16:01:42 #startmeeting oslo 16:01:43 Meeting started Mon Mar 16 16:01:42 2015 UTC and is due to finish in 60 minutes. The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:44 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:46 The meeting name has been set to 'oslo' 16:01:52 o/ 16:01:53 o/ 16:01:54 o/ 16:01:56 ./ 16:01:57 our agenda: 16:01:57 #link https://wiki.openstack.org/wiki/Meetings/Oslo 16:01:57 courtesy ping for jd__, dims, bnemec, flaper87, harlowja, viktors, rpodolyaka, zzzeek, sileht, kgiusti, dansmith 16:01:57 courtesy ping for redrobot, jungleboyj, zhiyan, therve, amotoki, GheRivero, bknudson, ihrachyshka, jogo, dougwig, sreshetnyak, amrith 16:01:57 lol 16:01:58 o/ 16:02:03 yo yo 16:02:08 o/ 16:02:08 \o 16:02:39 what is the emoticon for "here, but with a phone up to my other ear" ? 16:03:04 isn't there an emoji for that? 16:03:09 \Oj 16:03:26 * dhellmann slow clap 16:03:29 lol 16:03:39 #topic Review action items from previous meeting 16:03:48 I see no actions logged from last week 16:03:57 did I miss any? 16:04:21 o/ 16:04:24 o/ 16:04:25 yes, I wasn't looking in the right place 16:04:28 #link http://eavesdrop.openstack.org/meetings/oslo/2015/oslo.2015-03-09-16.02.html 16:04:37 #info add oslo-config-generator to priority work for Liberty 16:04:46 that has no name attached to it 16:05:00 #info amrith to drive trove to use oslo.log 16:05:10 amrith: how is that looking? 16:05:14 dhellmann, yes, that is underway 16:05:18 having a little trouble 16:05:30 with getting logging.register_options() plumbed into the right places. 16:05:40 ok, let the rest of the team know if you need help with reviews 16:05:42 dhellmann: probably mine, guess we need to start a priority list etherpad for liberty? (do we have one already?) 16:05:53 yeah, that should go right before the cfg.CONF() calls 16:05:57 dhellmann, yes. not yet ready for review. 16:06:11 ok, dhellmann thanks. I was doing a binary search to find the right place ;) 16:06:23 dims: we don't, but maybe we can build on the summit planning pad? 16:06:42 dhellmann: ok, let me find it 16:06:51 amrith: oh, wow, yeah please let me know if you need some pointers. I want to make sure those docs are clear. 16:07:01 #link https://etherpad.openstack.org/p/liberty-oslo-summit-planning 16:07:02 dims: ^^ 16:07:16 thx 16:07:23 #info dims to collect items to review after feature freeze 16:07:32 that last item was for bug-fix priorities 16:07:47 #link https://etherpad.openstack.org/p/oslo-kilo-final-bug-list 16:08:39 I don't see the database handle-after-a-fork issue there, unless that's what #2 is 16:09:12 #link https://bugs.launchpad.net/cinder/+bug/1417018 16:09:12 Launchpad bug 1417018 in oslo.db "Cinder encounters dbapi error: NoSuchColumnError: "Could not locate column in row for column '%(140070887032400 anon)s.volumes_id'"" [Medium,In progress] 16:09:14 Launchpad bug 1417018 in oslo.db "Cinder encounters dbapi error: NoSuchColumnError: "Could not locate column in row for column '%(140070887032400 anon)s.volumes_id'"" [Medium,In progress] 16:09:16 Launchpad bug 1417018 in oslo.db "Cinder encounters dbapi error: NoSuchColumnError: "Could not locate column in row for column '%(140070887032400 anon)s.volumes_id'"" [Medium,In progress] https://launchpad.net/bugs/1417018 16:09:21 dhellmann: done 16:09:27 ya, afaik thats the forking issue 16:09:51 he he 16:10:00 :-) 16:10:06 forking issue indeed. 16:10:10 dims: that's done? was it in the last oslo.db release? 16:10:10 dhellmann, u looked at the service code and pondered over it; any ideas on how to truely fix that (maintain a list of sockets somewhere that can't be closed?) 16:10:34 dhellmann: i meant i updated the liberty-oslo-summit-planning page, apologies 16:10:46 harlowja_at_home: I had hoped we could come up with a way to register callbacks to close before a fork and reopen after, but that may be cumbersome 16:10:56 dims: ah, sorry, mis-threaded your comment :-) 16:11:59 harlowja_at_home, my feeling is that the process launcher class should take a class and not a object 16:11:59 it looks like zzzeek's patch to oslo.db merged 16:13:05 but it's not released, so we need to backport that to the stable branch 16:13:24 can we get a volunteer to backport the db connection handling fix to oslo.db stable/kilo? 16:13:39 sileht: yes, that would work better, too 16:13:51 sileht, likely, i'd almost like to treat any open sockets/things as bugs, and not have anything opened till after fork 16:13:54 sileht: or a callable, in case args need to be provided to create the instance 16:14:06 that fixes the bug (but is a bigger challenge to fix) 16:14:18 harlowja_at_home: we could write a new launcher that works that way 16:14:39 agreed 16:15:03 who wants to backport the existing fix for us so we can release oslo.db 1.7.1? 16:15:17 dhellmann: i can help with that 16:15:19 is it more than a backport? looks like oslo-incubator is affected? https://bugs.launchpad.net/cinder/+bug/1417018 16:15:20 Launchpad bug 1417018 in oslo.db "Cinder encounters dbapi error: NoSuchColumnError: "Could not locate column in row for column '%(140070887032400 anon)s.volumes_id'"" [Medium,In progress] 16:15:20 Launchpad bug 1417018 in oslo.db "Cinder encounters dbapi error: NoSuchColumnError: "Could not locate column in row for column '%(140070887032400 anon)s.volumes_id'"" [Medium,In progress] 16:15:22 it should be easy, since that's the only difference between master and the stable branch :-) 16:15:25 Launchpad bug 1417018 in oslo.db "Cinder encounters dbapi error: NoSuchColumnError: "Could not locate column in row for column '%(140070887032400 anon)s.volumes_id'"" [Medium,In progress] https://launchpad.net/bugs/1417018 16:15:36 dhellmann: ack 16:15:46 #etoomanybots 16:15:49 openstack and uvirtbot are tripping over each other 16:16:40 bknudson: I think I added the incubator to the bug because that's where the service code is. The existing patch in oslo.db is a stop-gap or work-around or whatever, so it helps but isn't a complete solution. 16:17:01 changes to the service launcher or forking code will be in the incubator, until we graduate that code 16:18:02 #action dims set up backport of oslo.db fix for after-fork handling of connections 16:18:31 ok, I think that's it for old business 16:18:32 #topic Red flags for/from liaisons 16:18:44 none from keystone that I can think of. 16:18:54 smooth sailing. 16:18:54 how are we looking going into feature freeze? aside from the trove work, does anyone need help? 16:19:04 dhellmann, i can try to look into what may be better for service.py (examine exsting libraries...., see if any of them fit, and if not, then i guess we have to create/adapt ours)... 16:19:28 harlowja_at_home: what are existing libs you're thinking of? 16:19:56 bknudson, let's see; i made an etherpad somewhere, let me see if i can find it ,lol 16:19:58 (not that it really affects keystone since we're getting rid of eventlet anyways) 16:20:02 dhellmann: None for Cinder other than the issue already discussed. Just working on finishing up incubator clean-up. 16:20:09 harlowja_at_home: ok. changing too far from what we have may require a level of rewrite in the other projects that would mean getting a bunch of other people on board, so keep that in mind. that said, using other libs where we can is good. 16:20:36 jungleboyj: sounds good. We'll get that oslo.db release cut asap. 16:20:44 Thanks. 16:21:27 none for ironic. Clean-up from incubator and migrating to oslo.log 16:22:06 bknudson, https://etherpad.openstack.org/p/service-py-replacements 16:22:07 GheRivero: sounds good - let us know if you run into issues with any of those changes 16:22:14 harlowja_at_home: neat, thanks. 16:22:17 bknudson, additions/comments welcome 16:23:14 harlowja_at_home: maybe you can turn that into a spec for liberty? 16:23:25 it looks like a lot of options to evaluate 16:23:32 dhellmann, sure 16:23:42 cool 16:23:53 ok, let's move on then from issues 16:23:54 #topic Feature freeze 16:23:56 #info we have stable branches for all of the libs now so it should be safe to make changes in master 16:23:57 #info we should be focusing on bug fixes leading up to the release candidate period 16:24:18 so, while it's *safe* to keep working on master, we should be focusing on bug fixes over features for now 16:24:27 at least prioritizing them when we find them 16:24:45 so kilo is going to be using whatever's in stable now ? 16:24:48 dims' work on the deprecation warnings last week is a great example of that 16:25:05 not going to update global-requirements with any new features? 16:25:10 bknudson: I have a patch up to update the g-r, just a sec 16:25:23 #link https://review.openstack.org/#/c/162656/ 16:25:53 which will prevent K using new features. 16:25:58 good. 16:26:00 dhellmann, i was going to release taskflow 0.8 today (about time, ha); don't expect any issues there, should i move the stable/kilo to that, or just leave it be (this really has features that rackspace, stackforge projects... are using/want) 16:26:01 yes, but not bug fixes 16:26:16 then there's a release of all these libs with x.y+1.0 16:26:52 harlowja_at_home: ok, I wish we had done this last week. 16:27:04 ya, i was avoiding the friday release :-P 16:27:25 harlowja_at_home: if those features aren't released, no kilo code will be using them, so we should make sure that version is not introduced into the stable/kilo branch 16:27:35 o/ for 10 minutes 16:27:40 k, that's fine i think 16:28:22 I'm not even sure we should release them into master at this point, because of the approaching freeze for the other projects 16:29:23 * dhellmann thinks 16:29:40 * zzzeek starts jeopardy music 16:29:47 harlowja_at_home: do you have a list of what's in the release? 16:30:06 hmmm, i can get one/make one, lol 16:30:38 harlowja_at_home: is it everything that's not released right now? that's a looong list 16:30:45 right, thats the list :-P 16:31:17 ok. I think it's going to be safer to wait to release that until the rest of the projects are unfrozen :-/ 16:31:28 ok, whens that 16:31:36 * dhellmann looks for release calendar 16:31:53 https://wiki.openstack.org/wiki/Kilo_Release_Schedule 16:31:53 #link https://wiki.openstack.org/wiki/Kilo_Release_Schedule 16:32:18 ok, so this week i guess? 16:32:23 the first RCs will be cut early in april 16:32:53 after we cap requirements in master releasing the lib won't do anything because projects won't see it 16:33:06 right 16:33:06 and we won't release that cap until after their stable branches are cut 16:33:28 so maybe just waiting until after we have that cap landed in all of the projects would be long enough 16:33:42 seems fair to me 16:33:47 I obviously don't know when that will be, but we're trying to get the g-r piece done today 16:34:28 good luck getting through the gate. 16:34:28 cool, sputnik13 and a few others will be happy if that's possible i think, lol 16:34:57 RC of..? 16:35:10 sputnik13, nova, glance... 16:35:11 zookeeper? 16:35:13 oh 16:35:15 :) 16:35:28 I wonder if we should have a designated release manager for next cycle, so we have one person doing all of the releases to coordinate schedules like this? I did most of them last week, but left a few up to the primary maintainers and it looks like that means at least one slipped through the cracks :-/ 16:35:53 sputnik13: release candidates of the integrated projects 16:36:13 icic 16:36:24 we would want someone who gets up early on monday mornings :-) 16:36:31 * jungleboyj needs to step away. 16:36:44 early u saw :-/ 16:36:47 *say 16:37:22 yeah, I'm thinking the maintainers would say "lib X is ready for a release" and so this person would just push the right buttons 16:37:58 how early is early 16:37:58 dhellmann: let me add it to the liberty-oslo-summit-planning etherpad 16:38:04 just a thought, we can talk about that 16:38:07 dims: good idea 16:38:43 sputnik13: europe or us eastern morning? 16:38:45 not early but being in Europe, it's earlier than in Americas... but later than Asia :/ 16:39:13 GheRivero: yeah, that's a good point 16:39:25 maybe we should make tuesday release day, so we can talk about them at the meetings 16:39:39 normal morning europe time is good enough i feel 16:39:40 anyway, this is a good session topic for the summit 16:39:56 dhellmann: added to "Reviewing our release processes" session 16:40:00 dims: thanks 16:40:23 ok, we have a couple of other things to cover this week 16:40:28 #topic requirements mangement policy 16:40:29 #link https://review.openstack.org/157135 16:40:47 this topic saw some interest on the mailing list, and we have some feedback on the review 16:41:16 I still think we need a resolution on https://review.openstack.org/#/c/153966/ before we can make any decisions. 16:41:17 I would appreciate it if all of the liaisons would take a few minutes to read it and comment, so we can get a sense of how other projects handle the issue 16:42:23 bnemec: I think they're related, but I'm not sure that's the direction of the dependency. If we need a way to specify extra requirements then we need to figure out what that implemenation looks like, but not the other way around. 16:43:57 based on the feedback I've seen so far, I'm leaning towards moving the test requirements back out of requirements.txt for the next cycle 16:44:40 which does mean we need some other solution, but I don't know yet what that is 16:46:01 #topic test tooling policy 16:46:01 #link https://review.openstack.org/158787 16:46:04 what about an 'oslo.fixtures' library that has the fixtures for all the oslo libraries (this is with regard to the test/fixtures stuff); so that oslo.db fixture would be in there, so would .... 16:46:22 #undo 16:46:22 Removing item from minutes: 16:46:25 #undo 16:46:25 Removing item from minutes: 16:46:35 * harlowja_at_home just thinking out loud 16:46:57 i know we didn't want 2x the number of libraries, so just have one 'bigger' oslo.fixtures (with each libraries fixtures in it) 16:46:58 harlowja_at_home: that would have a lot of other dependencies on all of those other libs, so introducing it into the test requirements of an app would bring in all of oslo 16:47:08 meh 16:47:24 it would also mean that lib would have to be allowed to use private interfaces, because that's frequently how we implement the fixtures 16:47:49 I don't see an issue with including the fixtures in the libs that use them, and saying that to use those fixtures you might have to install another package 16:48:06 ok 16:48:07 Sane optional dependencies would solve all these problem. :-/ 16:48:09 and that leads nicely to the next topic :-) 16:48:13 #topic test tooling policy 16:48:13 #link https://review.openstack.org/158787 16:48:25 this is the policy that says we won't use test base classes for new testing features 16:48:53 and if we stop doing that, then the fixtures really only depend on the fixtures library, which really minimizes the issue 16:49:25 +1 16:49:26 seems fair to me 16:49:36 bnemec: yes, the question is how to specify those optional dependencies in some sort of sane way in the consuming project 16:50:00 the issue with the policy is the existing places that we do have unit test base classes, but I think that's mostly oslo.db right now 16:50:13 we'll need to review our existing test tools and see where we might need to provide new ones 16:50:19 or modify them 16:51:17 it would be good to have someone focused on this next cycle 16:51:30 no easy answers :( 16:51:41 so we make sure we actually resolve all of the open questions and make a list of the changes needed 16:51:53 bnemec: you have a lot of interest in this, are you willing to take the lead? 16:52:09 dims: if it was easy, anyone could do it :-) 16:52:24 dhellmann: We're talking about the base test class -> fixtures thing, right? 16:52:51 bnemec: resolving how we're going to manage test dependencies, and then the base class -> fixtures changes 16:53:07 not doing all of the work yourself, necessarily, but making sure we resolve all of the questions and understand what work does need to be done 16:53:29 dhellmann: Sure, I can do that. 16:53:58 bnemec: great, thanks 16:54:28 #info bnemec will be the lead for the test requirements and fixtures cleanup initiative 16:54:46 ok, we just have a few more minutes 16:54:47 #topic open discussion 16:54:58 is there anything that didn't make it onto the agenda that we should discuss? 16:55:19 we should start doing more planning for the summit, soon. Get your specs written! 16:55:32 * dims all good 16:55:45 go beat up https://review.openstack.org/#/c/164035/ 16:55:46 lol 16:55:56 i mean, be tender to it, lol 16:56:07 harlowja_at_home: yes, thank you for that, I'll put it on my review list 16:56:17 * dhellmann needs to write a similar spec about the python 3 porting work 16:57:00 sounds like another fun spec, lol 16:57:03 *fun* 16:57:37 yeah, it'll take a while to pull the details of what our dependencies support together 16:57:54 * bknudson interested to see if other projects are willing to get rid of eventlet in api servers. 16:58:28 the hole just gets deeper otherwise imho if they don't 16:58:33 bknudson: I'm interested to see if it actually gives us useful performance benefits over the options. 16:59:27 * harlowja_at_home will add a section on why its not just performance that matters, but the ability to move between container models (apache, ...) that eventlet is also acting as a barrier to making happen 16:59:37 harlowja_at_home: ++ 16:59:47 alright, good meeting, thanks everyone! 17:00:04 #endmeeting