16:00:13 <dhellmann> #startmeeting oslo
16:00:13 <dhellmann> #link https://wiki.openstack.org/wiki/Meetings/Oslo
16:00:15 <openstack> Meeting started Mon Feb 23 16:00:13 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:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:18 <openstack> The meeting name has been set to 'oslo'
16:00:21 <jungleboyj_> o/
16:00:22 <dhellmann> courtesy ping for jd__, dims, bnemec, flaper87, harlowja, viktors, rpodolyaka, zzzeek, sileht, kgiusti, dansmith
16:00:22 <dhellmann> courtesy ping for redrobot, jungleboyj, zhiyan, therve, amotoki, GheRivero, bknudson, ihrachyshka, jogo, dougwig, sreshetnyak, amrith
16:00:24 <rpodolyaka> o/
16:00:25 <bknudson> hi
16:00:30 <kgiusti> o/
16:00:31 <jecarey> o/
16:00:32 <bnemec> o/
16:00:53 <dansmith> I'm here, but on another call
16:00:53 <ozamiatin> o/
16:01:08 <flaper87> o/
16:01:12 <sileht> o/
16:01:27 <flaper87> have I said enough I thank infinitely this courtesy pings?
16:01:30 <flaper87> these*
16:01:40 <dhellmann> flaper87: I stole that idea from ttx
16:02:04 <dstanek> hi
16:02:30 <jungleboyj_> It is a good one.
16:02:38 <bnemec> +1
16:03:01 <dhellmann> #topic Review action items from previous meeting
16:03:06 <dhellmann> #info dhellmann set up specs repo to accept liberty specs - DONE
16:03:09 <flaper87> ttx:++
16:03:23 <dhellmann> our specs repo is set up to receive proposals for the liberty cycle
16:03:27 <ihrachyshka> o/
16:03:29 <amrith> o/
16:03:41 <dhellmann> if you had an idea for a summit session that warrants a spec, please submit one before we start reviewing session proposals
16:03:47 <dhellmann> #topic Red flags for/from liaisons
16:03:59 <dhellmann> how are things looking this week?
16:04:08 <ihrachyshka> dhellmann, we need new oslo.db release to apply retry decorator in neutron
16:04:10 <bknudson> haven't seen any issues in keystone.
16:04:33 <dhellmann> ihrachyshka: we're waiting for the current gate issue to settle down and for a fix in nova, but that is a high priority for us this week
16:04:34 * bknudson wonders about oslo.policy status.
16:04:38 <jungleboyj> Good.  I have many patches up to get Cinder's incubator code updated.  Going to wrap that up this week.
16:04:48 <jungleboyj> Then moving to oslo.log.
16:04:53 <jungleboyj> Library.
16:04:53 <amrith> quick update from trove land. we had been using several old (graduated and obsolete) libraries. we are now almost current (TM)
16:05:06 <amrith> another oslo sync pre-kilo is planned
16:05:07 <dhellmann> bknudson: we identified some missing API components when we reviewed the changes in keystone, so we will need another release before we make a public release. See my comments on the keystone review
16:05:16 <jungleboyj> I like it:   almost current (TM)
16:05:17 <dhellmann> jungleboyj: ++
16:05:23 <ihrachyshka> also it would be great if someone chime in at neutron review at: https://review.openstack.org/155412 and confirm it's a correct step in making eventlet usage not insane
16:05:28 <dhellmann> amrith: \o/
16:05:43 <jungleboyj> Has anyone moved to using the config generator from the oslo.config library?
16:05:52 <bknudson> eventlet usage is generally insane.
16:05:53 <dhellmann> ihrachyshka: bnemec is probably the best person to look at that
16:05:58 <amrith> almost current (TM) is part of my collection of similarly useful terms like "just works (TM)" ;)
16:06:05 <bknudson> jungleboyj: keystone uses config generator.
16:06:08 <dhellmann> jungleboyj: I believe so. Are you seeing issues?
16:06:27 <jungleboyj> bknudson: The new one in the oslo.config library?
16:06:29 <ihrachyshka> bknudson, ok, less insane
16:06:31 <bknudson> jungleboyj: yes.
16:06:37 <jungleboyj> bknudson: Cool.
16:06:48 <inc0> hello all, have you closed agenda already?
16:06:58 <jungleboyj> dhellmann: No, just wanted to an example to work from to make sure I was going in the right direction.  :-)
16:07:44 <dhellmann> jungleboyj: cool
16:07:52 <dhellmann> inc0: we should have an open discussion session at the end of the meeting
16:07:55 <jungleboyj> :-)
16:08:33 <dhellmann> any other reports from liaisons?
16:09:01 <bnemec> ihrachyshka: It sounds reasonable.  I'll take a closer look after the meeting.
16:09:23 <ihrachyshka> bnemec++
16:09:57 <dhellmann> let's keep moving
16:10:00 <dhellmann> #topic Releases for this week
16:10:09 <dhellmann> we have quite a backlog, prepare for pastebomb
16:10:18 <dhellmann> #link http://paste.openstack.org/show/178644/
16:10:19 <dhellmann> #info oslo.concurrency stops using namespace package for oslo.i18n
16:10:20 <dhellmann> #info oslo.config has a fix to remove a lot of deprecation warnings
16:10:21 <dhellmann> #info oslo.db was delayed from last week
16:10:22 <dhellmann> #info oslo.log also removes namespace package imports
16:10:23 <dhellmann> #info oslo.messaging was delayed from last week
16:10:24 <dhellmann> #info oslo.middleware has a packaging fix
16:10:25 <dhellmann> #info oslo.vmware has several bug fixes
16:10:26 <dhellmann> #info oslotest now uses a higher maxDiff value
16:10:36 <dhellmann> the oslo.db release is known to break nova right now, so rpodolyaka and sdague are looking into that
16:11:02 <dhellmann> sileht: how is oslo.messaging looking, is that ready or is there something you think we'll land today that we need?
16:11:17 <bnemec> oslo.config logs deprecated options \o/
16:11:33 <dhellmann> fwiw, that pastebin with the changes was prepared friday, so it may be slightly out of date if we merged anything over the weekend
16:11:37 <sileht> dhellmann, I think yes (just comeback from vacation)
16:12:04 <dhellmann> sileht: ok, are you going to be around for a bit after the meeting to check before I release it? I know we have at least one project waiting on it.
16:12:22 <sileht> dhellmann, yes
16:12:27 <dhellmann> I'll be holding off until the gate looks clear, so we have a little time
16:12:42 <dhellmann> sileht: ok, thanks, can you let me know in #openstack-oslo?
16:13:32 <sileht> sure
16:13:33 <dhellmann> as far as I can tell, all of the others are ready to go
16:13:35 <dhellmann> sileht: thanks
16:14:03 <dhellmann> liaisons, keep an eye out for unit tests breaking in your apps as the releases roll out today and tomorrow
16:14:17 <ihrachyshka> ack
16:14:18 <dhellmann> #topic summit planning
16:14:19 <dhellmann> #link https://etherpad.openstack.org/p/liberty-oslo-summit-planning
16:14:42 <dhellmann> we're up to 18 topics, which is likely to mean some merging or dropping
16:14:55 <dhellmann> but please don't let that stop you from adding something to the list
16:15:07 <dhellmann> the room allocations aren't set yet, and I've put in a request but can change it, I think
16:15:24 <harlowja_at_home> \o i made its! ha
16:15:37 <dhellmann> again, don't forget to file a spec if it's appropriate for your session
16:16:18 <dhellmann> are there any questions or comments about the summit planning?
16:17:24 <dhellmann> ok, moving on then
16:17:25 <dhellmann> #topic Ongoing work & Review priorities
16:17:26 <dhellmann> #link https://launchpad.net/oslo/+milestone/next-kilo
16:17:26 <dhellmann> #link https://launchpad.net/oslo/+milestone/kilo-3
16:17:26 <dhellmann> Is anyone blocked on work we prioritized for this release?
16:17:53 <harlowja_at_home> not me
16:18:06 <dhellmann> we have several in-progress bugs under next-kilo that look like they could use reviews
16:18:42 <dhellmann> harlowja_at_home: how's the debtcollector blueprint coming along, are those infra and devstack-gate patches moving through?
16:19:39 <harlowja_at_home> dhellmann, oh good point; they are moving i think, slowly but surely
16:19:48 <dhellmann> harlowja_at_home: ok, cool
16:20:11 <harlowja_at_home> i'll poke some devstack people today, might make it move  faster
16:20:57 <dhellmann> let's see if we can close out some of the in-progress bugs this week
16:21:13 <dhellmann> other than that, I think we're looking pretty good for this point in the cycle
16:21:19 <harlowja_at_home> did we decide want to decide on the https://review.openstack.org/#/c/157608/ (??) or similar, or let that get discussed some more
16:21:43 <dhellmann> harlowja_at_home: good question. We need to talk about that more on the mailing list, I think.
16:21:48 <harlowja_at_home> k
16:22:02 <bknudson> fds should default to CLOEXEC.
16:22:17 <dhellmann> bknudson: yeah, the service code doesn't exec though
16:22:22 <dhellmann> it just forks
16:22:33 <dhellmann> it's creating worker processes, I think
16:22:55 <dhellmann> so rather than running N copies of a service as separate commands, you configure how many workers you want and it forks to create them
16:23:02 <bknudson> ahh...
16:23:28 <bknudson> https://review.openstack.org/#/c/157608/ seems like a good idea then.
16:23:29 <dhellmann> I liked the suggestion of building a new version of the service base class that uses subprocess and does some other smarter things, so we can have a different API
16:24:04 <bknudson> (could use a test!)
16:24:22 <dhellmann> bknudson: one issue with that is that in some cases we know "safe" ways to close those sockets, and so it would be better to use those routes or never open the connection until after the fork
16:24:55 <bnemec> Would https://review.openstack.org/#/c/157608/ work as a "for now" solution and then we can rearchitect Service at our leisure?
16:25:02 <dhellmann> harlowja_at_home: have you tried putting that code into any of the other projects as a test?
16:25:09 <bnemec> Yeah^
16:25:12 <harlowja_at_home> not yet :-/
16:25:24 <bnemec> I'm a little worried that services might be relying on the bad behavior.
16:25:26 <dhellmann> ok, we should definitely do that before we land it in the incubator
16:25:38 <dhellmann> the incubator tests do not exercise some of that code as well as the devstack tests will
16:25:40 <harlowja_at_home> agreed
16:25:47 <dhellmann> bnemec: right
16:26:11 <harlowja_at_home> https://hg.python.org/releasing/2.7.9/file/753a8f457ddc/Lib/multiprocessing/util.py#l161 (do people know if that public); this is the registry of after fork things...
16:26:32 <dims> o/ sorry for the delay
16:27:37 <dhellmann> harlowja_at_home: I don't see it in the docs, so I don't think so.
16:28:30 <dhellmann> the fundamental issue with the service code is it takes a Manager instance as argument, and the Manager is holding an open database connection. That means the script that creates the service has already connected to the database by the time it asks to fork.
16:29:30 <dhellmann> someone suggested we replace that fork() with having systemd launch multiple copies, but that's not a backwards-compatible change so I don't know what we'd need to do to move to that
16:29:42 <dhellmann> someone else suggested using multiprocessing, which would close the descriptors for us
16:29:57 <dhellmann> but I also think we should think about whether we can avoid having the connection opened before the fork in the first place
16:30:21 <harlowja_at_home> agreed
16:30:33 <bknudson> it's weird that register_after_fork() isn't documented... seems handy
16:30:37 <bknudson> used internally?
16:31:36 <dhellmann> bknudson: yeah, I think so
16:31:49 <dhellmann> there's no docstring, which is a pretty big signal that it's meant for internal use
16:32:24 <dhellmann> we can finish that conversation on the mailing list
16:32:26 <dhellmann> #topic open discussion
16:32:30 <dhellmann> inc0: you had something to bring up?
16:32:39 <inc0> yeah, versionedobjects release
16:33:02 <inc0> dansmith, any plans for that? anything we can do to accelerate it?
16:33:30 <dansmith> inc0: I'm working on the namespacing issue that will impact nova right now
16:33:30 <inc0> we have patches for cinder and heat waiting:)
16:33:59 <inc0> ah, I was thinking to takie it, wanna help with this one?
16:34:03 <dims> any liaisons looking at oslo.log usage?
16:34:08 <dansmith> inc0: I think that is the last thing I need to do
16:34:24 <bknudson> dims: oslo.log use is already merged in keystone
16:34:32 <inc0> we're going to fill README and so on
16:34:33 <dims> bknudson: thanks!
16:34:34 <dhellmann> dims: how's that nova patch, did that merge?
16:34:40 <dansmith> dhellmann: is the plan to mark this first release as "alpha" or something in case we hit something that needs a breaking change?
16:34:42 <dims> dhellmann: y last night
16:34:44 <inc0> there are few things like that
16:34:48 <bknudson> dims: thank stevemar
16:35:10 <dhellmann> dansmith: for oslo.policy and oslo.log we did a soft 0.1.0 release without an announcement so we could test integration patches. We can do the same for versionedobjects
16:35:20 <dansmith> dhellmann: I think everyone getting ready to consume this is aware that it's a thing to keep track of
16:35:22 <dims> dansmith: dhellmann: yes, +1
16:35:24 <jungleboyj> dims: We have a patch up to use it.  I just need to get incubator cleaned up first.
16:35:25 <dansmith> dhellmann: cool, let's do that
16:35:38 <jungleboyj> dims: Hope to be moving to it in the next week or two.
16:35:59 <dims> jungleboyj: cool
16:36:13 <dhellmann> dansmith: we can prevent projects from fully adopting it by leaving it out of the global requirements list
16:36:19 <ihrachyshka> btw I forgot to mention that I attempt to introduce common oslo_* namespace checks in hacking: https://review.openstack.org/157894
16:36:43 <dims> ihrachyshka: nice segway, nova is totally clean now of namespaces!
16:36:51 <dims> "Segue"
16:37:05 <dhellmann> ihrachyshka: ok
16:37:21 <dhellmann> dims: very good, even some of the oslo libs aren't clean yet :-)
16:37:29 <dims> :)
16:37:34 <ihrachyshka> the idea is to have two checks - one for stable, another one for kilo+
16:37:50 <ihrachyshka> hacking bumps are explicit, so not a problem
16:38:16 <inc0> I just want to have it asap so we can have review going
16:38:22 <dhellmann> ihrachyshka: do we ever update the version of hacking used in stable branches?
16:38:27 <inc0> to merge as much as possible in kilo
16:38:57 <ihrachyshka> dhellmann, with those checks, we will (to be able to consume it) though I expect us to disable any new checks other than oslo one
16:39:08 <dhellmann> inc0: I'm not sure we set a goal of wide adoption during kilo.
16:39:19 <dhellmann> ihrachyshka: ok
16:39:25 <ihrachyshka> dhellmann, btw we already got an issue due to a backport with new namespaces
16:39:28 <bnemec> Only patch version updates can go into stable branches.
16:39:34 <ihrachyshka> dhellmann, so I decided to be proactive before we merge more
16:39:44 <dhellmann> ihrachyshka: I saw something about that, where was it? One of the clients, right?
16:39:53 <ihrachyshka> dhellmann, nope, server. a sec
16:40:08 <inc0> dhellmann, many projects wants to have versionedobjects implemented somwhere else before they implement these themselves
16:40:12 <ihrachyshka> https://bugs.launchpad.net/cinder/+bug/1420335
16:40:14 <openstack> Launchpad bug 1420335 in Cinder "cinder is testing with non-namespaced oslo_i18n in Juno" [Medium,In progress] - Assigned to John Griffith (john-griffith)
16:40:18 <dhellmann> inc0: and I want to get it right, so we're not going to rush
16:40:28 <ihrachyshka> bnemec, that's negotiable, we have a good case to actually bump
16:40:44 <dims> sileht: dhellmann: one more from me, i was trying to remove rpc aliases and ran into issues with grenade (https://review.openstack.org/#/c/158169/). discussion with sdague, raised a question, do we generate DeprecationWarning for old aliases in config files?
16:41:07 <inc0> dhellmann, sure thing:) but forgive me if I remind that every few days;)
16:41:15 <ihrachyshka> dims, why do we remove those?
16:41:24 <dhellmann> inc0: really, we're working on it, so there's no need to do that :-)
16:41:36 <dims> ihrachyshka: there are no nova modules of that name anymore
16:41:44 <inc0> I know I know, dont blame me for excitement :(
16:41:49 <dhellmann> dims: I don't think we ever put anything in place to emit deprecation
16:41:51 <dhellmann> inc0: :-)
16:42:04 <ihrachyshka> dims, that's fine, but this does not mean anything, afaik aliases are for backwards compatibility
16:42:14 <ihrachyshka> dims, so they are just converted into proper values
16:42:35 <dims> ihrachyshka: i know, trying remove old cruft
16:42:45 <ihrachyshka> dims, it does not look like a piece of code of hard maintenance, so better leave for compat
16:43:00 <ihrachyshka> dims, potentially breaking someone
16:43:01 <dhellmann> dims: I guess we would need to add something to oslo.messaging to log a warning if one of those alias names is used?
16:43:11 <dims> dhellmann: correct
16:43:11 <sileht> dims, dhellmann +1
16:43:15 <dims> dhellmann: so we can remove later
16:43:23 <ihrachyshka> +1
16:43:31 <ihrachyshka> no removal before a cycle of warnings I guess
16:43:36 <dims> yep
16:43:38 <bnemec> can we convert the aliases to deprecated opts?
16:43:58 <dhellmann> sileht: I thought at some point we had those names in the oslo.messaging setup.cfg. Am I thinking of something else?
16:44:00 <dims> bnemec: that would work for keys not values
16:44:17 <bnemec> dims: Ah, okay
16:44:27 * bnemec is hearing about this for the first time
16:44:36 <dhellmann> dims: we should probably have a bug to track this
16:44:53 <dims> dhellmann: i was poking at it this AM, will open a bug
16:45:01 <dhellmann> sounds good
16:45:18 <dhellmann> is there anything else we need to discuss this week?
16:45:57 <dhellmann> if not we can stop a few minutes early and spend time reviewing patches :-)
16:46:20 <dims> yay :)
16:46:27 <dhellmann> ok, thanks everyone!
16:46:30 <amrith> thx dhellmann
16:46:30 <dhellmann> #endmeeting