08:00:36 #startmeeting ptl_sync 08:00:37 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 08:00:40 The meeting name has been set to 'ptl_sync' 08:00:41 #topic Heat 08:00:54 all looks green 08:01:14 and ready for rc1 08:01:32 asalkeld: Alright, if you don't have any bugfix in the queue, now is as good as anytime 08:01:45 cool, let's do it 08:01:50 * ttx warms up his scripts 08:02:33 let me seee if we can merge translations or requirements 08:03:34 ttx: both done 08:03:44 good! 08:03:46 https://github.com/openstack/heat/commits/master 08:03:59 within the last ~10 commits 08:04:25 It's my first one for kilo so I have to remember how to do it 08:04:33 :-) 08:05:19 OK, we need to push the version bump on master, let me propose that 08:05:40 ok 08:07:20 https://review.openstack.org/171075 08:07:25 Approve if you're happy. 08:07:38 I'll cut the Kilo proposed branch from the commit just before that one 08:07:55 ok 08:08:37 (and then tag RC1 on the created proposed branch) 08:08:49 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 AttributeError: 'InstallRequirement' object has no attribute 'url' 08:09:22 i hope that review of yours is ok 08:09:41 asalkeld: well, we'll see... 08:09:51 suddenly = since when ? 08:10:10 last hour? 08:10:40 hm, ok, will keep an eye on it 08:10:50 yeah 08:11:10 https://bugs.launchpad.net/tempest/+bug/1440984 08:11:12 Launchpad bug 1440984 in tempest "AttributeError: 'InstallRequirement' when running update.py" [Undecided,New] 08:11:19 asalkeld: if you approve the bump I can babysit the fix in the queue and tag when ready 08:12:19 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 so you can refine the list of potential show-stoppers there 08:12:47 and we'll evaluate it regularly 08:12:47 asalkeld: were you going to be on leave this week? 08:12:50 ttx: done 08:12:56 stevebaker: next week 08:13:08 stevebaker: you off this week or next? 08:13:09 ok, cool 08:13:19 this Friday and Monday 08:13:25 ttx: i am taking a holiday next week 08:13:27 asalkeld: we'll let the RC1 be used un-troubled for a few days anyway, to encourage testing 08:13:38 my monday, so should be no problem for this ptl_sync 08:13:48 ttx: stevebaker has agreed to cover for next week 08:13:54 asalkeld: I'll sync with stevebaker to see if we need a RC2 next week 08:14:03 thanks 08:14:11 in the mean time if you discover critical issues, just get them fixed on master 08:14:14 stevebaker: thanks again for covering 08:14:23 np. 08:14:23 so that we can fast-track backports if we need to 08:14:24 ttx: ok, thanks 08:15:06 asalkeld: That's all I had. Will cut RC1 in the next hours, time for that bump patch to land 08:15:17 asalkeld: thx, and congrats ! 08:15:22 ok, thanks 08:15:23 Nice work by the Heat team. 08:15:50 * asalkeld heads off to enjoy a beer 08:16:16 johnthetubaguy: around? 08:16:23 ttx: good morning 08:16:28 #info Heat RC1 to be cut asap 08:16:33 #topic Nova 08:16:47 #link https://launchpad.net/nova/+milestone/kilo-rc1 08:17:13 #info 7 release-critical bugs on the list, all assigned and in progress 08:17:35 Checking that they are all actually in progress 08:18:05 yeah, there are a few dubious ones I just pushed out, I suspect there are more 08:18:29 https://bugs.launchpad.net/nova/+bug/1438183 -- some fix merged there, is the bug still needing more ? 08:18:30 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 Oh, https://review.openstack.org/#/c/169057/ probably 08:19:03 ah, yes 08:19:06 Same for https://bugs.launchpad.net/nova/+bug/1313573 08:19:06 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 https://bugs.launchpad.net/nova/+bug/1430239 looks a bit stale 08:19:50 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 yeah, some of these look at lot like the super critical bit for kilo is done 08:20:28 I am thinking we tag them as potential and add a note, I can do that after the meeting 08:20:41 yes, but all in all, looks like the RC1 could benefit from a few more days of fixes 08:20:53 and target end of week 08:21:09 at the earliest 08:21:42 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 yeah, I think thats a good assessment 08:22:04 maybe a quick catch up on thursday? 08:22:13 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 johnthetubaguy: works for me 08:22:25 cool 08:23:09 quick general question, I am wondering what you take is on "federating" the code review more in Nova? 08:23:11 johnthetubaguy: While you're around, let me push a open-liberty patch so that you can -2 it 08:23:22 ttx: ah, cool, thats a good plan 08:24:16 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 yeah, at this point we have little choice 08:24:43 I just worry about loosing consistency across the code base 08:24:58 but that not totally worth the cost of slowing everything down 08:25:16 so we kind of had the same problem in stable 08:25:33 johnthetubaguy: please -2 : https://review.openstack.org/171078 08:25:36 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 yeah, thats true, I hadn't thought of stable like that 08:26:02 In the stable team we could not review everythijng and were lacking local expertise 08:26:25 What we put in place is the following 08:26:37 We have local review teams (per project) 08:26:59 But we vet the members there to make sure they have the basics rules 08:27:09 We ask them to ask around when unsure 08:27:24 (escalate to the "core" stable maint) 08:27:37 and then we try to keep an eye on them and check they don't do crazy stuff 08:27:47 right, that makes sense 08:27:58 So stable-maint-core became the guardians of the stable policy, more than reviewers 08:28:18 transposed to nova, you could have a core group that maintains consistency and quality standards 08:28:21 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 but still let subteams go wild 08:28:48 It's tricky, because you have to fiond a way to communicate the "standards" 08:28:58 thats true 08:29:00 for stable policy it's relatively simple 08:29:16 since you have a few rules and you can call them out when they fail to apply them 08:29:29 For "consistency" and "quality" it's a bit harder 08:29:30 yeah, less subjective 08:29:38 right 08:29:44 but I still think it's the only way to scale 08:30:01 letting go of a bit of control to gain a bit of sanity 08:30:17 I mean the other approach is splitting more out of nova, but I think we need both at this point 08:30:36 But yes, ideally each subteam would grow around a strong nucleus that has the consistency/quality mindset already 08:30:38 mostly as there is only so much you can sanely split out, and it takes years to do it properly 08:30:57 luckily, I think some of that is already happening 08:31:01 so that the subteam doesn't grow it's own culture 08:31:30 yeah, thats the worry, subteam X don't do unit tests, they hate those, etc 08:31:42 johnthetubaguy: yes we won't split out enough and fast enough to avoid losing our sanity 08:31:57 and splitting should make sense technically too 08:32:02 ttx: thats totally true, well, we have proven that quite well the last 12 months 08:32:19 ttx: if you do it wrong, you get two competing network stacks… 08:32:21 the only reason we split is because it's the most convenient way to make Gerrit support the case 08:32:41 yeah, there is some truth in that 08:32:47 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 yeah, not sure we can wait for tooling, but agreed 08:33:11 (splitting still makes sense in a lot of cases, but it's a trade-off with consistency/quality as said above) 08:33:22 yeah 08:33:45 we were struggling with, if we split it off, they do crazy things, nova dies because the scheduler is broken, boom 08:33:58 but you totally captured that above 08:34:08 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 and at that point subteam +2ers can just go with it 08:34:30 ttx: agreed, thats my current preference actually 08:34:40 well, something like that 08:34:50 and if someone abuses their rights, just revoke the privs 08:34:56 right 08:34:59 and backtrack 08:35:15 we shoudln't limit ourselves to what Gerrit lets us do 08:35:31 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 anyways, I think there is enough for me to chew on there, really appreciate your thoughts on that 08:35:59 right -- which is why I don't want to pile up more rights/duties around core reviewing 08:36:03 will make it harder to drop people 08:36:15 ah, I get you now 08:36:22 the core review group should just be the ones with +2, not the "project maintainers" 08:36:39 yeah, the current people who have time for +2, etc 08:36:48 because removing people from the latter is harder than removing people from the former 08:37:00 since it implies "you're someone in Nova" 08:37:05 yeah, fluidity is important here 08:37:13 I think we fail to add people as its hard to remove them 08:37:23 Not opposed in having the latter, just opposed to tie +2 Gerrit rights to it :) 08:37:35 right 08:37:56 I want people with +2 be the ones that spens all their time reviewing, basically 08:38:22 devananda had an interesting strawman: what if you gave Workflow+1 to a separate group from Review+2 08:38:47 ah, not read that bit, I should take a look 08:38:57 I don't think he publicly suggested that 08:38:58 yet 08:39:16 I haven't read the thread you're talking about fwiw, just came back from holiday :) 08:39:36 yeah, similar, well a long weekend anyways 08:39:47 that way you could give review rights to a subgroup, but still quick-vet for change sanity 08:40:05 yeah, thats very attractive 08:40:29 (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 Also serves as checks & balances 08:41:12 yeah, some small group 08:41:49 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 might create botlenecks at the Workflow+1 and merge conflicts, but still worth considering 08:41:55 yeah 08:42:28 well, even a loose, policy, where you can +W only for merge conflicts, could work 08:42:29 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 deva's strawman kind of addresses that fear 08:42:51 yeah, its a nice touch 08:43:24 not considered splitting those before, fancy 08:43:45 right, correctness and desirability are actually 2 different things 08:43:57 its similar to the adding a +3 that owns +W, but its less… crazy 08:44:12 except you don't give +2 to the people who do Workflow+1 08:44:17 ttx: totally true, its a battle we have reguarly 08:44:25 (they can still +1 alright) 08:44:42 but it takes into accoutn that the pTl is often too busy to maintain crazy review levels 08:44:44 ttx: yeah, true, or at least, if they have +2, thats independent and not assumed 08:45:00 good point, not thought about it that way 08:45:25 You basically have two groups -- domain experts who vet the code makes sense and is correct 08:45:42 andd rivers who decide that the change is welcome at this time in the cycle 08:45:45 drivers* 08:45:51 * anteaya likes rivers 08:46:22 frankly when I review I only ever do the latter, since I'm not an expert anywhere anymore 08:46:43 but I can still judge the impact of a change and the rationale 08:47:07 ttx: yeah, I am liking that idea, it has great promise 08:47:28 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 ttx: cool, thanks for your time, appreciate that 12:00:01 ttx: knock, knock, ready when you are ... 12:00:23 eglynn: hi! 12:00:28 #topic Ceilometer 12:00:30 #link https://launchpad.net/ceilometer/+milestone/kilo-rc1 12:00:57 a few things came up mid/late- last week 12:00:58 #info 3 RC bugs, all in progress and assigned 12:01:10 looking how far they are 12:01:17 nothing major, patches for all under review 12:01:35 the main one was https://bugs.launchpad.net/bugs/1435855 discussed on the ML etc. 12:01:36 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 the approach to resolving while keeping the desired backward compat is agreed 12:02:09 just some style issues in the review and we're good to go 12:02:19 rechecking those that were stuck with gate state this morning 12:02:34 cool 12:02:46 OK, looks like we could have a RC1 tomorrow or Thursday 12:02:46 so no major red flags or alarms 12:03:01 yep, let's chat again thurs 12:03:03 Did you merge recent requirements and translations ? 12:03:35 lemme check that 12:03:48 https://review.openstack.org/#/c/170388/ could use a +2 12:04:22 cool 12:05:56 ys, translations were merged 12:06:20 So let me propose the version bump -- you can -2 it temporarily and approve it when you're happy with things 12:06:30 sounds like a plan 12:07:48 https://review.openstack.org/171152 -- please -2 for the moment to avoid errors 12:08:07 * eglynn looks 12:09:12 -2'd while we close out the rc1 queue 12:09:17 cool, thanks 12:09:24 so when ready, just approve it and ping me 12:09:37 I'll make things happen from the commit just before that one 12:09:42 will do, thanks! 12:10:08 Questions ? Urgent matters ? 12:10:21 nope, all good otherwise 12:10:30 alright, let's do this! 12:10:34 * SergeyLukjanov ready 12:10:38 SergeyLukjanov: hi! 12:10:43 ttx: thanks for your time! :) 12:10:43 ttx, hey! 12:10:43 #topic Sahara 12:10:55 #link https://launchpad.net/sahara/+milestone/kilo-rc1 12:11:05 #info 3 RC bugs, all in progress and assigned 12:11:15 checking how far and active they are 12:11:16 we have two issues on board + bunch of doc CR that are nice to have 12:11:58 MapR related just uploaded to review, but it's simple 12:12:09 OK, so you seem pretty close too 12:12:16 * ttx runs a couple checks 12:12:33 yeah, I think tomorrow we'll be fully ready for tag 12:12:50 Translations & requirements are in 12:13:14 yup 12:13:24 SergeyLukjanov: so I'll propose the version bump so that it's ready for your approval when ready 12:13:35 ack 12:14:05 so, I will ensure all needed CRs merged (till the end of tomorrow), than merge version bump and notify you 12:14:45 https://review.openstack.org/171155 -- please -2 for the time being 12:15:46 ttx, done, thx 12:15:57 no urgent questions or issues 12:16:11 Alright! Have a nice day then 12:16:23 ttx, thank you! have a nice day too! 12:16:27 dhellmann: ready when you are 12:16:37 ttx: here 12:16:39 #topic Oslo 12:16:40 ttx, btw how is the RC-1 going for projects? 12:16:54 SergeyLukjanov: pretty good so far 12:16:59 ttx, awesome! 12:17:02 http://old-wiki.openstack.org/rc/ 12:17:10 Most projects under 10 bugs 12:17:22 which makes them likely to hit target sometimes this week 12:17:36 There will be the occasional straggler although I can't predict who that will be 12:17:43 dhellmann: Not sure we have anything to discuss 12:18:17 ttx: I can't think of anything either :-) 12:18:19 dhellmann: Do we have anything left to d release-wide as far as Oslo is concerned ? 12:18:33 I mean "release-wise" 12:18:34 we need a stable branch in the incubator repository, but that's it 12:18:43 * ttx checks 12:19:01 yes, and a final tag 12:19:20 Maybe when all the RC1s are cut, just before we branch requirements ? 12:19:22 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 yeah, that sounds about right 12:20:08 ok then, that should happen early next week 12:20:21 sounds good 12:20:31 I'm going to pycon this week, so I'll be online but only sporadically 12:20:37 ack 12:20:58 * ttx hopes to get most RC1s in before everyone bumps libs 12:21:04 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 do you mean the clients? 12:21:21 dhellmann: ok, you might want to make sure you voted on stuff before then 12:21:31 yeah, I'll do that this morning 12:21:35 dhellmann: no, genera py libs 12:21:49 Pycon usually is when people randomly bump their libs 12:21:55 and break the world 12:21:55 oh, I see 12:22:10 the pip bump this morning was just the first sign 12:22:17 oh, I missed that 12:22:27 gate all stuck because pip changed API 12:22:44 which is according to pip authors not a public API 12:22:56 (only the CLI is public API) 12:23:25 anyway, fun 12:23:35 dhellmann: have a good day and travel! 12:23:42 nice 12:23:47 thanks, ttyl! 12:23:52 gate is fixed BTW - Just got a change to pass 12:24:01 yes, We ninjafixed it 13:10:59 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 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 dhellmann: do you see "target to series" there ? 13:11:37 ttx: no 13:11:47 ok, that is probably what needs fixing 13:11:51 oh, hmm, I do on that one 13:12:00 I had one on the policy lib the other day and didn't see it there 13:12:08 is that a permission setting? 13:12:11 *yeah,; looks like ayoung is the only driver there 13:12:19 yes, need to be a driver I think 13:12:19 oh, right 13:12:52 oh, so there is another issue on oslo.messaging 13:13:00 resulting oin the "status tracked in" mess 13:13:13 ? 13:13:25 problem is, liberty should be the "active development" series 13:13:44 that's something you need to switch to match what "master" means 13:14:00 https://launchpad.net/oslo.messaging -- see "development focus" there 13:14:14 that needs to be liberty, if master switched to liberty 13:14:25 otherwise you can't backport to kilo, since master = kilo 13:14:39 let me fix that 13:15:24 here 13:16:01 so you should check that all libs that had their kilo branch cut also switched "dev focus" in LP 13:16:18 otherwise you won't be able to create kilo backport tasks there 13:16:21 I did a bunch of them, but I guess I missed a few. I'll double-check 13:16:38 I do that as part of the proposed/$SERIES branching process 13:16:55 is that scripted, then? 13:16:56 https://wiki.openstack.org/wiki/ReleaseTeam/How_To_Release#proposed.2F.24SERIES_branch_cut_.28switch_master_to_next_version.29 13:17:13 no, I do it manually 13:17:17 ah, ok 13:17:20 not sure there ius even an API for that. Checking 13:17:55 yes there is, so I could script it in theory 13:18:11 Never had the need for it because doing it for 10 projects is not that painful 13:18:22 but with oslo libs in mix, might make sense 13:18:23 yeah, I have more than that just in oslo now 13:21:12 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 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 It's because I already added kilo ? 13:22:12 hmm, weird though 13:22:48 no, that must be the reason 13:38:27 oh, duh, I didn't notice that 13:45:29 ttx: Here when you're ready! 13:45:47 mestery: hi! 13:45:51 #topic Neutron 13:46:06 #link https://launchpad.net/neutron/+milestone/kilo-rc1 13:46:22 #info 6 in-progress bugs, all assigned 13:46:25 6 left, but one of those is in the merge queue 13:46:35 checking that they are all actively worked on 13:46:35 https://bugs.launchpad.net/bugs/1439817 13:46:36 Launchpad bug 1439817 in neutron "IP set full error in kernel log" [High,In progress] - Assigned to Brian Haley (brian-haley) 13:46:38 That's the one in the merge queue 13:46:49 Ack, they should be, I just looked myself this morning 13:47:25 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 ack confirmed 13:47:53 runnign a few checks 13:48:08 cool 13:48:34 ok, requirements & translations all merged 13:48:43 Excellent! 13:49:04 checking for missing files in tarballs... 13:49:24 looks like you are a couple of days away from your rc1 tag(s) 13:49:46 Yes sir, we're getting close! 13:49:47 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 Ack, sounds good, please proceed with that. 13:50:32 ok, I'll ping you with review numbers in a sec, so that you can temporarily -2 them 13:50:40 Perfect! 13:51:54 neutron -> https://review.openstack.org/171200 13:52:05 -2 :) 13:52:13 excellent. 13:52:35 I think we just need to close out these last bugs and then we're good! 13:53:01 neutron-fwaas -> https://review.openstack.org/171202 13:53:24 -2 :) 13:54:21 neutron-lbaas -> https://review.openstack.org/171205 13:55:26 -2 :) 13:56:18 neutron-vpnaas -> https://review.openstack.org/171206 13:56:46 Also -2 :) 13:56:48 Thanks for those! 13:56:50 Let's target around Thursday to tag 13:57:15 Questions ? 13:57:36 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 np, business as usual :) 13:58:24 :) 13:58:33 Thanks ttx, we'll sync thursday then! 13:58:40 Now, time to run the Neutron meeting :) 13:59:23 cheers 14:21:28 nikhil_k: ready when you are 14:26:26 ttx: hey, another meeting carried over 14:26:32 sorry about that 14:26:38 np 14:26:43 #topic Glance 14:27:10 #link https://launchpad.net/glance/+milestone/kilo-rc1 14:27:17 I see 3 bugs on the RC list 14:27:27 #info 3 RC bugs, all assigned and in progress 14:27:56 ttx: yeah, waiting on gate 14:28:11 this, https://launchpad.net/bugs/1434237 https://review.openstack.org/#/c/166909/ 14:28:13 Launchpad bug 1434237 in Glance "glance-manage db_export_metadefs fails with NoSuchColumnError" [High,In progress] - Assigned to Ashish (ashish-jain14) 14:28:18 ack 14:28:22 I think it has some discussion going 14:28:29 So it looks like you're pretty close 14:28:34 we can mark k2 to give it some time 14:28:37 yes 14:28:40 we should be good 14:28:46 one question though 14:28:50 * ttx runs a few tests 14:29:03 do we need a stable branch for store and client before RC1? 14:29:13 we don't have one last time I checked 14:29:34 not before, but certainly not far after 14:29:38 dhellmann: ^ ? 14:29:39 sure 14:29:59 sometime close to RC2 , or beginning or RC3 14:30:06 s/or/of/ 14:30:13 well in theory you won't have a RC2 :) 14:30:24 ttx: please do not say that 14:30:46 one sec 14:30:54 https://bugs.launchpad.net/glance/+bugs?field.tag=kilo-rc-potential 14:31:00