16:00:17 <dhellmann> #startmeeting oslo
16:00:24 <openstack> Meeting started Mon Feb  9 16:00:17 2015 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:27 <ihrachyshka> o/
16:00:28 <openstack> The meeting name has been set to 'oslo'
16:00:34 <dhellmann> #link https://wiki.openstack.org/wiki/Meetings/Oslo
16:00:35 <bnemec> o/
16:00:36 <sileht> o/
16:00:42 <dhellmann> courtesy ping for jd__, dims, bnemec, flaper87, harlowja, viktors, rpodolyaka1, zzzeek, sileht, kgiusti
16:00:44 <dhellmann> courtesy ping for redrobot, jungleboyj, zhiyan, therve, amotoki, GheRivero, bknudson, ihrachyshka, jogo, dougwig, sreshetnyak, amrith
16:00:51 <jecarey> o/
16:00:54 <dhellmann> courtesy ping for rpodolyaka
16:00:55 <harlowja_at_home> \o
16:00:55 <bknudson> lol
16:00:56 <jungleboyj> o/
16:01:17 * dhellmann can't keep up with everyone's alternate nicks
16:01:20 <ozamiatin> o/
16:01:28 <amotoki> o/
16:02:02 <redrobot> o/
16:02:09 <dhellmann> nice turnout today!
16:02:13 <dhellmann> let's get started...
16:02:14 <dhellmann> #topic Review action items from previous meeting
16:02:17 <kgiusti> o/
16:02:19 <dhellmann> #info rpodolyaka & viktors to start a mailing list thread discussing mysql driver change
16:02:26 <dhellmann> #link http://lists.openstack.org/pipermail/openstack-dev/2015-January/thread.html#55469
16:02:59 <dhellmann> zzzeek actually started that thread, but the action is still done :-)
16:03:34 <dhellmann> it looks like we had plenty of support for testing the new lib
16:04:01 <dhellmann> rpodolyaka: how is that going?
16:04:33 <dhellmann> I'll find out from him later
16:04:38 <dhellmann> #info dhellmann write down spec approval policy in the specs repository
16:04:48 <dhellmann> that's up for review
16:04:50 <dhellmann> #link https://review.openstack.org/150119
16:05:02 <dhellmann> #action dhellmann document policy assumptions for library adoption among applications, including milestones and support for incubator code after graduation - DONE
16:05:12 <dhellmann> also up for review
16:05:12 <dhellmann> #link https://review.openstack.org/153682
16:05:23 <dhellmann> #info bnemec write policy spec on feature freezes
16:05:34 <bnemec> #link https://review.openstack.org/#/c/153642/
16:05:50 <dhellmann> nice
16:06:17 <dhellmann> ok, that's all of our old business
16:06:25 <dhellmann> #topic Policy Reviews
16:06:37 <dhellmann> I would like to finish the reviews for existing policies this week.
16:06:54 <dhellmann> there are a couple that are new ideas, like the oslo.config thing, but most of them are just updating what we had in the wiki
16:06:56 <bknudson> this is confusing since there's also oslo.policy.
16:07:17 <dhellmann> #link https://review.openstack.org/#/q/status:open+project:openstack/oslo-specs+branch:master+topic:policy,n,z
16:07:18 <GheRivero> o/
16:07:51 <dhellmann> bknudson: yeah, we now have 3 uses of that term (team rules, ACLs, and something out of neutron for network access rules)
16:08:09 <dhellmann> one more, and our next use is free
16:08:16 <harlowja_at_home> more policies! :-P
16:08:52 <ihrachyshka> :D
16:09:00 <ihrachyshka> neutron is not involved (almost)
16:09:01 <dhellmann> #info dhellmann will approve the policy documents in the specs repo by the end of the week unless there are objections registered in gerrit
16:09:05 <ihrachyshka> it's a side project
16:09:11 <dhellmann> ihrachyshka: ah, my mistake
16:09:24 <dhellmann> neutron ~= anything having to do with networking
16:09:46 <dhellmann> are there any questions or comments on the policy specs?
16:10:24 <bknudson> will be interesting to see how documenting policy works here since might be good for other projects to do it too.
16:10:43 <dhellmann> bknudson: yeah, I thought maybe we'd start another trend :-)
16:11:05 <dhellmann> some projects do already have this sort of thing in their developer docs, but since we have a bunch of repositories the specs repo seemed like a more natural place
16:11:16 <ihrachyshka> +1 for other projects doing the same thing. wiki is obsolete.
16:11:20 <bnemec> Yeah, I've made some policy edits to the wiki that it would have been nice to review.
16:11:32 <ihrachyshka> neutron has devref section for dev docs
16:11:32 <bnemec> But there's not really a way to do that there.
16:11:33 * dhellmann nods
16:11:40 <ihrachyshka> but it's like 5% of what we have
16:12:34 <dhellmann> yeah, I feel like we do a bit more explaining "why" we do things than other projects do, so we may have more of these
16:12:46 <amotoki> oslo consists of many libs, so it sounds reasonable we have docs in specs.
16:13:33 <dhellmann> ok, another planning-related topic came up late last week
16:13:38 <dhellmann> #topic summit planning
16:13:45 <dhellmann> yes, we need to start thinking about this already
16:13:53 <dhellmann> It's early, but we need to start planning for the amount of space we'll need at the summit.
16:13:59 <dhellmann> The summit organization will be a little different this time:
16:14:05 <dhellmann> #link http://lists.openstack.org/pipermail/openstack-dev/2015-January/054122.html
16:14:13 <dhellmann> There will be "fishbowl" rooms with large numbers of chairs for discussions, "boardroom" style rooms for priortization and doing work, and sprinting space on Friday.
16:14:15 <dhellmann> We need to decide on the mix of room sizes and purposes.
16:14:22 <dhellmann> Oslo didn't do any sprinting in Paris, because everyone was involved in the work going on for other projects on that day.
16:14:27 <dhellmann> Since a lot of what we do affects other groups, I suspect we will want more fishbowl rooms.
16:14:33 <dhellmann> But I'm sure some of the teams like oslo.db and oslo.messaging could take advantage of the boardoom style rooms for planning as well.
16:14:51 <dhellmann> ttx didn't give a deadline for reporting back, but we should work quickly
16:15:33 <dhellmann> I wanted to mention it here, and get some initial thoughts from you all, but we'll probably need to move to the mailing list.
16:15:49 <dhellmann> #action dhellmann start a mailing list thread for summit room planning
16:16:15 <dhellmann> the first question, I guess is, would sprinting time be valuable? would anyone be there?
16:16:35 <dhellmann> actually, that's the second question. The first question, is who is planning to be in Vancouver? :-)
16:16:43 <harlowja_at_home> afaik me :-P
16:17:06 <bnemec> Planning to, but don't know for sure yet.
16:17:08 <jungleboyj> dhellmann: me, me!
16:17:09 <ihrachyshka> I guess me, but that's not decided yet
16:17:26 <bknudson> I'm planning to be there.
16:17:28 * jungleboyj will try to make more Oslo sessions this time.
16:17:42 <zzzeek> o/
16:18:07 <dhellmann> knowing how many and what types of rooms also pre-supposes that we know what we're going to be doing during the next cycle
16:18:09 <ihrachyshka> zzzeek, will you be on summit?
16:18:13 <zzzeek> ihrachyshka: most likely
16:18:18 <dhellmann> so you should all be thinking about that, too :-)
16:18:21 <ihrachyshka> coool
16:18:33 <harlowja_at_home> are we gonna be in the basement again? lol
16:18:49 <bknudson> I think we're upstairs
16:18:52 <harlowja_at_home> woot
16:19:05 <bknudson> there's a map of the venue ...
16:19:10 * harlowja_at_home was sad that they put us in the basement without our red staplers
16:19:23 * ihrachyshka notes that he is especially interested in getting some understanding of what oslo.versionedobjects is about and how it relates to neutron, so I would be glad to have some quick coding/code reading session with someone behind it
16:19:38 <dhellmann> ihrachyshka: the lead for that is dansmith
16:19:45 <bnemec> Ooh, yeah.  We should rope dan into a session this summit.
16:20:03 <dhellmann> bnemec: can you use your special red hatter influence to do that? :-)
16:20:26 <bknudson> https://www.openstack.org/summit/vancouver-2015/venue-maps-2/
16:20:27 <bnemec> Heh, I can try.
16:20:44 * dansmith notes to be extra difficult to make it worth bnemec's time
16:20:49 <bknudson> design summit is on level 2
16:21:04 <dhellmann> dansmith: but think of all the new reviewers you'll attract! :-)
16:21:10 <dansmith> heh
16:21:10 <dhellmann> bknudson: cool, thanks
16:21:37 <bnemec> That would probably be a fishbowl session, IMO
16:21:54 <dhellmann> I've been waiting until we have an official name for the next cycle to create an etherpad for planning, but I'll send email to the dev list as soon as that's up.
16:22:18 <dhellmann> And then we'll do what we did last time, and put ideas in the etherpad and see where we have overlap and what style of sessions we need
16:22:21 <dhellmann> bnemec: ++
16:23:08 <dhellmann> moving on...
16:23:09 <dhellmann> #topic Red flags for/from liaisons
16:23:25 <bknudson> nothing from keystone... things seem to be going smoothly.
16:23:28 <dhellmann> we have several releases queued up for this week, so be on the lookout
16:23:42 <dhellmann> I need to verify that those libs are capped in the juno requirements list before releasing
16:24:13 <dhellmann> I have oslo.db, oslo.utils, oslo.messaging and oslotest down for releases
16:24:20 <ihrachyshka> neutron adopted new oslo_* namespaces.
16:24:29 <ihrachyshka> we would like to see oslo.policy released earlier
16:24:30 <dhellmann> \o/
16:24:34 <ihrachyshka> so that we have time to consider it
16:24:47 <bnemec> Nothing that I know of for tripleo.  Probably need to look into whether all of our stuff is switched off namespaces.
16:24:48 <dhellmann> it's not ready for use yet, but it should be coming soon
16:24:51 <bnemec> Which it's probably not.
16:25:01 <bknudson> on that note (about capping in stable/), this change in oslo.i18n seems to be in an odd place: https://review.openstack.org/#/c/147262/
16:25:02 <ihrachyshka> (we wanted to check since it's a bunch of security related code and we don't want to maintain it if we have an option to get rid of it)
16:25:39 <jungleboyj> Not issues from Cinder.  Just need to wrap up the updates for namespace and getting latest incubator code over.
16:25:48 <ihrachyshka> bknudson, re this error, it's known to stable maintainers
16:25:52 <ihrachyshka> and we're working on it
16:26:04 <bknudson> ihrachyshka: ok, thanks.
16:26:05 <ihrachyshka> but it's currently a mess and requires multiple patches to merge to cap misc version
16:26:23 <dhellmann> bknudson: yes, that is odd, good catch
16:26:27 <ihrachyshka> details in https://etherpad.openstack.org/p/stable-tracker if you care
16:26:32 <dhellmann> bknudson: we should move the fixture before releasing it
16:27:57 <dhellmann> oh, that's not merged, we can fix it before we land it
16:28:28 <dhellmann> dimsum__: want to remove your +2a on https://review.openstack.org/#/c/147262/ ?
16:29:14 * dhellmann is confused
16:29:25 <bknudson> my only issue with https://review.openstack.org/#/c/147262/ is that it's not passing jenkins.
16:29:28 <dhellmann> bknudson: when you say "an odd place" what do you mean? I thought you were talking about the filename?
16:29:35 * dhellmann needs more tea
16:29:37 <dimsum__> dhellmann: done
16:29:59 <bnemec> In oslo.concurrency we put the fixture in its own directory: https://github.com/openstack/oslo.concurrency/blob/master/oslo_concurrency/fixture/lockutils.py
16:30:02 <dhellmann> ihrachyshka: so is there a patch to fix the issue with that test somewhere?
16:30:03 <bknudson> and I didn't know what the jenkins problem was, but apparently it's known
16:30:15 <ihrachyshka> dhellmann, not really, oslo.config issue is not resolved yet
16:30:23 <ihrachyshka> I'll check with apevec on whether there are updates
16:30:32 <ihrachyshka> atm juno is kinda broken
16:30:37 <ihrachyshka> that's what it is :)
16:30:48 <dhellmann> ihrachyshka: I thought we landed a patch to cap pycadf
16:31:34 <dhellmann> https://review.openstack.org/151770
16:31:42 <dhellmann> something there failed jenkins
16:31:59 <ihrachyshka> yeah, it all goes to oslo.config issue
16:32:11 <ihrachyshka> getting: pkg_resources.ContextualVersionConflict: (oslo.config 1.4.0 (/usr/local/lib/python2.7/dist-packages), Requirement.parse('oslo.config>=1.6.0'), set(['tempest-lib']))
16:32:13 <dhellmann> ihrachyshka: so we need to cap oslo.config, too?
16:32:22 <dhellmann> oh, tempest-lib
16:32:24 <dhellmann> wow
16:32:31 <ihrachyshka> I think it's capped, but tempest-lib requires new one
16:32:43 <ihrachyshka> I'll update you via email
16:32:57 <dhellmann> ihrachyshka: yeah, please, on the -dev list so we can sort it out
16:32:59 <bknudson> tempest-lib should get their own tox env.
16:33:10 <dhellmann> bknudson: probably true
16:33:50 <ihrachyshka> dhellmann, ack
16:34:07 <ihrachyshka> bknudson, there is a patch for that somewhere (or was it just for tempest?)
16:34:23 * dhellmann misses using alpha versions
16:34:34 <ihrachyshka> https://review.openstack.org/#/c/153702/
16:34:55 <ihrachyshka> yeah, so I guess we need to start unwrapping it from tempest-lib
16:35:00 <bknudson> nice, thanks.
16:35:25 <dhellmann> ihrachyshka: thanks, I'll see what I can do to help
16:35:41 <bknudson> at this point it appears that master oslo.i18n is blocked...
16:35:51 <bknudson> not sure if every oslo.* is blocked?
16:36:13 <dhellmann> yeah, and I wonder if we should hold off on those releases to make sure we don't make things worse until we can unblock the stable requirements list and cap all of our libs
16:36:35 <dhellmann> ihrachyshka: it looks like jogo is working on this, is there a team working together?
16:37:42 <ihrachyshka> dhellmann, no idea who is jogo
16:37:47 <dhellmann> ihrachyshka: joe gordon
16:38:11 <ihrachyshka> not that I aware of any work done in this area other than apevec looking into it
16:38:12 <dhellmann> I'll catch up with him later today, I don't see him in channel
16:38:16 <ihrachyshka> thanks
16:38:16 <dhellmann> ok
16:38:45 * ihrachyshka feels guilty for not having time today to resolve it myself
16:39:32 <dhellmann> one more topic on our agenda...
16:39:32 <dhellmann> #topic Ongoing work & Review priorities
16:39:54 <dhellmann> #link https://launchpad.net/oslo/+milestone/next-kilo
16:39:54 <dhellmann> #link https://launchpad.net/oslo/+milestone/kilo-3
16:39:54 <dhellmann> Aside from the stable/juno issues, is anyone blocked on work we prioritized for this release because of reviews?
16:40:25 <bnemec> I would still like to get https://review.openstack.org/#/c/148020/ in ASAP.
16:40:25 <ozamiatin> dhellmann, hi
16:40:47 <bnemec> I assume there's going to be another round of culling deprecated opts next cycle, so the sooner we're notifying people about them the better.
16:40:52 <dhellmann> bnemec: yep
16:41:39 <ozamiatin> dhellmann, please take a look at some of my specs on zmq driver https://review.openstack.org/154094, https://review.openstack.org/150735, https://review.openstack.org/151185
16:42:12 <dhellmann> ozamiatin: sure. We'll need to get sileht's feedback on those, too.
16:42:27 <ozamiatin> dhellmann, sure, thanks!
16:43:02 <ozamiatin> dhellman, We still have this bug on devstack https://bugs.launchpad.net/oslo.messaging/+bug/1395721, I'm trying to fix it
16:43:03 <openstack> Launchpad bug 1395721 in oslo.messaging "Devstack nova-compute fails with ZeroMQ" [Undecided,Confirmed] - Assigned to Oleksii Zamiatin (ozamiatin)
16:43:42 <ozamiatin> dhellmann, https://review.openstack.org/#/c/154094/ - this is my vision how to do that more elegant)
16:44:17 <sileht> ozamiatin, I have setuped into a experimental job with zeromq functionnal tests
16:44:34 <sileht> (with redis)
16:44:35 <dhellmann> ozamiatin: you will also want to get some of the other zmq contributors to review those specs
16:45:25 <ozamiatin> sileht, redis is ok, but it is timeout with nova
16:45:52 <ozamiatin> sileht, I've mentioned in the comments
16:46:01 <ihrachyshka> btw I've reported a bug in redis driver that also failed in stable gate. https://bugs.launchpad.net/oslo.messaging/+bug/1419718
16:46:01 <openstack> Launchpad bug 1419718 in oslo.messaging "matchmaker_redis: ack_alive fails with KeyError on re-registration attempt" [Undecided,New]
16:46:06 <ihrachyshka> you may be interested to check
16:46:41 <ozamiatin> ihrachyshka, thanks! I'll check it
16:47:28 <sileht> ozamiatin, ihrachyshka, making the funcionnal tests suite passing gate should help a lot the zeromq driver developement
16:47:29 <dhellmann> #topic open discussion
16:47:36 <dhellmann> does anyone have anything else to bring up this week?
16:48:26 <ihrachyshka> https://review.openstack.org/153216
16:48:38 <ihrachyshka> I'd like to hear more from reviewers
16:49:00 <ihrachyshka> there is disagreement on which guarantees oslo libs should provide for imports
16:49:18 <ihrachyshka> bnemec already commented on it, but I'd like to see more votes
16:49:43 <bnemec> Oh, my issue there is that supporting this behavior allows projects to use racy eventlet monkey patching.
16:49:49 <dhellmann> ihrachyshka: is your change backwards compatible?
16:50:04 * dhellmann hasn't read it all yet
16:50:08 <sileht> bnemec, I agree
16:50:37 <dhellmann> ugh, eventlet
16:50:42 <ihrachyshka> bnemec, shouldn't we allow oslo libs to be imported before neutron stuff? (we even have hacking checks for that)
16:50:42 <sileht> bnemec, in oslo.messaging with just print an error message to inform developer about the racy monkey patching
16:50:43 <bnemec> I talked to otherwiseguy about how to make the monkey patching safe on Friday.
16:50:47 <sileht> with/we
16:51:18 <ihrachyshka> bnemec, we work on this in neutron, but I also think it's worth fixing in the lib too
16:51:21 * dhellmann wishes we could just switch to threads and be done with monkeypatching
16:51:25 <sileht> ihrachyshka, monkeypatch must be done before loading anything, this is the recommandation
16:51:29 * bnemec agrees
16:51:46 <bnemec> If you run code, monkey patch, then run other code, you're in undefined behavior territory.
16:51:55 <harlowja_at_home> https://review.openstack.org/#/c/149730/ might be useful for folk also
16:51:55 <ihrachyshka> sileht, so we need to make all external consumers of neutron and oslo code to explicitly monkey patch
16:52:09 <harlowja_at_home> dhellmann, i agree, the madness this causes is a PITA
16:53:19 <ihrachyshka> sileht, because relying on neutron/__init__.py to patch it is not enough (it's imported after oslo)
16:53:20 <dhellmann> ihrachyshka: I think you're right. We expect the calling application to be doing the monkeypatching.
16:53:29 <otherwiseguy> I personally don't see the harm in having the library handle it. Robustness is always preferable if it doesn't have an associated cost. The cost in this case is kind of etherical slippery-slope kinds of things.
16:53:33 <bnemec> I also suggested that we should have an "eventlet sanity" cross-project spec that rolls up the best practices we've come up with so far.
16:53:39 <dhellmann> ihrachyshka: no, the main program script may have to do it, or you may have to change the import order
16:53:48 <dhellmann> bnemec: good idea
16:53:53 <harlowja_at_home> bnemec, +1
16:53:57 <sileht> bnemec, +1
16:54:04 <bknudson> harlowja_at_home: where is https://review.openstack.org/#/c/149730/ supposed to be used? in keystone for example?
16:54:08 <ihrachyshka> dhellmann, import order is sometimes controlled by hacking, so - explicit onlyt
16:54:08 <amotoki> bnemec: +1
16:54:23 <dhellmann> ihrachyshka: we may have to change the hacking rules then
16:54:39 <dhellmann> those style rules are to make code readable, but if it makes readable broken code what's the point?
16:54:53 <harlowja_at_home> bknudson, in libraries, when the library is imported, to at least give the user a warning that if certain things aren't patched the library may be all wonky...
16:54:58 <bknudson> there's no good way to use eventlet.
16:55:02 <ihrachyshka> + for policy spec, that would help (neutron is one of projects who would benefit from it, since atm we monkey patch ourselves like monkeys without clear understanding of why it's done this way)
16:55:17 <bknudson> harlowja_at_home: ok, thanks... so not in keystone.
16:55:27 <harlowja_at_home> bknudson, i think so
16:56:53 <sileht> harlowja_at_home, bknudson oslo.messaging can consume this, It always have sanity check around monkeypatch stuffs
16:57:13 <sileht> always/already
16:57:58 <harlowja_at_home> ya, a 'eventlet sanity' (combination of words there might not be sane) spec would help also
16:58:00 <bknudson> keystone can run in eventlet or non-eventlet, and uses oslo.messaging.
16:58:10 * bnemec proposes an oslo.sanity library
16:58:34 <ihrachyshka> neutron won't consume it, ever!
16:58:45 <dhellmann> bnemec: does eventlet not patch subprocess by default, or does it not patch it at all?
16:58:46 <harlowja_at_home> bknudson, what executor of oslo.messaging are u using in the non-eventlet case?
16:59:06 <bnemec> dhellmann: It doesn't patch subprocess at all, IIRC.
16:59:12 <dhellmann> k
16:59:13 <ihrachyshka> dhellmann, I think it's 'threading' that is patched
16:59:13 <bnemec> It's not even an option for monkey_patch
16:59:13 <bknudson> harlowja_at_home: this isn't something I've ever looked into ....
16:59:19 <dhellmann> we're about out of time
16:59:21 <harlowja_at_home> bknudson, k
16:59:30 <dhellmann> bknudson: I'd be interested in hearing about how you set up keystone without eventlet, too
16:59:45 * dhellmann hopes for a blog post
16:59:50 <harlowja_at_home> :)
17:00:04 <dhellmann> ok, good meeting again this week, everyone
17:00:06 <dhellmann> thanks!
17:00:09 <sileht> harlowja_at_home, eventlet executor work even without monkeypatching, greenthread blocks when IO occurs that all
17:00:25 <sileht> dhellmann, nova/cinder-api works well too
17:00:25 <dhellmann> ah
17:00:39 <harlowja_at_home> sileht, except i can cause that to freeze up pretty easily, just use a thread lock somewhere in an eventlet thread and poof
17:00:43 <dhellmann> sileht: it would be interesting to set up a POC with the threaded executor
17:00:56 <dhellmann> we need to clear the meeting room
17:01:01 <dhellmann> let's move to #openstack-oslo
17:01:04 <dhellmann> #endmeeting