16:00:12 #startmeeting oslo 16:00:13 Meeting started Mon Dec 15 16:00:12 2014 UTC and is due to finish in 60 minutes. The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:17 The meeting name has been set to 'oslo' 16:00:25 #link https://wiki.openstack.org/wiki/Meetings/Oslo 16:00:31 who's around for the oslo meeting? 16:00:32 o/ 16:00:33 o/ 16:00:37 o/ 16:00:43 o/ 16:00:46 o/ 16:00:59 o/ 16:01:09 hi 16:01:17 o/ 16:01:18 o/ 16:01:24 o/ 16:01:26 o/ 16:02:04 courtesy ping for jd__, dims, flaper87, harlowja,viktors, rpodolyaka1 16:02:17 oops, I missed that viktors and rpodolyaka1 were here, sorry guys 16:02:37 #topic Review action items from previous meeting 16:02:46 #info dhellmann update release instructions after https://review.openstack.org/#/c/136401/ is merged DONE 16:02:46 #link https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary 16:02:55 #info jd__ to update gerrit dashboard config for oslo and review links in the oslo wiki to add tooz and remove hacking DONE 16:02:55 #link https://review.openstack.org/#/c/140611/ 16:03:01 jd__, did you update the link on the wiki page, too? 16:03:35 we'll come back to that 16:03:41 #info jd__ prepare a list of projects using memcache libraries directly that will need to be migrated if we recommend a new memcache lib DONE 16:03:45 (Keystone in test-requirements and Zaquar in requirements) 16:03:54 #info harlowja_at_home to plan a date for a taskflow review sprint DONE 16:03:55 #link http://lists.openstack.org/pipermail/openstack-dev/2014-December/052688.html 16:04:09 please everyone reply to that mailing list thread if you haven't already so we know whether the date will work 16:04:40 #info dhellmann send email asking liaisons to prepare list of potential fixtures to be added to libraries and config options used by tests DONE 16:04:40 #link http://lists.openstack.org/pipermail/openstack-dev/2014-December/052977.html 16:05:04 let me know if you have questions about that -- it's not a rush, but we expect the research to take a while so we need to start 16:05:45 I need to add some more info to the rewritten project instructions: 16:05:46 #action dhellmann make sure instructions for creating a new library are up to date with stable requirements jobs 16:05:57 I think that's it for old business, unless I missed something? 16:06:38 ok, new business then 16:06:40 #topic kilo-1 deadline 16:06:40 #link https://launchpad.net/oslo/+milestone/kilo-1 16:06:48 We have 2 blueprints with "Good Progress" that I think we can probably finish before the deadline 16:07:00 #info tooz-adoption 16:07:00 #link https://blueprints.launchpad.net/oslo-incubator/+spec/tooz-adoption 16:07:00 the final work here is in the global requirements list, right? 16:07:06 jd__: ^^ 16:07:18 looks like it 16:07:28 ok, good 16:07:42 dhellmann: hm, so isn't oslo.context already graduated? :) 16:07:48 I've already migrated neutron to it :| 16:07:56 ihrachyshka: we have a library, but have not finished all of the process 16:08:05 releasing the library is not the last step in the process by a long shot 16:08:10 #info graduate-oslo-context 16:08:10 #link https://blueprints.launchpad.net/oslo-incubator/+spec/graduate-oslo-context 16:08:11 ah, ok, so I haven't failed here, good;) 16:08:25 it looks like the last step here is to remove the context code from the incubator 16:08:30 I tried working on that last week, and ended up having trouble because of changes to the logging code that needed to be backported 16:08:39 rather than do all of that, I propose we wait and remove context and logging from the incubator at the same time 16:08:43 thoughts? 16:09:03 Sounds reasonable. 16:09:10 sounds good 16:09:54 the logging graduation turned into a bit of a mess, but with the work dims did on the context library I think we're about ready to get back on track 16:10:12 We also have 1 bug in progress for kilo-1 16:10:18 #info oslo apiclient logs sensitive data 16:10:18 #link https://bugs.launchpad.net/oslo-incubator/+bug/1328488 16:10:20 Launchpad bug 1328488 in oslo-incubator "oslo apiclient logs sensitive data" [Medium,Fix committed] 16:10:30 ah, that is done 16:10:52 * dhellmann notes that it is hard to keep the agenda up to date with lp 16:11:07 #topic Red flags for/from liaisons 16:11:11 we know we have one ongoing issue 16:11:18 #info glance is currently having an issue with the sqlalchemy requirements in the released oslo.db breaking their unit tests 16:11:18 #link http://logs.openstack.org/28/139228/9/gate//gate-glance-python27/75d5cb9/console.html#_2014-12-15_10_35_29_889 16:11:25 apparently the problem was caused by the new release of setuptools, which has changed the way it deals with dependencies and versions 16:11:35 the glance team also has a security issue they are trying to resolve, so we need to help them find a way to fix this quickly 16:11:37 we need to prioritize making a new release of oslo.db with the right version string, but we also want to understand what other changes that will include 16:12:24 what's wrong with the version string? 16:12:27 viktors, rpodolyaka1 : can we talk right after the meeting? I can cut the release if it's getting late for you there, but I want to make sure I know what's in it before we do that 16:12:39 dhellmann: sure, np 16:12:48 dhellmann: ok, sure 16:12:55 bknudson: the old version string expresses exceptions in several version ranges, and apparently setuptools doesn't like that? I'm not entirely certain. 16:12:56 dhellmann: should be an easy pie. we haven't merged anything big AFAIR 16:13:04 dhellmann: ya thats basically it 16:13:04 rpodolyaka1: ok, that's good to hear 16:13:23 oh, that was an update to global requirements... just saw that in keystone 16:13:24 clarkb: cool, thanks 16:13:25 dhellmann: bknudson it expresses two ranges >=8.5,<=8.99 and >=0.97,<0.99 16:13:37 we were just talking about that last week. 16:13:38 bknudson: yeah, we have the change in oslo.db, but not in a released oslo.db, so... 16:13:41 except the , is now treated as an AND so logically that doesn't make sense 16:14:04 so we'll get a release out in about 50-60 minutes, it sounds like 16:14:16 dhellmann: haven't we capped setuptools version to <8.0? doesn't it help? 16:14:24 ihrachyshka: we have and it helps most things 16:14:25 ihrachyshka: no, that is not what we have 16:14:30 oh, sorry, setuptools, yes 16:14:38 I read sqlalchemyt 16:14:43 ihrachyshka: but only in the gate and only if something doesn't undo the pin 16:14:51 which it looks like glance's unittests manage to do 16:15:05 ok, so that's more about 'the right fix' than about 'fixing gate' discussion. 16:15:12 it's not a problem to do the release, I just didn't want to do it right before the meeting without having a chance to look at the included changes 16:15:27 ah, ok, glance specific. sorry for noise. 16:15:50 are there any other issues we need to discuss? 16:15:56 #link http://lists.openstack.org/pipermail/openstack-dev/2014-December/052972.html 16:16:04 (liaisons, please report "none" if you have nothing) 16:16:14 none 16:16:15 no issues in keystone that I know if. 16:16:16 ironic: none 16:16:25 cinderr 16:16:30 briefly, neutron was split, and now we wonder how to manage multiple oslo-incubator copies. please comment, maybe in email 16:16:48 None that I know of for tripleo, but I just got back. 16:16:58 ihrachyshka: yes, I'll comment on that email thread after I've had a chance to read through your problem statement 16:17:05 tnx 16:17:26 jungleboyj, does cinder use oslo.concurrency? 16:17:43 I'm curious about how the namespace change is going there 16:17:53 dhellmann: Ah, I think we just were moving to that. 16:17:56 I believe nova has started changing their import statements 16:18:05 ah, ok, so you can just use the new name and ignore the old namespace 16:18:54 oh, lots of other projects are already using it http://paste.openstack.org/show/151264/ 16:19:13 is everyone working on moving away from using "from oslo.concurrency import" to "from oslo_concurrency import"? 16:19:24 dhellmann: Ok, I thought we had moved to that and didn't have major issues. 16:19:34 jungleboyj: good, that's what I want to hear :-) 16:20:02 dhellmann: That sounds like a todo for me to check on. 16:20:20 ah, ok, yes 16:20:37 * dhellmann takes silence from the other liaisons as a lack of issues 16:20:38 * bnemec makes a note too look into aeromancer 16:20:52 https://github.com/dhellmann/aeromancer 16:21:14 #topic Ongoing work & Review priorities 16:21:16 dhellmann: Nice, thanks 16:21:27 bnemec: WIP 16:21:34 #link https://launchpad.net/oslo/+milestone/next-kilo 16:21:35 #link https://launchpad.net/oslo/+milestone/kilo-1 16:21:37 We have a problem with https://review.openstack.org/#/c/126330/ 16:22:02 sileht has pushed some patches and leaved it as is 16:22:24 now it is down on the two gates 16:22:39 #undo 16:22:40 Removing item from minutes: 16:22:42 i159, the patch have some issues, some times rabbitmq drop the connection 16:22:43 #undo 16:22:44 Removing item from minutes: 16:22:47 #undo 16:22:48 Removing item from minutes: 16:23:17 sileht: Hi! Can you investigate it? 16:23:30 is this a problem in a released version of oslo.messaging, with master, or with patches we have not yet merged? 16:23:35 sileht: unfirtunately I have no time to fix it 16:23:41 i159, I have tried, but it's hard to reproduce locally 16:24:05 dhellmann, havent merged yet 16:24:10 ok, good 16:24:47 sileht: maybe we should revert it to a stable version and merge? 16:24:52 #topic Ongoing work & Review priorities 16:24:52 #link https://launchpad.net/oslo/+milestone/next-kilo 16:24:52 #link https://launchpad.net/oslo/+milestone/kilo-1 16:25:05 * dhellmann apologizes for fiddling with the meeting logs 16:25:16 i159, the stable version don't works too 16:25:48 sileht: ok, let's discuss later... Thank you 16:25:57 i159, ok thanks 16:26:27 I need some reviews on the namespace package changes I'm making 16:26:34 #link https://review.openstack.org/#/q/status:open+branch:master+topic:bp/drop-namespace-packages,n,z 16:26:41 Every time we land a patch in one of these libraries, I have to rebuild my patch by hand to ensure I don't miss anytihng because renaming all of the files ensures there is going to be a merge conflict. Please prioritize reviewing these patches over anything else currently in the review queue. :-) 16:26:53 ack 16:27:01 I've had an especially hard time with oslo.db, oslo.messaging, and oslo.config since those see a lot of other patches 16:27:18 the other libs are quieter, and smaller, so they're easier to handle 16:27:56 I've had a few people ask, so I'll mention here that the reason I kept the old tests directly in addition to creating the new one under the new package name is to have a way to test the old namespace API 16:28:08 so if you look at the tests, they are mostly copies with imports and mocks changed 16:28:31 we will only need to add new tests under oslo_foo/tests but I want to keep the tests/ directory around for now 16:28:37 That's what I figured, but I wanted to make sure. 16:28:38 until we drop the namespace package entirely 16:28:54 yeah, I should have made that clear in the spec or commit message but didn't 16:29:28 I would like to get all of the current patches reviewed this week, with the idea that we may be able to cut releases of the libraries next week 16:29:55 * dhellmann looks at the calendar 16:30:01 ok, so maybe no release next week, maybe after the holidays 16:30:23 but if we can merge the changes, that will give everyone else time to rebase their work 16:30:41 Is anyone else blocked on work we prioritized for this release? 16:31:01 ok, here is my (opportunistic) attempt to unblock oslo.concurrency for neutron: https://review.openstack.org/141436 16:31:31 ihrachyshka: ah, yes, I'll look at that today. it's good that bnemec is back, too 16:32:18 tnx 16:32:25 bnemec: the quick version of the history there is if we use the config filter then deployers can't use interpolation with configuration options in some cases because the configuration objects can't see to get the value being inserted if it is filtered 16:32:52 That's weird. 16:32:57 but it actually breaks the other way, too, so if filtered_opt is set to $unfiltered_opt the config filter can't find $unfiltered_opt 16:33:31 it's by design, and works great within the application for preventing code from referring to option values it shouldn't, but a deployer doesn't understand why the error tells them the option isn't defined 16:33:58 I have a related fix in oslo.config to improve the error message: https://review.openstack.org/#/c/140143/ 16:34:08 I can understand why the unfiltered opts can't see the filtered opts, but not the other way around. 16:34:11 but I think the right solution is to not use the filter until we can make this work 16:34:31 dhellmann: and that's what my patch does :) 16:34:37 the filter is wrapped around the main config object, so the filtered options aren't even defined when the unfiltered option is evaluated 16:34:47 ihrachyshka: right 16:35:12 That makes me very sad though. It means the config opts are back to being part of the public api whether we want them to be or not. 16:35:28 we might actually have a similar problem if we define options at runtime, I'll have to check that case 16:36:05 bnemec: yeah, it's not great, but I think it just means we built the filter wrong -- we left out this use case 16:36:25 deployers shouldn't have to know where options are defined to refer to them -- their config file is "flat" as far as they can tell 16:37:30 Yeah 16:37:30 bnemec: we could, for example, use option the discovery mechanism for the sample generator to find all options and allow them to be used for interpolation, but not referenced directly in code 16:38:17 I don't know if that would actually work, but something similar might -- maybe filtered options are explicitly registered as "hidden" on the config object being wrapped 16:38:46 Yeah, will have to think about it. 16:39:09 right, so in the mean time, we need to drop the filter to support neutron 16:39:31 #topic open discussion 16:39:39 is there anything else we need to discuss this week? 16:40:26 viktors, rpodolyaka1 : here's what I get for release notes for oslo.db: http://paste.openstack.org/show/151294/ 16:40:53 dhellmann: yes, it should be safe for release 16:41:30 viktors: are any of those other fixes important enough to be worth mentioning in the release email? 16:41:38 with more detail, I mean 16:42:04 some of them are related to python 3, so are you testing under python 3 now, for example? 16:42:28 it's not voting yet 16:42:32 1-2 patches left 16:42:34 ok 16:42:34 dhellmann: only this, maybe - we are made py3 unittests green ) 16:42:49 we'll hold off on that announcement until it's voting 16:42:57 dhellmann: agreed 16:43:34 viktors, rpodolyaka1 : I can tag a release right after the meeting, unless one of you wants to do it. I know it's late there. 16:44:11 dhellmann: np, you can move on 16:44:15 ok 16:44:42 If no one has anything else to discuss, we can stop early so you have a few minutes to review some oslo patches :-) 16:45:20 :) 16:45:39 ok, let's go review, then! 16:45:46 thanks, everyone! 16:45:48 #endmeeting