08:00:36 <ttx> #startmeeting ptl_sync
08:00:37 <openstack> Meeting started Tue Apr  7 08:00:36 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:00:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:00:40 <openstack> The meeting name has been set to 'ptl_sync'
08:00:41 <ttx> #topic Heat
08:00:54 <asalkeld> all looks green
08:01:14 <asalkeld> and ready for rc1
08:01:32 <ttx> asalkeld: Alright, if you don't have any bugfix in the queue, now is as good as anytime
08:01:45 <asalkeld> cool, let's do it
08:01:50 * ttx warms up his scripts
08:02:33 <ttx> let me seee if we can merge translations or requirements
08:03:34 <asalkeld> ttx: both done
08:03:44 <ttx> good!
08:03:46 <asalkeld> https://github.com/openstack/heat/commits/master
08:03:59 <asalkeld> within the last ~10 commits
08:04:25 <ttx> It's my first one for kilo so I have to remember how to do it
08:04:33 <asalkeld> :-)
08:05:19 <ttx> OK, we need to push the version bump on master, let me propose that
08:05:40 <asalkeld> ok
08:07:20 <ttx> https://review.openstack.org/171075
08:07:25 <ttx> Approve if you're happy.
08:07:38 <ttx> I'll cut the Kilo proposed branch from the commit just before that one
08:07:55 <asalkeld> ok
08:08:37 <ttx> (and then tag RC1 on the created proposed branch)
08:08:49 <asalkeld> ttx: we are suddenlly getting heaps of this: http://logs.openstack.org/14/170814/2/check/check-tempest-dsvm-full/86acaad/logs/devstacklog.txt.gz#_2015-04-07_06_14_46_464
08:09:11 <asalkeld> AttributeError: 'InstallRequirement' object has no attribute 'url'
08:09:22 <asalkeld> i hope that review of yours is ok
08:09:41 <ttx> asalkeld: well, we'll see...
08:09:51 <ttx> suddenly = since when ?
08:10:10 <asalkeld> last hour?
08:10:40 <ttx> hm, ok, will keep an eye on it
08:10:50 <asalkeld> yeah
08:11:10 <asalkeld> https://bugs.launchpad.net/tempest/+bug/1440984
08:11:12 <openstack> Launchpad bug 1440984 in tempest "AttributeError: 'InstallRequirement' when running update.py" [Undecided,New]
08:11:19 <ttx> asalkeld: if you approve the bump I can babysit the fix in the queue and tag when ready
08:12:19 <ttx> asalkeld: once we cut RC1 we'll use the kilo-rc-potential tag as a list of bugs that may or may not trigger a RC2 window
08:12:36 <ttx> so you can refine the list of potential show-stoppers there
08:12:47 <ttx> and we'll evaluate it regularly
08:12:47 <stevebaker> asalkeld: were you going to be on leave this week?
08:12:50 <asalkeld> ttx: done
08:12:56 <asalkeld> stevebaker: next week
08:13:08 <asalkeld> stevebaker: you off this week or next?
08:13:09 <stevebaker> ok, cool
08:13:19 <stevebaker> this Friday and Monday
08:13:25 <asalkeld> ttx: i am taking  a holiday next week
08:13:27 <ttx> asalkeld: we'll let the RC1 be used un-troubled for a few days anyway, to encourage testing
08:13:38 <stevebaker> my monday, so should be no problem for this ptl_sync
08:13:48 <asalkeld> ttx: stevebaker has agreed to cover for next week
08:13:54 <ttx> asalkeld: I'll sync with stevebaker to see if we need a RC2 next week
08:14:03 <asalkeld> thanks
08:14:11 <ttx> in the mean time if you discover critical issues, just get them fixed on master
08:14:14 <asalkeld> stevebaker: thanks again for covering
08:14:23 <stevebaker> np.
08:14:23 <ttx> so that we can fast-track backports if we need to
08:14:24 <asalkeld> ttx: ok, thanks
08:15:06 <ttx> asalkeld: That's all I had. Will cut RC1 in the next hours, time for that bump patch to land
08:15:17 <ttx> asalkeld: thx, and congrats !
08:15:22 <asalkeld> ok, thanks
08:15:23 <ttx> Nice work by the Heat team.
08:15:50 * asalkeld heads off to enjoy a beer
08:16:16 <ttx> johnthetubaguy: around?
08:16:23 <johnthetubaguy> ttx: good morning
08:16:28 <ttx> #info Heat RC1 to be cut asap
08:16:33 <ttx> #topic Nova
08:16:47 <ttx> #link https://launchpad.net/nova/+milestone/kilo-rc1
08:17:13 <ttx> #info 7 release-critical bugs on the list, all assigned and in progress
08:17:35 <ttx> Checking that they are all actually in progress
08:18:05 <johnthetubaguy> yeah, there are a few dubious ones I just pushed out, I suspect there are more
08:18:29 <ttx> https://bugs.launchpad.net/nova/+bug/1438183 -- some fix merged there, is the bug still needing more ?
08:18:30 <openstack> Launchpad bug 1438183 in OpenStack Compute (nova) "Graceful shutdown of nova-compute service fails" [Medium,In progress] - Assigned to Dan Smith (danms)
08:18:43 <ttx> Oh, https://review.openstack.org/#/c/169057/ probably
08:19:03 <johnthetubaguy> ah, yes
08:19:06 <ttx> Same for https://bugs.launchpad.net/nova/+bug/1313573
08:19:06 <openstack> Launchpad bug 1313573 in OpenStack Compute (nova) "nova backup fails to backup an instance with attached volume (libvirt, LVM backed)" [Medium,In progress] - Assigned to Fei Long Wang (flwang)
08:19:49 <ttx> https://bugs.launchpad.net/nova/+bug/1430239 looks a bit stale
08:19:50 <openstack> Launchpad bug 1430239 in OpenStack Compute (nova) "Hyper-V: *DataRoot paths are not set for instances" [High,In progress] - Assigned to Dorin Paslaru (dpaslaru)
08:20:07 <johnthetubaguy> yeah, some of these look at lot like the super critical bit for kilo is done
08:20:28 <johnthetubaguy> I am thinking we tag them as potential and add a note, I can do that after the meeting
08:20:41 <ttx> yes, but all in all, looks like the RC1 could benefit from a few more days of fixes
08:20:53 <ttx> and target end of week
08:21:09 <ttx> at the earliest
08:21:42 <ttx> johnthetubaguy: so let's give it a few more days, and reevaluate the criticality of the leftovers by the end of the week
08:21:53 <johnthetubaguy> yeah, I think thats a good assessment
08:22:04 <johnthetubaguy> maybe a quick catch up on thursday?
08:22:13 <ttx> If nothing critical is left in the pipe, we'll tag. Then if those fixes merge in master and we have enough to justify a RC2, we'll do one
08:22:21 <ttx> johnthetubaguy: works for me
08:22:25 <johnthetubaguy> cool
08:23:09 <johnthetubaguy> quick general question, I am wondering what you take is on "federating" the code review more in Nova?
08:23:11 <ttx> johnthetubaguy: While you're around, let me push a open-liberty patch so that you can -2 it
08:23:22 <johnthetubaguy> ttx: ah, cool, thats a good plan
08:24:16 <ttx> johnthetubaguy: I think it's really necessary to split nova reviewing along smaller domains of expertise. It's the only way to scale development and avoid critical resources burning out
08:24:33 <johnthetubaguy> yeah, at this point we have little choice
08:24:43 <johnthetubaguy> I just worry about loosing consistency across the code base
08:24:58 <johnthetubaguy> but that not totally worth the cost of slowing everything down
08:25:16 <ttx> so we kind of had the same problem in stable
08:25:33 <ttx> johnthetubaguy: please -2 : https://review.openstack.org/171078
08:25:36 <johnthetubaguy> I am kinda thinking of a way sub groups can prove themselves worthy, etc, and graduate to have some level of merge ability
08:25:49 <johnthetubaguy> yeah, thats true, I hadn't thought of stable like that
08:26:02 <ttx> In the stable team we could not review everythijng and were lacking local expertise
08:26:25 <ttx> What we put in place is the following
08:26:37 <ttx> We have local review teams (per project)
08:26:59 <ttx> But we vet the members there to make sure they have the basics rules
08:27:09 <ttx> We ask them to ask around when unsure
08:27:24 <ttx> (escalate to the "core" stable maint)
08:27:37 <ttx> and then we try to keep an eye on them and check they don't do crazy stuff
08:27:47 <johnthetubaguy> right, that makes sense
08:27:58 <ttx> So stable-maint-core became the guardians of the stable policy, more than reviewers
08:28:18 <ttx> transposed to nova, you could have a core group that maintains consistency and quality standards
08:28:21 <johnthetubaguy> I am just thinking we need a way for a subteam to gain the trust of the core team, like a graduation flow
08:28:26 <ttx> but still let subteams go wild
08:28:48 <ttx> It's tricky, because you have to fiond a way to communicate the "standards"
08:28:58 <johnthetubaguy> thats true
08:29:00 <ttx> for stable policy it's relatively simple
08:29:16 <ttx> since you have a few rules and you can call them out when they fail to apply them
08:29:29 <ttx> For "consistency" and "quality" it's a bit harder
08:29:30 <johnthetubaguy> yeah, less subjective
08:29:38 <johnthetubaguy> right
08:29:44 <ttx> but I still think it's the only way to scale
08:30:01 <ttx> letting go of a bit of control to gain a bit of sanity
08:30:17 <johnthetubaguy> I mean the other approach is splitting more out of nova, but I think we need both at this point
08:30:36 <ttx> But yes, ideally each subteam would grow around a strong nucleus that has the consistency/quality mindset already
08:30:38 <johnthetubaguy> mostly as there is only so much you can sanely split out, and it takes years to do it properly
08:30:57 <johnthetubaguy> luckily, I think some of that is already happening
08:31:01 <ttx> so that the subteam doesn't grow it's own culture
08:31:30 <johnthetubaguy> yeah, thats the worry, subteam X don't do unit tests, they hate those, etc
08:31:42 <ttx> johnthetubaguy: yes we won't split out enough and fast enough to avoid losing our sanity
08:31:57 <ttx> and splitting should make sense technically too
08:32:02 <johnthetubaguy> ttx: thats totally true, well, we have proven that quite well the last 12 months
08:32:19 <johnthetubaguy> ttx: if you do it wrong, you get two competing network stacks…
08:32:21 <ttx> the only reason we split is because it's the most convenient way to make Gerrit support the case
08:32:41 <johnthetubaguy> yeah, there is some truth in that
08:32:47 <ttx> If you had magic ways to split reviews across subteams in a single repo, we would do that more often than splitting
08:33:04 <johnthetubaguy> yeah, not sure we can wait for tooling, but agreed
08:33:11 <ttx> (splitting still makes sense in a lot of cases, but it's a trade-off with consistency/quality as said above)
08:33:22 <johnthetubaguy> yeah
08:33:45 <johnthetubaguy> we were struggling with, if we split it off, they do crazy things, nova dies because the scheduler is broken, boom
08:33:58 <johnthetubaguy> but you totally captured that above
08:34:08 <ttx> Even if tooling doesn't support it, you can add a bit of procedures. Like reviews by default are for the core team, but can be tagged so that they are a subteams decision
08:34:26 <ttx> and at that point subteam +2ers can just go with it
08:34:30 <johnthetubaguy> ttx: agreed, thats my current preference actually
08:34:40 <johnthetubaguy> well, something like that
08:34:50 <ttx> and if someone abuses their rights, just revoke the privs
08:34:56 <johnthetubaguy> right
08:34:59 <ttx> and backtrack
08:35:15 <ttx> we shoudln't limit ourselves to what Gerrit lets us do
08:35:31 <johnthetubaguy> so the problem we have with nova-core, is its very political to drop people, so it just doesn't happen, we need to be more fluid, then the right things just happen
08:35:55 <johnthetubaguy> anyways, I think there is enough for me to chew on there, really appreciate your thoughts on that
08:35:59 <ttx> right -- which is why I don't want to pile up more rights/duties around core reviewing
08:36:03 <ttx> will make it harder to drop people
08:36:15 <johnthetubaguy> ah, I get you now
08:36:22 <ttx> the core review group should just be the ones with +2, not the "project maintainers"
08:36:39 <johnthetubaguy> yeah, the current people who have time for +2, etc
08:36:48 <ttx> because removing people from the latter is harder than removing people from the former
08:37:00 <ttx> since it implies "you're someone in Nova"
08:37:05 <johnthetubaguy> yeah, fluidity is important here
08:37:13 <johnthetubaguy> I think we fail to add people as its hard to remove them
08:37:23 <ttx> Not opposed in having the latter, just opposed to tie +2 Gerrit rights to it :)
08:37:35 <johnthetubaguy> right
08:37:56 <ttx> I want people with +2 be the ones that spens all their time reviewing, basically
08:38:22 <ttx> devananda had an interesting strawman: what if you gave Workflow+1 to a separate group from Review+2
08:38:47 <johnthetubaguy> ah, not read that bit, I should take a look
08:38:57 <ttx> I don't think he publicly suggested that
08:38:58 <ttx> yet
08:39:16 <ttx> I haven't read the thread you're talking about fwiw, just came back from holiday :)
08:39:36 <johnthetubaguy> yeah, similar, well a long weekend anyways
08:39:47 <ttx> that way you could give review rights to a subgroup, but still quick-vet for change sanity
08:40:05 <johnthetubaguy> yeah, thats very attractive
08:40:29 <ttx> (his suggestion was to only let PTL Workflow+1, which might not scale well, but the concept of separating code review from change desirability is interesting)
08:41:11 <ttx> Also serves as checks & balances
08:41:12 <johnthetubaguy> yeah, some small group
08:41:49 <johnthetubaguy> I think you would want at least one person in each timezone, and bigger projects, two or more, but yes, I like that
08:41:49 <ttx> might create botlenecks at the Workflow+1 and merge conflicts, but still worth considering
08:41:55 <johnthetubaguy> yeah
08:42:28 <johnthetubaguy> well, even a loose, policy, where you can +W only for merge conflicts, could work
08:42:29 <ttx> The fear in giving +2/aprv to subgroups is to lose touch with what theu are doing and discover insanity too late
08:42:43 <ttx> deva's strawman kind of addresses that fear
08:42:51 <johnthetubaguy> yeah, its a nice touch
08:43:24 <johnthetubaguy> not considered splitting those before, fancy
08:43:45 <ttx> right, correctness and desirability are actually 2 different things
08:43:57 <johnthetubaguy> its similar to the adding a +3 that owns +W, but its less… crazy
08:44:12 <ttx> except you don't give +2 to the people who do Workflow+1
08:44:17 <johnthetubaguy> ttx: totally true, its a battle we have reguarly
08:44:25 <ttx> (they can still +1 alright)
08:44:42 <ttx> but it takes into accoutn that the pTl is often too busy to maintain crazy review levels
08:44:44 <johnthetubaguy> ttx: yeah, true, or at least, if they have +2, thats independent and not assumed
08:45:00 <johnthetubaguy> good point, not thought about it that way
08:45:25 <ttx> You basically have two groups -- domain experts who vet the code makes sense and is correct
08:45:42 <ttx> andd rivers who decide that the change is welcome at this time in the cycle
08:45:45 <ttx> drivers*
08:45:51 * anteaya likes rivers
08:46:22 <ttx> frankly when I review I only ever do the latter, since I'm not an expert anywhere anymore
08:46:43 <ttx> but I can still judge the impact of a change and the rationale
08:47:07 <johnthetubaguy> ttx: yeah, I am liking that idea, it has great promise
08:47:28 <ttx> anyway, i'll let you run. Will comment on that thread when I get to there
08:47:36 * ttx has a lot of ML reading to do
08:47:42 <johnthetubaguy> ttx: cool, thanks for your time, appreciate that
12:00:01 <eglynn> ttx: knock, knock, ready when you are ...
12:00:23 <ttx> eglynn: hi!
12:00:28 <ttx> #topic Ceilometer
12:00:30 <eglynn> #link https://launchpad.net/ceilometer/+milestone/kilo-rc1
12:00:57 <eglynn> a few things came up mid/late- last week
12:00:58 <ttx> #info 3 RC bugs, all in progress and assigned
12:01:10 <ttx> looking how far they are
12:01:17 <eglynn> nothing major, patches for all under review
12:01:35 <eglynn> the main one was https://bugs.launchpad.net/bugs/1435855 discussed on the ML etc.
12:01:36 <openstack> Launchpad bug 1435855 in Ceilometer "Default rule does not work in ceilometer policy.json" [High,In progress] - Assigned to Divya K Konoor (dikonoor)
12:01:57 <eglynn> the approach to resolving while keeping the desired backward compat is agreed
12:02:09 <eglynn> just some style issues in the review and we're good to go
12:02:19 <ttx> rechecking those that were stuck with gate state this morning
12:02:34 <eglynn> cool
12:02:46 <ttx> OK, looks like we could have a RC1 tomorrow or Thursday
12:02:46 <eglynn> so no major red flags or alarms
12:03:01 <eglynn> yep, let's chat again thurs
12:03:03 <ttx> Did you merge recent requirements and translations ?
12:03:35 <eglynn> lemme check that
12:03:48 <ttx> https://review.openstack.org/#/c/170388/ could use a +2
12:04:22 <eglynn> cool
12:05:56 <ttx> ys, translations were merged
12:06:20 <ttx> So let me propose the version bump -- you can -2 it temporarily and approve it when you're happy with things
12:06:30 <eglynn> sounds like a plan
12:07:48 <ttx> https://review.openstack.org/171152 -- please -2 for the moment to avoid errors
12:08:07 * eglynn looks
12:09:12 <eglynn> -2'd while we close out the rc1 queue
12:09:17 <eglynn> cool, thanks
12:09:24 <ttx> so when ready, just approve it and ping me
12:09:37 <ttx> I'll make things happen from the commit just before that one
12:09:42 <eglynn> will do, thanks!
12:10:08 <ttx> Questions ? Urgent matters ?
12:10:21 <eglynn> nope, all good otherwise
12:10:30 <ttx> alright, let's do this!
12:10:34 * SergeyLukjanov ready
12:10:38 <ttx> SergeyLukjanov: hi!
12:10:43 <eglynn> ttx: thanks for your time! :)
12:10:43 <SergeyLukjanov> ttx, hey!
12:10:43 <ttx> #topic Sahara
12:10:55 <ttx> #link https://launchpad.net/sahara/+milestone/kilo-rc1
12:11:05 <ttx> #info 3 RC bugs, all in progress and assigned
12:11:15 <ttx> checking how far and active they are
12:11:16 <SergeyLukjanov> we have two issues on board + bunch of doc CR that are nice to have
12:11:58 <SergeyLukjanov> MapR related just uploaded to review, but it's simple
12:12:09 <ttx> OK, so you seem pretty close too
12:12:16 * ttx runs a couple checks
12:12:33 <SergeyLukjanov> yeah, I think tomorrow we'll be fully ready for tag
12:12:50 <ttx> Translations & requirements are in
12:13:14 <SergeyLukjanov> yup
12:13:24 <ttx> SergeyLukjanov: so I'll propose the version bump so that it's ready for your approval when ready
12:13:35 <SergeyLukjanov> ack
12:14:05 <SergeyLukjanov> so, I will ensure all needed CRs merged (till the end of tomorrow), than merge version bump and notify you
12:14:45 <ttx> https://review.openstack.org/171155 -- please -2 for the time being
12:15:46 <SergeyLukjanov> ttx, done, thx
12:15:57 <SergeyLukjanov> no urgent questions or issues
12:16:11 <ttx> Alright! Have a nice day then
12:16:23 <SergeyLukjanov> ttx, thank you! have a nice day too!
12:16:27 <ttx> dhellmann: ready when you are
12:16:37 <dhellmann> ttx: here
12:16:39 <ttx> #topic Oslo
12:16:40 <SergeyLukjanov> ttx, btw how is the RC-1 going for projects?
12:16:54 <ttx> SergeyLukjanov: pretty good so far
12:16:59 <SergeyLukjanov> ttx, awesome!
12:17:02 <ttx> http://old-wiki.openstack.org/rc/
12:17:10 <ttx> Most projects under 10 bugs
12:17:22 <ttx> which makes them likely to hit target sometimes this week
12:17:36 <ttx> There will be the occasional straggler although I can't predict who that will be
12:17:43 <ttx> dhellmann: Not sure we have anything to discuss
12:18:17 <dhellmann> ttx: I can't think of anything either :-)
12:18:19 <ttx> dhellmann: Do we have anything left to d release-wide as far as Oslo is concerned ?
12:18:33 <ttx> I mean "release-wise"
12:18:34 <dhellmann> we need a stable branch in the incubator repository, but that's it
12:18:43 * ttx checks
12:19:01 <ttx> yes, and a final tag
12:19:20 <ttx> Maybe when all the RC1s are cut, just before we branch requirements ?
12:19:22 <dhellmann> I found a few issues with some of the library release tools that weren't prepared to work with stable branches, but I've made notes and will be working on fixes
12:19:29 <dhellmann> yeah, that sounds about right
12:20:08 <ttx> ok then, that should happen early next week
12:20:21 <dhellmann> sounds good
12:20:31 <dhellmann> I'm going to pycon this week, so I'll be online but only sporadically
12:20:37 <ttx> ack
12:20:58 * ttx hopes to get most RC1s in before everyone bumps libs
12:21:04 <dhellmann> oh, and the TC meeting today will be during my flight, so I *think* I'll be there, but that depends on how the wifi holds out
12:21:21 <dhellmann> do you mean the clients?
12:21:21 <ttx> dhellmann: ok, you might want to make sure you voted on stuff before then
12:21:31 <dhellmann> yeah, I'll do that this morning
12:21:35 <ttx> dhellmann: no, genera py libs
12:21:49 <ttx> Pycon usually is when people randomly bump their libs
12:21:55 <ttx> and break the world
12:21:55 <dhellmann> oh, I see
12:22:10 <ttx> the pip bump this morning was just the first sign
12:22:17 <dhellmann> oh, I missed that
12:22:27 <ttx> gate all stuck because pip changed API
12:22:44 <ttx> which is according to pip authors not a public API
12:22:56 <ttx> (only the CLI is public API)
12:23:25 <ttx> anyway, fun
12:23:35 <ttx> dhellmann: have a good day and travel!
12:23:42 <dhellmann> nice
12:23:47 <dhellmann> thanks, ttyl!
12:23:52 <Kiall> gate is fixed BTW - Just got a change to pass
12:24:01 <ttx> yes, We ninjafixed it
13:10:59 <dhellmann> ttx: I can't remember how to make launchpad let me associate a bug with more than one release of a project. For example, https://bugs.launchpad.net/oslo.messaging/+bug/1440755 needs to be backported
13:11:00 <openstack> Launchpad bug 1440755 in oslo.messaging "NoneType 'retry' parameter causes TypeError in impl_rabbit" [High,Fix committed] - Assigned to Dan Prince (dan-prince)
13:11:26 <ttx> dhellmann: do you see "target to series" there ?
13:11:37 <dhellmann> ttx: no
13:11:47 <ttx> ok, that is probably what needs fixing
13:11:51 <dhellmann> oh, hmm, I do on that one
13:12:00 <dhellmann> I had one on the policy lib the other day and didn't see it there
13:12:08 <dhellmann> is that a permission setting?
13:12:11 <ttx> *yeah,; looks like ayoung is the only driver there
13:12:19 <ttx> yes, need to be a driver I think
13:12:19 <dhellmann> oh, right
13:12:52 <ttx> oh, so there is another issue on oslo.messaging
13:13:00 <ttx> resulting oin the "status tracked in" mess
13:13:13 <dhellmann> ?
13:13:25 <ttx> problem is, liberty should be the "active development" series
13:13:44 <ttx> that's something you need to switch to match what "master" means
13:14:00 <ttx> https://launchpad.net/oslo.messaging -- see "development focus" there
13:14:14 <ttx> that needs to be liberty, if master switched to liberty
13:14:25 <ttx> otherwise you can't backport to kilo, since master = kilo
13:14:39 <ttx> let me fix that
13:15:24 <ttx> here
13:16:01 <ttx> so you should check that all libs that had their kilo branch cut also switched "dev focus" in LP
13:16:18 <ttx> otherwise you won't be able to create kilo backport tasks there
13:16:21 <dhellmann> I did a bunch of them, but I guess I missed a few. I'll double-check
13:16:38 <ttx> I do that as part of the proposed/$SERIES branching process
13:16:55 <dhellmann> is that scripted, then?
13:16:56 <ttx> https://wiki.openstack.org/wiki/ReleaseTeam/How_To_Release#proposed.2F.24SERIES_branch_cut_.28switch_master_to_next_version.29
13:17:13 <ttx> no, I do it manually
13:17:17 <dhellmann> ah, ok
13:17:20 <ttx> not sure there ius even an API for that. Checking
13:17:55 <ttx> yes there is, so I could script it in theory
13:18:11 <ttx> Never had the need for it because doing it for 10 projects is not that painful
13:18:22 <ttx> but with oslo libs in mix, might make sense
13:18:23 <dhellmann> yeah, I have more than that just in oslo now
13:21:12 <dhellmann> ttx: now for https://bugs.launchpad.net/oslo.policy/+bug/1437992 I can see the "target to series" link but it only shows me the liberty series, no kilo
13:21:14 <openstack> Launchpad bug 1437992 in oslo-incubator "policy file in policy.d will be reloaded every rest api call" [Critical,In progress] - Assigned to Eli Qiao (taget-9)
13:21:51 <ttx> It's because I already added kilo ?
13:22:12 <ttx> hmm, weird though
13:22:48 <ttx> no, that must be the reason
13:38:27 <dhellmann> oh, duh, I didn't notice that
13:45:29 <mestery> ttx: Here when you're ready!
13:45:47 <ttx> mestery: hi!
13:45:51 <ttx> #topic Neutron
13:46:06 <ttx> #link https://launchpad.net/neutron/+milestone/kilo-rc1
13:46:22 <ttx> #info 6 in-progress bugs, all assigned
13:46:25 <mestery> 6 left, but one of those is in the merge queue
13:46:35 <ttx> checking that they are all actively worked on
13:46:35 <mestery> https://bugs.launchpad.net/bugs/1439817
13:46:36 <openstack> Launchpad bug 1439817 in neutron "IP set full error in kernel log" [High,In progress] - Assigned to Brian Haley (brian-haley)
13:46:38 <mestery> That's the one in the merge queue
13:46:49 <mestery> Ack, they should be, I just looked myself this morning
13:47:25 <mestery> I had hoped we would have been down to 3 or so this morning, but some of them saw issues during review last night and one needed a unit test written which turned out to be challenging :)
13:47:28 <ttx> ack confirmed
13:47:53 <ttx> runnign a few checks
13:48:08 <mestery> cool
13:48:34 <ttx> ok, requirements & translations all merged
13:48:43 <mestery> Excellent!
13:49:04 <ttx> checking for missing files in tarballs...
13:49:24 <ttx> looks like you are a couple of days away from your rc1 tag(s)
13:49:46 <mestery> Yes sir, we're getting close!
13:49:47 <ttx> I propose to upload the reviews for the version bumps, so that they are ready for your approval when all is ready
13:50:05 <mestery> Ack, sounds good, please proceed with that.
13:50:32 <ttx> ok, I'll ping you with review numbers in a sec, so that you can temporarily -2 them
13:50:40 <mestery> Perfect!
13:51:54 <ttx> neutron -> https://review.openstack.org/171200
13:52:05 <mestery> -2 :)
13:52:13 <ttx> excellent.
13:52:35 <mestery> I think we just need to close out these last bugs and then we're good!
13:53:01 <ttx> neutron-fwaas -> https://review.openstack.org/171202
13:53:24 <mestery> -2 :)
13:54:21 <ttx> neutron-lbaas -> https://review.openstack.org/171205
13:55:26 <mestery> -2 :)
13:56:18 <ttx> neutron-vpnaas -> https://review.openstack.org/171206
13:56:46 <mestery> Also -2 :)
13:56:48 <mestery> Thanks for those!
13:56:50 <ttx> Let's target around Thursday to tag
13:57:15 <ttx> Questions ?
13:57:36 <mestery> Nope, I think we're good, thanks for all the help as usual, you make doing these releases a pain free experience :)
13:58:22 <ttx> np, business as usual :)
13:58:24 <mestery> :)
13:58:33 <mestery> Thanks ttx, we'll sync thursday then!
13:58:40 <mestery> Now, time to run the Neutron meeting :)
13:59:23 <ttx> cheers
14:21:28 <ttx> nikhil_k: ready when you are
14:26:26 <nikhil_k> ttx: hey, another meeting carried over
14:26:32 <nikhil_k> sorry about that
14:26:38 <ttx> np
14:26:43 <ttx> #topic Glance
14:27:10 <ttx> #link https://launchpad.net/glance/+milestone/kilo-rc1
14:27:17 <ttx> I see 3 bugs on the RC list
14:27:27 <ttx> #info 3 RC bugs, all assigned and in progress
14:27:56 <nikhil_k> ttx: yeah, waiting on gate
14:28:11 <nikhil_k> this, https://launchpad.net/bugs/1434237 https://review.openstack.org/#/c/166909/
14:28:13 <openstack> Launchpad bug 1434237 in Glance "glance-manage db_export_metadefs fails with NoSuchColumnError" [High,In progress] - Assigned to Ashish (ashish-jain14)
14:28:18 <ttx> ack
14:28:22 <nikhil_k> I think it has some discussion going
14:28:29 <ttx> So it looks like you're pretty close
14:28:34 <nikhil_k> we can mark k2 to give it some time
14:28:37 <nikhil_k> yes
14:28:40 <nikhil_k> we should be good
14:28:46 <nikhil_k> one question though
14:28:50 * ttx runs a few tests
14:29:03 <nikhil_k> do we need a stable branch for store and client before RC1?
14:29:13 <nikhil_k> we don't have one last time I checked
14:29:34 <ttx> not before, but certainly not far after
14:29:38 <ttx> dhellmann: ^ ?
14:29:39 <nikhil_k> sure
14:29:59 <nikhil_k> sometime close to RC2 , or beginning or RC3
14:30:06 <nikhil_k> s/or/of/
14:30:13 <ttx> well in theory you won't have a RC2 :)
14:30:24 <nikhil_k> ttx: please do not say that
14:30:46 <nikhil_k> one sec
14:30:54 <nikhil_k> https://bugs.launchpad.net/glance/+bugs?field.tag=kilo-rc-potential
14:31:00 <nikhil_k> that's why I say ^
14:31:35 <ttx> nikhil_k: if you have things you can't release without fixing them, we should delay RC1 a bit
14:31:50 <ttx> no point in making a release candidate we already know is broken
14:31:54 <nikhil_k> How long can we wait?
14:32:04 <ttx> I'd say one more week
14:32:13 <nikhil_k> That would be better
14:32:20 <ttx> if you have show stoppers they should be on the RC list
14:32:21 <nikhil_k> I feel we should have stable branch for store and client
14:32:35 <nikhil_k> yes, all show stoppers are on the list
14:32:53 <nikhil_k> But I feel that better to have small bugs fixed too
14:32:56 <ttx> nikhil_k: master uses capped dependencies anyway, so the stable branch is noly needed if you have to backport stuff there
14:33:15 <ttx> but yeah, we should have stable branches cut from the last releases
14:33:27 <ttx> I'll come back to you on that
14:33:40 <nikhil_k> yeah, so I'm okay with moving on RC1 for now
14:33:43 <ttx> We might want to do that in a more..; systematic way
14:33:56 <nikhil_k> so that people do some testing and find any more bugs if applicable
14:34:07 <nikhil_k> and then get RC2 in a better shape
14:34:22 <nikhil_k> but either works for me, waiting for RC1 one week too
14:34:25 <ttx> ok, let's target later this week then
14:34:30 <ttx> and we'll decide
14:34:33 <nikhil_k> sure
14:34:37 <ttx> in the mean time let's get the ones on the list in
14:34:47 <nikhil_k> Yeah, today hopefully
14:35:34 <ttx> alright, let me propose a version bump that will open master to liberty
14:35:56 <ttx> you can -2 it until you are happy with your RC1
14:36:43 <nikhil_k> ttx: sounds like a plan
14:36:45 <nikhil_k> thanks
14:36:55 <ttx> nikhil_k: please -2 temporarily: https://review.openstack.org/171227
14:37:11 <ttx> approve when you're happy with state of things
14:37:23 <ttx> Ideally when all showstopper fixes are in
14:37:30 <nikhil_k> done
14:37:36 <nikhil_k> thanks
14:37:43 <ttx> I'll talk to you tomorrow, probably, or when that merged
14:37:48 <ttx> thingee: around?
14:37:51 <thingee> ttx: o/
14:38:02 <ttx> #topic Cinder
14:38:11 <thingee> what I can't live without https://etherpad.openstack.org/p/cinder-kilo-rc-priorities
14:38:23 <ttx> #link https://launchpad.net/cinder/+milestone/kilo-rc1
14:38:40 <thingee> unfortunately a bunch of these would've merged earlier, but we're hitting some jenkins issues.
14:38:45 <thingee> rechecks are in place
14:38:48 <ttx> #info status at https://etherpad.openstack.org/p/cinder-kilo-rc-priorities
14:39:02 <ttx> yep, things need rechecks if they hit the pip issues earlier today
14:39:26 <ttx> Looks like you could hit the RC1 target.. Thursday ?
14:39:42 <thingee> seems more than enough time to me, but I won't complain :)
14:39:47 * ttx runs a few checks
14:40:05 <ttx> well, I'll upload the liberty version bump for you to merge when happy
14:40:12 <thingee> sure
14:40:52 <ttx> please -2 temporarily: https://review.openstack.org/171229
14:41:18 <thingee> done
14:41:53 <ttx> So just approve it when you're happy and I'll make stuff happen
14:42:32 <thingee> are we fine with continuing with Kilo once that merges?
14:42:38 <ttx> then you should pile up bugs that may be interesting to fix in kilo-rc-potential, fix them in master... and when we have a bunch, we could respin
14:42:39 <thingee> errr
14:42:40 <thingee> liberty
14:42:53 <ttx> yes, once that merges, master switches to liberty
14:43:00 <ttx> so no more freezes
14:43:07 <thingee> ok!
14:43:08 <ttx> I cut the kilo release branch from the previous commit
14:43:21 <ttx> OK then, I'll talk to you later
14:43:28 <thingee> one last question, cinderclient.
14:43:32 <ttx> yes?
14:43:39 <thingee> is it too late to do a cut from there?
14:43:48 <thingee> I know that depends on me
14:44:01 <ttx> It's too late to bump requirements for sure
14:44:33 <thingee> ok
14:44:36 <thingee> That's all
14:44:41 <ttx> I'm not totally clear on the effect of cutting a release there now
14:44:51 <ttx> I need to speak with dhellmann on that
14:45:03 <ttx> I'll get back to you
14:45:07 <thingee> well the pin for cinderclient would just ignore it
14:45:14 <thingee> python-cinderclient>=1.1.0
14:45:20 <ttx> right
14:45:26 <ttx> david-lyle: ready when you are
14:45:32 <thingee> ttx: thanks
14:48:40 <david-lyle> ttx: ready
14:49:06 <ttx> #topic Horizon
14:49:11 <ttx> #link https://launchpad.net/horizon/+milestone/kilo-rc1
14:49:38 <ttx> I see 6 bugs on the list, one of them unassigned and one of them not up for review yet
14:49:52 <ttx> checking how active they are
14:50:18 <ttx> https://review.openstack.org/#/c/165800/ is a bit stale
14:50:54 <ttx> https://bugs.launchpad.net/horizon/+bug/1435869 looks partially fixed, no idea where the second half of the fix (if any) is
14:50:55 <openstack> Launchpad bug 1435869 in OpenStack Dashboard (Horizon) "[Launch Instance Fix] Establish Baseline Unit Tests" [High,In progress] - Assigned to Matt Borland (palecrow)
14:51:24 <david-lyle> hhttps://review.openstack.org/#/c/165800/ I'll move out of RC-1
14:51:38 <ttx> https://bugs.launchpad.net/horizon/+bug/1436903 slightly unclear state as well
14:51:40 <openstack> Launchpad bug 1436903 in OpenStack Dashboard (Horizon) "integration tests failing blocking gate" [Critical,Confirmed] - Assigned to David Lyle (david-lyle)
14:51:59 <ttx> same for https://bugs.launchpad.net/horizon/+bug/1438822
14:52:00 <openstack> Launchpad bug 1438822 in OpenStack Dashboard (Horizon) "Table widget should show a default message when filtering yields no items" [Medium,New]
14:52:04 <david-lyle> integration tests are still failing and I've yet to find a fix
14:52:26 <ttx> ok, so that one is a blocker
14:52:26 <david-lyle> we can ship without it fixed, but would like to work on it until we cut RC-1
14:52:36 <ttx> oh ok
14:53:12 <david-lyle> all of these are individually not truly a blocker
14:53:17 <ttx> so yes, you might want to push a few non-critical out of RC1 if they can't get a fix in the next few days
14:53:39 <ttx> maybe we should reconvene on Thursday and see if we should just tag
14:54:01 <ttx> since none of those sounds critical nor close
14:54:12 <ttx> but a few more days shaking it wouldn't hurt
14:54:15 <david-lyle> yeah, if these aren't complete by thursday we can cut RC-1
14:54:21 <ttx> let's do that
14:54:30 <david-lyle> I think a couple of these will have commits by then
14:54:35 <ttx> Let me propose a liberty bump that you can -2
14:54:40 <ttx> temporarily
14:54:44 <ttx> until RC1 is ready for you
14:55:00 <david-lyle> ok, sounds good
14:55:07 <ttx> questions?
14:55:24 <david-lyle> just approve that patch when ready and you'll branch from the last commit
14:55:25 <david-lyle> ?
14:55:31 <ttx> yes
14:55:36 <ttx> and -2 it in the mean time
14:55:41 <david-lyle> ok, that works
14:55:44 <ttx> to make sure nobody gets triggerhappy
14:55:57 <david-lyle> yeah we had one of those yesterday we reverted
14:56:22 <ttx> Please -2  https://review.openstack.org/171241
14:56:47 <david-lyle> done
14:56:50 <ttx> OK, that is all. I'll talk to you again on Thursday!
14:57:00 <david-lyle> sounds great
14:57:02 <david-lyle> thanks
14:57:05 <ttx> have a great day
15:49:44 <ttx> morganfainberg: ready when you are
15:50:17 <morganfainberg> o/
15:50:20 <ttx> #topic Keystone
15:50:26 <ttx> #link https://launchpad.net/keystone/+milestone/kilo-rc1
15:50:37 <ttx> #info 1 RC bug, assigned and in progress
15:50:50 <morganfainberg> Refresh
15:51:00 <morganfainberg> Just punted that to l1
15:51:13 <ttx> ah-ah.
15:51:17 * morganfainberg gave up on the argument to keep it in kilo.
15:51:25 <ttx> Does that mean you're comfortable with a RC1 tag now ?
15:51:28 <morganfainberg> Sure
15:51:36 <ttx> OK, let me propose the version bump
15:52:13 <morganfainberg> Going to wait for the one patch that is dating (will run through and make sure all fix committed bugs are tagged to rc)
15:52:16 <ttx> ok, so when https://review.openstack.org/171260 merges, I cut proposed/kilo from the previous commit
15:52:24 <morganfainberg> And I'll approve.
15:52:31 <ttx> maybe -2 it until that other patch lands
15:52:38 <ttx> Or I can mark it as depending if you want
15:52:50 * ttx runs a few checks first
15:52:50 <morganfainberg> Nah ill wip yours
15:53:50 <morganfainberg> Done. Marked wip. Will make sure no outstanding translations etc are ready and will approve today hopefully.
15:53:55 <ttx> ok, so just approve it and ping me, and i'll branch/tag from there
15:54:21 <ttx> anything that merges after the version bump is liberty-only
15:54:38 <morganfainberg> ++
15:54:54 <morganfainberg> the critical security bug we can rc2 if needed
15:55:13 <ttx> alright
15:55:21 <morganfainberg> I moved it off rc blocking due to ossa/OSSN discussion.
15:55:36 <ttx> yeah, we need to run that in parallel, too hard to sync
15:55:51 <morganfainberg> Exactly.
15:55:55 <ttx> Questions?
15:56:17 <morganfainberg> Nope. Besides asking myself if it was a good idea to run for PTL again :P
15:56:24 <ttx> heh
15:56:30 <morganfainberg> ttx: thanks! :)
15:57:14 <ttx> let me know when you approved the bump and I'll keep an eye on it
15:59:05 <morganfainberg> ack
15:59:50 <ttx> notmyname: ready when you are
16:00:15 <notmyname> Yo
16:00:24 <ttx> #topic Swift
16:00:31 <ttx> #link https://launchpad.net/swift/+milestone/2.3.0-rc1
16:00:43 <ttx> notmyname: how are things going with your megamerge ?
16:01:03 <notmyname> Well. That's the focus for this week
16:01:16 <notmyname> Still targeting Friday for landing it
16:01:42 <notmyname> And I'm working on release notes, etc for the rc
16:02:09 <notmyname> I'll be sending some stuff the to ml about it
16:02:33 <ttx> notmyname: ok
16:02:41 <notmyname> This feature has been a huge collaboration from global devs. It's been really cool to see and be a part of
16:03:36 <ttx> Not sure we have much to discuss until the merge is completed
16:03:42 <ttx> so I'll let you go back to it
16:03:49 <ttx> unless you have questions
16:04:00 <notmyname> :)
16:04:01 <ttx> #info Still targeting Friday for landing the feature branch
16:04:20 <ttx> #info Open source is kinda cool
16:04:22 <notmyname> Summit scheduling will kick off this week for us
16:04:26 <notmyname> Lol
16:04:54 <ttx> notmyname: yes, should be able to confirm your allocation by April 10
16:05:02 <notmyname> Great. Thanks
16:05:44 <ttx> The 6 fishbowl sessions are very likely. The 12 work sessions slightly less (depend on what projects we need to include)
16:05:55 <notmyname> Ok
16:06:20 <notmyname> We'll take all we can get :)
16:06:30 <ttx> could be 6/8 or 6/10 instead of 6/12, but not really lower
16:06:41 <ttx> so you can count on 6/8 already
16:06:49 <notmyname> Ok
16:07:00 <notmyname> Plus Friday sessions?
16:07:05 <ttx> yes
16:07:11 <notmyname> Ack
16:07:51 <ttx> Other questions or announcements ?
16:07:59 <notmyname> I'm good. Thanks
16:08:05 <ttx> alright, have a great week!
16:08:14 <ttx> devananda: ready when you are
16:14:11 <devananda> ttx: o/
16:14:24 <devananda> roofers are making so much noise i can't hear my notification s...
16:14:42 <ttx> #topic Ironic
16:15:04 <ttx> #link https://launchpad.net/ironic/+milestone/kilo-rc1
16:15:28 <ttx> That RC1 list is a bit confusing to me... how current is it with your own tracking tools ?
16:15:51 <devananda> fairly current
16:16:05 <devananda> though i'm about to bump the not-in-progress ones
16:16:14 <ttx> #info 10 RC bugs, 4 unassigned and 3 in progress
16:16:28 <ttx> yeah, unless they are showstoppers, sounds like a good tradeoff
16:16:32 <devananda> I raised them in the meeting yesterday morning, and apparently no one took them on
16:16:53 <devananda> the 4 in progress should be landed soon
16:18:05 <devananda> we've also just found a backwards-incompatible change in the client lib, so I plan to fix that before tomorrow as well
16:18:18 <ttx> ok, let me push a liberty version bump for you to approve when all is ready
16:18:42 <devananda> ack
16:18:53 <devananda> I will be on vacation thursday and friday, btw
16:19:09 <ttx> please -2 temporarily: https://review.openstack.org/171274
16:19:21 <ttx> ok, so let's cut RC1 before then
16:19:26 <ttx> Let's target tomorrow
16:19:43 <devananda> indeed
16:19:49 <ttx> running a few checks
16:20:28 <ttx> Could we get that one merged as well: https://review.openstack.org/#/c/169184/
16:20:57 <ttx> so that we include relatively recent ones in RC1 ? They are likely to be dropped in future RCs fwiw
16:21:03 <ttx> if they don't reach the %
16:21:26 <devananda> nothing is above 15% translated yet, iirc
16:21:56 <ttx> yeah, so that is probably a useless merge, but still good so that we can judge on current adta
16:22:01 <devananda> k k
16:22:58 <ttx> ok, so when all your bockers merge, just approve that version bump and ping me
16:23:03 <ttx> and I'll make stuff happen
16:23:22 <ttx> questions ?
16:24:24 * devananda grumbles about slow network
16:25:21 <devananda> we have a couple related projects (ipa, discoverd, dib) which aren't being release-managed at this time
16:25:31 <devananda> so folks will be doing those releases independently
16:25:38 <devananda> any thing they should know about that?
16:25:59 <devananda> or just follow the same approach that I am with python-ironicclent
16:26:42 <ttx> I'd say just follow the same approach. We want to cut stable branches for those asap though, so that we can cap
16:27:07 * ttx is still e bit fuzzy on that part and needs to sync with dhellmann
16:27:14 <devananda> yea... i am fuzzy on that too
16:27:28 <devananda> i thnk discoverd plans to tag a stable point around April 30
16:27:39 <ttx> basically we need to follow that recent spec
16:27:48 <devananda> because it will be based on what is in RC of ironic
16:27:56 <devananda> not the other way around
16:28:19 <devananda> mmm. have a link handy? I'll make sure it gets to the right people in ironic
16:28:36 <devananda> also, launchpad tracking page has now been updated
16:28:44 <ttx> http://specs.openstack.org/openstack/openstack-specs/specs/library-stable-branches.html
16:28:54 <ttx> I'll clarify and get back to you on that
16:28:58 <devananda> cheers
16:29:02 <ttx> SlickNik: around?
16:29:44 <SlickNik> ttx: here
16:29:49 <ttx> #topic Trove
16:29:55 <ttx> #link https://launchpad.net/trove/+milestone/kilo-rc1
16:30:05 <ttx> #info 3 RC bugs left, all assigned and in progress
16:30:09 <ttx> checking that they are all active
16:30:35 <ttx> No patch yet for https://bugs.launchpad.net/trove/+bug/1430586 ?
16:30:36 <openstack> Launchpad bug 1430586 in Trove "Trove fails to send notification event using oslo.messaging" [High,In progress] - Assigned to Nikhil Manchanda (slicknik)
16:30:41 <SlickNik> ttx: 2 of them have patchsets up already.
16:30:57 <SlickNik> I'm working on https://bugs.launchpad.net/trove/+bug/1430586 so I should be able to push up a patchset today.
16:31:21 <ttx> https://review.openstack.org/#/c/155555/ looks a bit stale
16:31:32 * ttx doesn't like to depend on stale patches
16:32:45 <SlickNik> Actually, that one isn't super important — so I think we can punt that one to liberty in case it doesn't land in the next couple of days.
16:33:04 <ttx> ok
16:33:17 <ttx> Let me upload a review that you can approve when all is ready from your pov
16:33:32 <ttx> Please -2 it temporarily: https://review.openstack.org/171282
16:33:50 <ttx> Merging this one will open master for Liberty development, so only merge when you're ready for RC1
16:34:01 <ttx> Ping me when you approve it and i'll make magic happen
16:34:54 <SlickNik> ttx: awesome. Just -2'ed it. Will ping you once ready and approved.
16:35:33 <ttx> Alright looks like you're all set. We could cut RC1 on Wed/Thu
16:35:38 <ttx> Questions ?
16:35:55 <SlickNik> Nope, sounds good to me.
16:36:10 <ttx> Alright, that concludes our syncs for today
16:36:13 <ttx> Thanks !
16:36:15 <ttx> #endmeeting