16:01:42 <dhellmann> #startmeeting oslo
16:01:43 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:46 <openstack> The meeting name has been set to 'oslo'
16:01:52 <jecarey> o/
16:01:53 <redrobot> o/
16:01:54 <kgiusti> o/
16:01:56 <amrith> ./
16:01:57 <dhellmann> our agenda:
16:01:57 <dhellmann> #link https://wiki.openstack.org/wiki/Meetings/Oslo
16:01:57 <dhellmann> courtesy ping for jd__, dims, bnemec, flaper87, harlowja, viktors, rpodolyaka, zzzeek, sileht, kgiusti, dansmith
16:01:57 <dhellmann> courtesy ping for redrobot, jungleboyj, zhiyan, therve, amotoki, GheRivero, bknudson, ihrachyshka, jogo, dougwig, sreshetnyak, amrith
16:01:57 <bknudson> lol
16:01:58 <sileht> o/
16:02:03 <harlowja_at_home> yo yo
16:02:08 <dims> o/
16:02:08 <bnemec> \o
16:02:39 <dansmith> what is the emoticon for "here, but with a phone up to my other ear" ?
16:03:04 <dhellmann> isn't there an emoji for that?
16:03:09 <dansmith> \Oj
16:03:26 * dhellmann slow clap
16:03:29 <dansmith> lol
16:03:39 <dhellmann> #topic Review action items from previous meeting
16:03:48 <dhellmann> I see no actions logged from last week
16:03:57 <dhellmann> did I miss any?
16:04:21 <jd__> o/
16:04:24 <jungleboyj> o/
16:04:25 <dhellmann> yes, I wasn't looking in the right place
16:04:28 <dhellmann> #link http://eavesdrop.openstack.org/meetings/oslo/2015/oslo.2015-03-09-16.02.html
16:04:37 <dhellmann> #info add oslo-config-generator to priority work for Liberty
16:04:46 <dhellmann> that has no name attached to it
16:05:00 <dhellmann> #info amrith to drive trove to use oslo.log
16:05:10 <dhellmann> amrith: how is that looking?
16:05:14 <amrith> dhellmann, yes, that is underway
16:05:18 <amrith> having a little trouble
16:05:30 <amrith> with getting logging.register_options() plumbed into the right places.
16:05:40 <dhellmann> ok, let the rest of the team know if you need help with reviews
16:05:42 <dims> dhellmann: probably mine, guess we need to start a priority list etherpad for liberty? (do we have one already?)
16:05:53 <dhellmann> yeah, that should go right before the cfg.CONF() calls
16:05:57 <amrith> dhellmann, yes. not yet ready for review.
16:06:11 <amrith> ok, dhellmann thanks. I was doing a binary search to find the right place ;)
16:06:23 <dhellmann> dims: we don't, but maybe we can build on the summit planning pad?
16:06:42 <dims> dhellmann: ok, let me find it
16:06:51 <dhellmann> 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 <dhellmann> #link https://etherpad.openstack.org/p/liberty-oslo-summit-planning
16:07:02 <dhellmann> dims: ^^
16:07:16 <dims> thx
16:07:23 <dhellmann> #info dims to collect items to review after feature freeze
16:07:32 <dhellmann> that last item was for bug-fix priorities
16:07:47 <dhellmann> #link https://etherpad.openstack.org/p/oslo-kilo-final-bug-list
16:08:39 <dhellmann> I don't see the database handle-after-a-fork issue there, unless that's what #2 is
16:09:12 <dhellmann> #link https://bugs.launchpad.net/cinder/+bug/1417018
16:09:12 <openstack> 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 <uvirtbot> 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 <uvirtbot> 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 <dims> dhellmann: done
16:09:27 <harlowja_at_home> ya, afaik thats the forking issue
16:09:51 <bknudson> he he
16:10:00 <jungleboyj> :-)
16:10:06 <jungleboyj> forking issue indeed.
16:10:10 <dhellmann> dims: that's done? was it in the last oslo.db release?
16:10:10 <harlowja_at_home> 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 <dims> dhellmann: i meant i updated the liberty-oslo-summit-planning page, apologies
16:10:46 <dhellmann> 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 <dhellmann> dims: ah, sorry, mis-threaded your comment :-)
16:11:59 <sileht> harlowja_at_home, my feeling is that the process launcher class should take a class and not a object
16:11:59 <dhellmann> it looks like zzzeek's patch to oslo.db merged
16:13:05 <dhellmann> but it's not released, so we need to backport that to the stable branch
16:13:24 <dhellmann> can we get a volunteer to backport the db connection handling fix to oslo.db stable/kilo?
16:13:39 <dhellmann> sileht: yes, that would work better, too
16:13:51 <harlowja_at_home> 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 <dhellmann> sileht: or a callable, in case args need to be provided to create the instance
16:14:06 <harlowja_at_home> that fixes the bug (but is a bigger challenge to fix)
16:14:18 <dhellmann> harlowja_at_home: we could write a new launcher that works that way
16:14:39 <harlowja_at_home> agreed
16:15:03 <dhellmann> who wants to backport the existing fix for us so we can release oslo.db 1.7.1?
16:15:17 <dims> dhellmann: i can help with that
16:15:19 <bknudson> is it more than a backport? looks like oslo-incubator is affected? https://bugs.launchpad.net/cinder/+bug/1417018
16:15:20 <openstack> 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 <uvirtbot> 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 <dhellmann> it should be easy, since that's the only difference between master and the stable branch :-)
16:15:25 <uvirtbot> 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 <dims> dhellmann: ack
16:15:46 <dhellmann> #etoomanybots
16:15:49 <bknudson> openstack and uvirtbot are tripping over each other
16:16:40 <dhellmann> 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 <dhellmann> changes to the service launcher or forking code will be in the incubator, until we graduate that code
16:18:02 <dhellmann> #action dims set up backport of oslo.db fix for after-fork handling of connections
16:18:31 <dhellmann> ok, I think that's it for old business
16:18:32 <dhellmann> #topic Red flags for/from liaisons
16:18:44 <bknudson> none from keystone that I can think of.
16:18:54 <bknudson> smooth sailing.
16:18:54 <dhellmann> how are we looking going into feature freeze? aside from the trove work, does anyone need help?
16:19:04 <harlowja_at_home> 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 <bknudson> harlowja_at_home: what are existing libs you're thinking of?
16:19:56 <harlowja_at_home> bknudson, let's see; i made an etherpad somewhere, let me see if i can find it ,lol
16:19:58 <bknudson> (not that it really affects keystone since we're getting rid of eventlet anyways)
16:20:02 <jungleboyj> dhellmann: None for Cinder other than the issue already discussed.  Just working on finishing up incubator clean-up.
16:20:09 <dhellmann> 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 <dhellmann> jungleboyj: sounds good. We'll get that oslo.db release cut asap.
16:20:44 <jungleboyj> Thanks.
16:21:27 <GheRivero> none for ironic. Clean-up from incubator and migrating to oslo.log
16:22:06 <harlowja_at_home> bknudson, https://etherpad.openstack.org/p/service-py-replacements
16:22:07 <dhellmann> GheRivero: sounds good - let us know if you run into issues with any of those changes
16:22:14 <bknudson> harlowja_at_home: neat, thanks.
16:22:17 <harlowja_at_home> bknudson,  additions/comments welcome
16:23:14 <dhellmann> harlowja_at_home: maybe you can turn that into a spec for liberty?
16:23:25 <dhellmann> it looks like a lot of options to evaluate
16:23:32 <harlowja_at_home> dhellmann, sure
16:23:42 <dhellmann> cool
16:23:53 <dhellmann> ok, let's move on then from issues
16:23:54 <dhellmann> #topic Feature freeze
16:23:56 <dhellmann> #info we have stable branches for all of the libs now so it should be safe to make changes in master
16:23:57 <dhellmann> #info we should be focusing on bug fixes leading up to the release candidate period
16:24:18 <dhellmann> so, while it's *safe* to keep working on master, we should be focusing on bug fixes over features for now
16:24:27 <dhellmann> at least prioritizing them when we find them
16:24:45 <bknudson> so kilo is going to be using whatever's in stable now ?
16:24:48 <dhellmann> dims' work on the deprecation warnings last week is a great example of that
16:25:05 <bknudson> not going to update global-requirements with any new features?
16:25:10 <dhellmann> bknudson: I have a patch up to update the g-r, just a sec
16:25:23 <dhellmann> #link https://review.openstack.org/#/c/162656/
16:25:53 <bknudson> which will prevent K using new features.
16:25:58 <bknudson> good.
16:26:00 <harlowja_at_home> 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 <dhellmann> yes, but not bug fixes
16:26:16 <bknudson> then there's a release of all these libs with x.y+1.0
16:26:52 <dhellmann> harlowja_at_home: ok, I wish we had done this last week.
16:27:04 <harlowja_at_home> ya, i was avoiding the friday release :-P
16:27:25 <dhellmann> 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 <zzzeek> o/ for 10 minutes
16:27:40 <harlowja_at_home> k, that's fine i think
16:28:22 <dhellmann> 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 <dhellmann> harlowja_at_home: do you have a list of what's in the release?
16:30:06 <harlowja_at_home> hmmm, i can get one/make one, lol
16:30:38 <dhellmann> harlowja_at_home: is it everything that's not released right now? that's a looong list
16:30:45 <harlowja_at_home> right, thats the list :-P
16:31:17 <dhellmann> 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 <harlowja_at_home> ok, whens that
16:31:36 * dhellmann looks for release calendar
16:31:53 <bknudson> https://wiki.openstack.org/wiki/Kilo_Release_Schedule
16:31:53 <dhellmann> #link https://wiki.openstack.org/wiki/Kilo_Release_Schedule
16:32:18 <harlowja_at_home> ok, so this week i guess?
16:32:23 <dhellmann> the first RCs will be cut early in april
16:32:53 <dhellmann> after we cap requirements in master releasing the lib won't do anything because projects won't see it
16:33:06 <harlowja_at_home> right
16:33:06 <dhellmann> and we won't release that cap until after their stable branches are cut
16:33:28 <dhellmann> so maybe just waiting until after we have that cap landed in all of the projects would be long enough
16:33:42 <harlowja_at_home> seems fair to me
16:33:47 <dhellmann> I obviously don't know when that will be, but we're trying to get the g-r piece done today
16:34:28 <bknudson> good luck getting through the gate.
16:34:28 <harlowja_at_home> cool, sputnik13 and a few others will be happy if that's possible i think, lol
16:34:57 <sputnik13> RC of..?
16:35:10 <harlowja_at_home> sputnik13, nova, glance...
16:35:11 <sputnik13> zookeeper?
16:35:13 <sputnik13> oh
16:35:15 <sputnik13> :)
16:35:28 <dhellmann> 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 <dhellmann> sputnik13: release candidates of the integrated projects
16:36:13 <sputnik13> icic
16:36:24 <dhellmann> we would want someone who gets up early on monday mornings :-)
16:36:31 * jungleboyj needs to step away.
16:36:44 <harlowja_at_home> early u saw :-/
16:36:47 <harlowja_at_home> *say
16:37:22 <dhellmann> 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 <sputnik13> how early is early
16:37:58 <dims> dhellmann: let me add it to the liberty-oslo-summit-planning etherpad
16:38:04 <dhellmann> just a thought, we can talk about that
16:38:07 <dhellmann> dims: good idea
16:38:43 <dhellmann> sputnik13: europe or us eastern morning?
16:38:45 <GheRivero> not early but being in Europe, it's earlier than in Americas... but later than Asia :/
16:39:13 <dhellmann> GheRivero: yeah, that's a good point
16:39:25 <dhellmann> maybe we should make tuesday release day, so we can talk about them at the meetings
16:39:39 <dims> normal morning europe time is good enough i feel
16:39:40 <dhellmann> anyway, this is a good session topic for the summit
16:39:56 <dims> dhellmann: added to "Reviewing our release processes" session
16:40:00 <dhellmann> dims: thanks
16:40:23 <dhellmann> ok, we have a couple of other things to cover this week
16:40:28 <dhellmann> #topic requirements mangement policy
16:40:29 <dhellmann> #link https://review.openstack.org/157135
16:40:47 <dhellmann> this topic saw some interest on the mailing list, and we have some feedback on the review
16:41:16 <bnemec> I still think we need a resolution on https://review.openstack.org/#/c/153966/ before we can make any decisions.
16:41:17 <dhellmann> 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 <dhellmann> 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 <dhellmann> 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 <dhellmann> which does mean we need some other solution, but I don't know yet what that is
16:46:01 <dhellmann> #topic test tooling policy
16:46:01 <dhellmann> #link https://review.openstack.org/158787
16:46:04 <harlowja_at_home> 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 <dhellmann> #undo
16:46:22 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0x908cb50>
16:46:25 <dhellmann> #undo
16:46:25 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x8b4a250>
16:46:35 * harlowja_at_home just thinking out loud
16:46:57 <harlowja_at_home> 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 <dhellmann> 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 <harlowja_at_home> meh
16:47:24 <dhellmann> 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 <dhellmann> 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 <harlowja_at_home> ok
16:48:07 <bnemec> Sane optional dependencies would solve all these problem. :-/
16:48:09 <dhellmann> and that leads nicely to the next topic :-)
16:48:13 <dhellmann> #topic test tooling policy
16:48:13 <dhellmann> #link https://review.openstack.org/158787
16:48:25 <dhellmann> this is the policy that says we won't use test base classes for new testing features
16:48:53 <dhellmann> and if we stop doing that, then the fixtures really only depend on the fixtures library, which really minimizes the issue
16:49:25 <bnemec> +1
16:49:26 <harlowja_at_home> seems fair to me
16:49:36 <dhellmann> bnemec: yes, the question is how to specify those optional dependencies in some sort of sane way in the consuming project
16:50:00 <dhellmann> 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 <dhellmann> we'll need to review our existing test tools and see where we might need to provide new ones
16:50:19 <dhellmann> or modify them
16:51:17 <dhellmann> it would be good to have someone focused on this next cycle
16:51:30 <dims> no easy answers :(
16:51:41 <dhellmann> so we make sure we actually resolve all of the open questions and make a list of the changes needed
16:51:53 <dhellmann> bnemec: you have a lot of interest in this, are you willing to take the lead?
16:52:09 <dhellmann> dims: if it was easy, anyone could do it :-)
16:52:24 <bnemec> dhellmann: We're talking about the base test class -> fixtures thing, right?
16:52:51 <dhellmann> bnemec: resolving how we're going to manage test dependencies, and then the base class -> fixtures changes
16:53:07 <dhellmann> 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 <bnemec> dhellmann: Sure, I can do that.
16:53:58 <dhellmann> bnemec: great, thanks
16:54:28 <dhellmann> #info bnemec will be the lead for the test requirements and fixtures cleanup initiative
16:54:46 <dhellmann> ok, we just have a few more minutes
16:54:47 <dhellmann> #topic open discussion
16:54:58 <dhellmann> is there anything that didn't make it onto the agenda that we should discuss?
16:55:19 <dhellmann> we should start doing more planning for the summit, soon. Get your specs written!
16:55:32 * dims all good
16:55:45 <harlowja_at_home> go beat up https://review.openstack.org/#/c/164035/
16:55:46 <harlowja_at_home> lol
16:55:56 <harlowja_at_home> i mean, be tender to it, lol
16:56:07 <dhellmann> 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 <harlowja_at_home> sounds like another fun spec, lol
16:57:03 <harlowja_at_home> *fun*
16:57:37 <dhellmann> 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 <harlowja_at_home> the hole just gets deeper otherwise imho if they don't
16:58:33 <dhellmann> 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 <dhellmann> harlowja_at_home: ++
16:59:47 <dhellmann> alright, good meeting, thanks everyone!
17:00:04 <dhellmann> #endmeeting