16:00:04 <dims> #startmeeting oslo
16:00:04 <dims> courtesy ping for GheRivero, amotoki, amrith, bknudson, bnemec, dansmith, dhellmann, dougwig, e0ne, flaper87, garyk, harlowja, haypo,
16:00:05 <openstack> Meeting started Mon Jan 18 16:00:04 2016 UTC and is due to finish in 60 minutes.  The chair is dims. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:05 <dims> courtesy ping for ihrachyshka, jd__, jecarey, johnsom, jungleboyj, kgiusti, kragniz, lifeless, lintan, ozamiatin, redrobot, rpodolyaka, spamaps
16:00:05 <dims> courtesy ping for sergmelikyan, sreshetnyak, sileht, sreshetnyak, stevemar, therve, thinrichs, toabctl, viktors, zhiyan, zzzeek, gcb
16:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:08 <openstack> The meeting name has been set to 'oslo'
16:00:10 <kgiusti> o/
16:00:12 <jecarey> 0/
16:00:15 <toabctl> hi
16:00:30 <jd__> hello
16:00:39 <bknudson_> hi
16:00:41 <rpodolyaka> o/
16:00:53 <dims> hi kgiusti jecarey toabctl jd__ bknudson_ rpodolyaka
16:00:58 <ozamiatin_> o/
16:01:00 <bknudson_> we actually don't have the day off here.
16:01:23 <dims> bknudson_ : aha
16:01:32 <dims> #topic Red flags for/from liaisons
16:01:42 <rbradfor> o/
16:02:05 <bknudson_> None for keystone -- I'm getting a little worried about some deprecated oslo.db stuff that we haven't fixed up yet... more of a yellow flag.
16:02:24 <ihrachys> none for neutron
16:02:33 * rpodolyaka wonders what we deprecated recently in oslo.db
16:02:35 <dims> bknudson_ : haven't been fixed in keystone?
16:02:45 <dims> rpodolyaka : probably the engine facade?
16:02:53 <bknudson_> yes, keystone has to change engine usage
16:02:53 <rpodolyaka> ah, yeah
16:03:11 <bknudson_> last time I looked at it there were no docs. I think there's docs now.
16:03:23 <rpodolyaka> the old version is going to stay for a while
16:03:37 <rpodolyaka> yeah, the action item is till on me to write a blog post on the new facade thing
16:03:47 <rpodolyaka> or simply docs
16:03:56 <dims> rpodolyaka : +1
16:04:09 * rpodolyaka adds it to todo list
16:04:39 <dims> #topic Releases for Mitaka
16:04:47 <dims> does anyone need a release this week?
16:05:08 <dims> dukhlov - was waiting on some docs for pika for o.m release
16:05:43 <flaper87> o/
16:05:48 <dims> hey flaper87
16:06:01 <flaper87> oh, that was to say hi
16:06:04 <flaper87> I don't need a release
16:06:06 <flaper87> :D
16:06:11 <dims> :)
16:06:18 * flaper87 should try ninja-entering meetings next time
16:06:23 <dims> #topic - releases for stable branches
16:06:53 <dims> i see a bunch of discussion over on glance, so thought we could spend a little time here as well
16:06:55 <dims> starting with an update from me
16:07:23 <dims> oslo has stable branches but has not released any library from the stable branches
16:07:26 <dims> so far
16:07:46 <bknudson_> couldn't call it stable if you kept doing releases.
16:07:53 <dims> the current CI has upper-constraints in stable branches that are uncapped
16:08:14 <dims> so any releases will not affect any tests in the CI and so we would not even know if we broke something
16:08:17 <bknudson_> so CI doesn't run with stable anyways
16:08:52 <dims> so mriedem and dhellmann and lifeless were trying to come up with a release-constraints file for stable/liberty
16:08:56 <dukhlov> dims: will do tomorrow, is it ok?
16:09:06 <dims> and figure out a test matrix that will run against that
16:09:10 <dims> dukhlov : +1
16:09:28 <dims> once that's in place we can make stable/liberty library releases
16:10:25 <dims> so we'll end up with a set of oslo libraries cut from stable/liberty and a set of oslo libraries from master, both of which should not break say stable/liberty nova or keystone
16:10:40 <dims> per the openstack-spec in progress from lifeless
16:10:59 <dims> haypo, flaper87, makes sense?
16:11:34 <haypo> dims: what i see is that it becomes much harder to change anything in oslo
16:11:34 <dims> the idea is that packagers will still be able to use stable/liberty branches and corresponding libs and not have to pull from master
16:11:41 <haypo> dims: which is a real pain point for me
16:11:56 <dims> haypo : right that's a valid concern and one of my top problems as well
16:11:58 <haypo> dims: i don't understand the rationale behaviour always using the latest version of oslo for all openstack versions
16:12:07 <bknudson_> packagers already use old releases and don't always get from master.
16:12:25 <haypo> dims: for me, it's perfectly fine to stop at oslo.context < 2.0 on liberty (for example)
16:12:37 <dims> haypo : you need to respond on https://review.openstack.org/#/c/226157/
16:12:45 <dims> bknudson_ : right
16:12:59 <haypo> the problem is that it becomes really hard to estimate how much code will be broken if we change oslo and all openstack releases use the latest oslo versions
16:13:23 <dims> haypo : you should talk to mriedem on openstack-stable about the capping, he is in favor of it but it's very hard to do with experience from previous releases
16:13:35 <haypo> dims: i hesitate to qualify my change as a corner case, since it breaks the API
16:13:44 <bknudson_> you would like to be able to upgrade the libraries to master and then upgrade the servers, so it makes sense to want to support some backwards compat.
16:13:46 <dims> haypo : yes, that the next problem on my list which is being able to predict what we break
16:13:54 <haypo> dims: and an obvious alternative is to keep the old attribute and add a new one, as dhellmann suggested
16:14:48 <haypo> my point is that python3 is *not* used by anything, so it's cheaper to break the API than having the dead slow deprecation process ... which does *not* work (see multiple discussions on openstack-dev)
16:15:29 <dims> haypo : for this specific thing let's talk to dhellmann once more when he is around.
16:15:35 <bknudson_> keystone server doesn't support python3 yet.
16:15:43 <bknudson_> not sure if it even will in M.
16:15:43 <haypo> bknudson_: yeah, openstack products are kind of certified with a set of oslo versions
16:16:32 <haypo> bknudson_: since we don't run functional tests on python 3, it would be unsane to deploy openstack on python 3 today
16:16:40 <dims> bknudson_ : haypo : we should start with comments on the spec and follow up with discussion on openstack-stable with mriedem, etc
16:17:29 <dims> haypo : yes, for this change. i just want to be sure everyone else understands the implications for the rest of the work
16:18:06 <dims> let's get through one more item and then we can talk more
16:18:08 <dims> #topic Add failure remoting best-of-breed spec
16:18:09 <dims> #link https://review.openstack.org/#/c/229194/
16:18:12 <dims> harlowja : around?
16:18:25 <haypo> dims: the concrete impact of my oslo.context change https://review.openstack.org/#/c/250731/ is that i will break python3 gates of some projects
16:18:42 <dims> i need some eyes on this review please per harlowja's request
16:18:52 <bknudson_> the description sounds like a xkcd comic about standards.
16:19:26 <dims> bknudson_ : y commit message is funny, the actual spec is better :)
16:19:57 <dims> #topic Open discussion
16:19:57 <dims> Any other stuck reviews?
16:20:09 <rbradfor> I have a discussion point
16:20:31 <dims> haypo : do you want to ping PTL(s) about removing their python3 jobs in stable/liberty?
16:20:47 <ozamiatin_> dims: I've got these minor changes: https://review.openstack.org/#/c/268097/, https://review.openstack.org/#/c/268110/
16:21:08 <ozamiatin_> dims: And this big one, https://review.openstack.org/#/c/268792/ will get ready soon (pep8 etc)
16:21:09 <dims> haypo : you could get the ball rolling with a note on -dev.
16:21:20 <bknudson_> what's the problem with python3 jobs on stable/liberty?
16:21:25 <dims> ozamiatin_ : ack thanks, will add to my queue
16:21:31 <haypo> dims: i don't think that it's a good idea to remove py3 gates
16:21:46 <ozamiatin_> dims: thanks
16:22:00 <dims> haypo : so what's left is the slow deprecation process?
16:22:01 <haypo> dims: i just said it to explain that it will not impact anyone in practice, but it's usually a good practice to test code
16:22:29 <haypo> dims: for the specific case of glance? well, there is still the option of accepting my patch which already has a +2 :-)
16:22:44 <haypo> dims: but i'm probably over confident, since ian is strongly opposed to that :)
16:22:53 <dims> haypo : i'll leave that to glance cores :)
16:23:58 <bknudson_> I guess the unit test jobs on keystone don't get us anything since you can't run keystone that way anyways.
16:24:05 <dims> kgiusti jecarey toabctl jd__ bknudson_ rpodolyaka - anything else to discuss?
16:24:23 <kgiusti> dims: nope
16:24:34 <rpodolyaka> no
16:24:53 <dims> kgiusti : were you able to check on compression options for your driver?
16:24:54 <jd__> nop
16:25:02 <dims> rpodolyaka : jd__ : thanks
16:25:23 <kgiusti> dims: sorry, no - I will do that today.
16:25:27 <jecarey> No
16:25:38 <bknudson_> security midcycle was last week
16:25:47 <bknudson_> keystone midcycle is next week
16:26:04 <dims> w00t: have fun bknudson_
16:26:09 <dims> kgiusti : ack thanks
16:26:13 <bknudson_> nova must be coming up too
16:26:23 <dims> jecarey : thanks
16:26:45 <dims> bknudson_ : next week i think
16:26:57 <dims> i won't make it to either one
16:27:28 <dims> k let's wrap it up for this week. thanks everyone
16:27:37 <dims> #endmeeting