14:52:25 #startmeeting incub_sync 14:52:26 Meeting started Thu Apr 9 14:52:25 2015 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:52:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:52:29 The meeting name has been set to 'incub_sync' 14:52:30 #topic Manila 14:52:40 it's one of /those/ days 14:52:43 so the news is not good for us 14:52:51 we've fixed a ton of bugs, but new ones keep coming in 14:53:02 #link https://launchpad.net/manila/+milestone/kilo-rc1 14:53:12 bswartz: it's not a big deal, ideally you all would RC1 next week 14:53:17 everyone claims their bugs are critical 14:53:23 well of course 14:53:45 How about I push a "open liberty" patch and you -2 it until ytou're ready for RC1 ? 14:54:01 what would that achieve? 14:54:19 Then we can async 14:54:30 You approve it when you're OK, and I can pick it up 14:54:41 That serves as a formal signoff 14:54:44 well I was just planning to send you a commit hash when we've got the bugs to zero 14:54:58 we'll still need to push a version bump 14:55:04 so if you do it that way, then you take the parent of the "open liberty" patch and make that the new proposed branch? 14:55:08 and I still need to cut the stable/kilo branch from the previous commit 14:55:11 yes 14:55:24 that works for me 14:55:25 that ensures nothing slips "between" cycles 14:55:48 how much time would you say we have left? 14:56:22 well, since you're not in the integrated release, failure only reflects bad on you, so it's your risk management, not mine 14:56:33 So you have until April 30 :) 14:56:34 BUT 14:56:44 Usually releasing a RC1 gets new people to test the thing 14:56:49 and new critical bugs to be uncovered 14:56:57 yeah that was my thinking 14:56:58 so it's a good thing to do, at least 2 weeks before final 14:57:07 I'd say you have until end of next week 14:57:17 that's more time than I'd like to wait, but okay 14:57:17 after that that will start to impact the quality adversely 14:57:23 at least we're not about to run into a wall 14:58:00 bswartz: ok, please -2 temporarily https://review.openstack.org/172104 14:58:29 and just approve it when you're happy with stuff. And ping me here. Then I'll make magic hapen first chance I get :) 14:58:41 okay thank you 14:58:59 Alright, have a good week bugfixing then 14:59:11 or a bad week, in my case 14:59:14 hehe 14:59:39 okay gotta run 14:59:56 run run 15:00:00 redrobot: around? 15:00:06 ttx o/ 15:00:15 #topic Barbican 15:00:28 #link https://launchpad.net/barbican/+milestone/kilo-rc1 15:00:34 Still 3 RC bugs up 15:00:52 I guess you're on track for RC1 next week too 15:01:14 Let me push a "open liberty" version bump patch and you -2 it until you're ready for RC1 ? 15:01:30 sure thing, that sounds great 15:01:41 I'm hoping we'll have these bugs fixed early next week. 15:01:52 OK, please -2 temporarily: https://review.openstack.org/172106 15:02:07 When ready you approve that, and I'll cut the release branch from the previous commit 15:02:35 ok, sounds good. 15:02:43 Questions? 15:03:15 none at this time. Thanks, ttx 15:03:23 alright, nice & fast 15:03:29 flaper87: ready when you are 15:17:08 Kiall: around? 15:17:12 flaper87: around? 15:21:36 ttx: I am, last patch is still gating.. We hit, of all things, a kernel bug during the gate. lol. 15:22:13 can we sync on designate now ? 15:22:17 Yes, we can 15:22:50 #topic Designate 15:23:06 #link https://launchpad.net/designate/+milestone/kilo-rc1 15:23:15 So - I have a Q around the "Mark API v2 Stable" BP.. We're planning on making that call after 1 more week of review, which is before final.. but after rc1. The change itself is a trivial one liner, but I'm not 100% sure it's totally acceptable to do so 15:23:23 I count 3 RC bugs, not "one patch" ? 15:23:50 Those are to be bumped - only Critical/Blocker will hold us on rc1 15:23:56 Well, you should RC1 once you have the go-ahead on that, not after 15:24:05 I mean, not before 15:24:29 I prefer to wait to tag RC1 rather than pretend that this could be the release while we know it won't 15:24:42 and ask people to test something that is not anything like the release API-wise 15:24:59 Sounds good, I figured you would say that :) I'll push the team to review ASAP. 15:25:07 So I'd rather hold until next week 15:25:14 It's fine for incubated projects anyway 15:25:21 Busy enough with the others right now 15:25:45 That said I'd like to push the open-liberty version bump so that it's ready when you need it 15:25:56 Sure, that's fine with me! 15:26:05 let me do that 15:26:41 Please -2 temporarily: https://review.openstack.org/172116 15:26:53 My other question would be with the client 15:27:13 Do you need a new release ? It's a bit late to do that now 15:27:22 but then your current one is a bit stale 15:27:32 No, no new release is needed.. 15:28:10 OK, maybe answer that answering you're just fine as is thank you very much 15:28:10 and stale just means it still works ;) 15:28:27 since I suggested designateclient update there 15:28:44 so that nobody goes wild 15:28:59 Kilo stable branches for "other" libraries <-- This a ML thead? I missed it. 15:29:06 yes openstack-dev 15:29:12 That's the topic 15:29:16 I mean "subject" 15:29:26 under the [all] topic 15:29:35 Sure, I'll have a read and reply after this meet 15:29:53 (Too many replies to read during the meet) 15:32:15 Just prodded the team around that mark V2 Stable BP, will get that closed our early next week at latest. 15:34:29 Anything else before we wrap up for today? 15:34:43 nope 15:34:50 flaper87: ready when you are 15:34:56 Cool, will read that thread now 15:35:00 Thanks as always :) 15:35:17 morganfainberg: care to ask your question here ? -infra is a bit busy with 3 parallel discussions right now 15:35:34 sure 15:35:37 so... 15:35:52 we can't land changes in master for keystoneclient, middleware, novaclient (i think) among other things 15:36:08 because these projects do not have stable/juno & stable/icehouse branches 15:36:29 example 15:37:01 https://review.openstack.org/#/c/166438/ 15:37:12 because the dependencies cannot be resolved for juno 15:37:17 it explodes 15:37:43 the juno job is "use master unless stable/juno branch is available, then use that" 15:37:54 our options are "create stable branches retoactively" 15:37:54 yes 15:38:05 or remove that check/gate job 15:38:07 That would not be the first time we do that 15:38:16 (create stable branches retroactively) 15:38:27 i don't mind which way we go 15:38:45 but i'd like to do one more release of keystoneclient and keystonemiddleware before kilo g-r is cut 15:39:15 but this is blocking it up. 15:39:18 morganfainberg: will that require the min version to be bumped as well ? 15:39:23 nope 15:39:27 just the cap. 15:39:27 ok good 15:39:47 sdague: I think creating branches retroactively is the lesser of the two evils there. Thoughts , 15:39:48 ? 15:40:22 i tend to agree, but since i don't have access to create the branches :) and we determined last night in -infra we wanted to ask you before making a choice 15:40:37 we are here today 15:40:38 <- flaper87 <- ttx 15:40:53 (here whenever you're ready) 15:40:55 morganfainberg: I'm slightly worried about security patches that may be needed on that branch... how far back would you go with stable/juno ? Just the last tag ? 15:41:08 #topic Zaqar 15:41:24 I can parallelize up to 3 discussion before becoming crazy 15:41:24 o/ 15:41:34 ttx: ok, whatever you think 15:41:40 #link https://launchpad.net/zaqar/+milestone/kilo-rc1 15:41:51 ttx: https://review.openstack.org/#/c/171438/ <- this patch fixes the problem blocking ceilometer and zaqar 15:41:54 i'm willing to commit as PTL that 1.4.x is juno and will receive backports in a semver-sane-way 15:42:04 famous last words 15:42:04 as soon as that lands, there are 2 patche sto recheck and then we can cut it 15:42:07 for middleware 15:42:11 but thats just me. 15:42:30 i don't want to speak on behalf of any other projects ;) 15:42:37 fesp: let me propose the liberty version bump so that it's ready for when you are ready 15:42:47 ttx: sounds perfect 15:42:53 other than that, I think we're good 15:42:55 nothing else to add 15:42:58 fesp: please -2 temporarily: https://review.openstack.org/172125 15:43:12 Plan is to tag rc1 on incubated projects sometimes next week 15:43:29 morganfainberg: so you need me to create the branch at this point, right 15:43:36 ttx: done 15:43:45 ttx, if that is the path. yes. 15:43:50 morganfainberg: branch_es_ 15:43:57 ttx: I'll ping you as soon as those patches land 15:43:58 ttx, and i'm happy with that path. 15:43:59 fesp: okk great, have a good day! 15:44:04 thank you, you too! 15:44:06 morganfainberg: let me check a few things 15:44:39 ttx, i also would like to change the g-r for juno to include 1.4.x for juno in this case as well 15:44:51 so we can do semver sane updates. 15:44:56 and include backports 15:45:08 but that is a slightly related-but-not-the-same conversation 15:45:12 morganfainberg: so we'd branch stable/juno for keystonemiddleware at 1.5.0? 15:45:16 or earlier ? 15:45:26 ttx, 1.4.0, current cap 15:45:49 oh, it's capped on stable/juno now ? Great 15:45:59 uhm.. wait a sec... 15:46:14 https://github.com/openstack/requirements/blob/stable/juno/global-requirements.txt#L40 15:46:16 yeah 15:46:29 1.4.0 is the cap in stable/juno for middleware 15:46:32 We'll have to check if we need security backports there though 15:46:52 Could you check recent advisories for that ? Or should I prod someone on the VMT to do that ? 15:47:05 see if we actually don't already need a 1.4.1 :) 15:48:08 So... keystonemiddleware stable/juno at 02abaa1d2711a3d5fc0dd020f05133618e5b7dde (1.4.0) 15:48:31 ttx, we have an open bug that likely should be backported 15:48:45 ttx, in fact... i think you commented [or tristan did] today 15:48:45 cool. Nice past 15:49:20 we will need to look through all the advisories and make sure they're backported though 15:49:24 python-keystoneclient stable/juno at 4ee6e3302ae53c8858c0e48c27a46c292e771afb (1.1.0) ? 15:49:28 looking 15:49:43 correct 15:49:44 1.1.0 15:50:12 so the good thing here is that you did not consume any 1.1.1 or 1.4.1 15:50:21 otherwise the .Z would have been tainted 15:50:40 so it looks like all lights are green 15:50:59 yeah 15:51:01 Ready to pull trigger if you confirm. 15:51:10 checking now 15:51:26 Do you need to do the same for stable/icehouse ? 15:51:53 ttx, confirmed on the juno branches 15:52:07 ttx, i am going to say probably yes. 15:52:16 we're likely to hit similar issues... 15:52:23 let's check if the .Z is clean there 15:52:29 looking now 15:53:08 no middleware for icehouse 15:53:09 python-keystoneclient capped to 0.11.2 15:53:23 was there a 0.11.3... ? 15:53:43 and no 0.11.3 15:53:44 you sir seem to be lucky 15:53:47 for keystoneclient 15:54:04 ttx, it was all planned! and i'm sticking to that story :P 15:54:19 so for stable/icehouse... 6d85d182a2cbd50f0e6a8477c97a84e149addbce (0.11.2) 15:54:40 yesyes 15:54:45 Alright, let's do this 15:54:57 i'm sure other client libs are going to need this 15:55:07 but it might get ugly with tainted .Z 15:55:25 keystonemiddleware stable/juno at 02abaa1d2711a3d5fc0dd020f05133618e5b7dde DONE 15:56:09 python-keystoneclient stable/juno at 4ee6e3302ae53c8858c0e48c27a46c292e771afb DONE 15:56:42 python-keystoneclient stable/icehouse 6d85d182a2cbd50f0e6a8477c97a84e149addbce DONE 15:56:56 All set, let's hope we just didn't break the world 15:57:00 ttx, thank you very much sir. 15:57:12 i'm going to go issue a nice recheck on some stuff 15:57:26 and i do agree.... no breakage *knock on wood* 15:57:32 Please indicate that you intend to do another keystoneclient release on that ML thread -- you only mentioned keystonemiddleware 15:57:40 will do 15:57:48 I'll use that thread as an external memory storage 15:57:57 just going to confirm KSC has something to release before responding 15:58:00 i am near certain it does 15:58:35 OK, please check if anything needs backporting too 16:06:45 ttx, yep. will do 16:07:29 ttx, i will also need to get python-keystoneclient-kerberos into the stable branch fun when we do it for kilo. i'll remind you as we need it/get there [there are other things that must happen before that one is ready] 16:08:00 ok 16:12:21 I'll be back in a couple hours to push ceilometer and neutron. 16:31:28 ttx: back 18:35:36 ttx: Neutron is ready to tag, all 4 Liberty opening patches have merged. 18:39:57 mestery: ok, I'm on it 19:09:59 mestery: done 19:10:05 ceilometer is done too 19:10:11 ttx: Woot! 19:10:23 * ttx checks if something else looks close 19:10:28 before calling it a day 19:12:52 ok, looks like we won't have another winner tonight 19:13:42 back tomorrow 06:40:27 mikal: FTR there is no pause. When https://review.openstack.org/#/c/171078/ is merged, Liberty starts 06:40:39 I cut the release branch from the previous commit in history 06:42:04 So if you're ready you should probably approve that 06:42:42 (otherwise I'll check with zz_johnthetubagu when he is no longer zz) 07:08:54 ttx: I just emailed you the SHA for RC1, and +2'ed that review, so I think we're good to go 07:09:00 You'll need John to remove his -2 though 07:09:07 Oh. 07:09:14 Right. 07:09:32 mikal: anything that sneaks in before that review will be in Kilo, I fear 07:09:50 I'll make sure he approves it first thing when he gets up 07:10:34 Yeah, two things have snuck in already, but they look harmless to me 07:10:45 I thought I was meant to provide a SHA, but perhaps I am confused 07:11:22 nope. SHAs are for milestone tags. For RC1 we need to bump to liberty and then I take the previous commit and create the kilo release branch from it 07:11:31 Ahhh, ok 07:11:34 Fair enough then 07:11:43 Regardless, I think I've done those thigns now 07:11:55 Indeed 07:12:13 I'll make magic happen from there 07:12:51 Thanks 08:20:16 mikal: ttx: that change should be in the gate now 08:21:32 yep, saw that, thx! 08:21:37 np 08:21:59 sorry we are using some pacific island time again! 09:14:28 ttx: just checking, now we are merged, I guess liberty is open? 09:14:36 yes 09:14:52 Triggering the big machine now to cut proposed/kilo 09:15:00 ttx: cool, I thoughts that how it worked, cool 09:15:03 ttx: cool 09:15:21 ttx: thanks for you help pushing on this, as always! 09:15:40 cheers and congrats! 09:55:04 nikhil_k: Looks like you're ready to go ? 11:01:14 I guess we should send a "liberty is open for nova" email to -dev? 11:02:49 * mikal sends that email 11:29:37 mikal: Sure. it's announced at the end of the rc1 email but a bit hidden 12:59:10 ttx: so what's left for RCs? 12:59:25 Glance Horizon Ironic and Swift 12:59:32 ok 12:59:48 I'll have to doublecheck if we need to wait on Swift, but I guess we do 12:59:55 they have a time line? curious when we can cut over g-r 13:00:03 Ironic Monday, Swift Tuesday 13:00:11 Glance and Horizon hopefully today 13:00:17 ok, sounds reasonable 13:00:44 yes, it's not going too bad. 13:00:50 Let me compare with previous cycle(s) 13:02:58 For Juno last RC1s were done by Oct 6 (swift) Oct 3 (others) for an Oct 16 release 13:03:21 For Icehouse last RC1s were done by Apr 4 (swift) and Apr 2 (others) for a Apr 17 release 13:03:36 So we are 10 days earlier. 13:03:48 cool 13:03:55 err well 13:04:30 By Tuesday we'll be D-16 while at Juno we were D-10 and for Icehouse D-13 13:04:46 so 3-6 days earlier, rather 13:06:20 yes and for Juno we waited until after Swift to unfreeze requirements. 13:07:00 so, is there a reason for that? because swift doesn't do the requirements sync like other projects anyway 13:07:15 which is why I was looking into it 13:07:52 It might have just been laziness 13:08:45 sdague: They could hold on requirements syncs for a few days. They don't really do them anyway 13:09:56 But then if they hit Tuesday it's a bit of a non-issue 13:19:15 agree 14:08:28 david-lyle: ping me when around 14:08:35 nikhil_k: ping me when around 14:18:33 ttx: hi 14:20:12 nikhil_k: glance looks ready from where I stand... Anything you're waiting for ? 14:20:50 double checking 14:21:59 ttx: looks good 14:22:11 nikhil_k: ok, feel free to approve that open-liberty patch then 14:22:18 ttx: will you be sending a bulk email to ML with RCs? 14:22:22 https://review.openstack.org/#/q/branch:master+topic:open-liberty,n,z 14:22:31 ttx: Just want to wait a few days to see how RC1 is 14:22:33 yes, I'll take it from there, just approve the review :) 14:22:36 then consider RC2 14:22:55 ttx: so we can open Liberty even if we want RC2? 14:23:18 yes 14:23:24 let me explain 14:23:30 You push the libert version bump on master 14:23:31 ttx: ok, please do.. 14:23:48 then I cut a kilo release branch from the commit just before this one 14:24:00 And I tag that same commit as RC1 14:24:18 Then if you need an RC2 you push the bugfix to master, backport it for proposed/kilo 14:24:25 and we tag proposed/kilo again as RC2 14:24:26 etc 14:24:34 perfect 14:24:36 makes sense 14:24:47 and about communication for this? 14:25:12 Would you email cover the RC1 part and I can try to explain this to people in a meeting? 14:25:13 I mention liberty being open in the RC1 announcement 14:25:20 Doc is at https://wiki.openstack.org/wiki/Release_Cycle 14:25:21 Cool 14:25:34 or https://wiki.openstack.org/wiki/Branch_Model 14:25:40 people have questions even with the doc :| 14:26:43 Thanks for the links 14:27:15 ttx: approving the review now 14:28:30 ttx: done. https://review.openstack.org/#/c/171227/ 14:28:40 cool, will branch and tga ocne that's in 14:28:44 tag once* 14:30:57 thanks 14:33:56 ttx: here 14:34:15 david-lyle: should we wait anymore ? 14:34:37 The only reason to wait is django-openstack-auth version 14:34:58 I have https://review.openstack.org/#/c/172123/1 posted 14:35:21 but not entirely sure that's sufficient to remove the py26 job from the gate for d-o-a 14:35:42 let's ask on #-infra 14:36:12 ok, I did yesterday, but I think it got lost in the other things happening 14:36:21 sdague: so it looks like we have incoming: python-cinderclient django_openstack_auth python-barbicanclient python-ironicclient 14:36:45 so.... why? 14:37:22 we've done *all* our validation against the older versions for the servers 14:37:51 let's see... 14:38:14 thingee says "we do have some good fixes" but could skip it 14:38:25 I feel like any client releases need a High priority bug 14:38:34 for django_openstack_auth I'll let david-lyle explain 14:39:13 it's requirements mismatch 14:39:17 barbicanclient... "The planned version is 3.1.0. [1] and it will include features landed during FFE." -- since it's not integarted it flies below radar 14:39:52 but, that barbicanclient statement is nonsense 14:40:04 ironicclient... "I've tagged a 0.5.0 version two days ago, and plan a quick fix (0.5.1) today." except he didn't 14:40:04 there are no consumers of those features as a library in the kilo release 14:40:12 horizon supports django 1.7 and actually django_openstack_auth 1.1.9 supports django 1.7, but it's requirements list <1.7 14:40:42 david-lyle: ok, that's a legit bug 14:40:53 and I'd say that's valid to get this out 14:42:15 david-lyle: you need the py26 disable in first right 14:42:51 yes, https://review.openstack.org/#/c/172123/1 14:43:06 have I mentioned how much I'd like to run away from Django recently 14:43:19 david-lyle: ok, +A on the project-config change 14:43:31 we can probably resist the cinder one, since thingee wasn't originally planning to push for it 14:44:08 yeh, honestly, these library releases are mostly totally gratuitous, and *unneeded* in any way by the kilo release 14:44:18 barbican is an interesting one. In my simplified view it's not integrated so I shouldn't care. But turns out I have to 14:44:39 * ttx checks what depends on it 14:44:50 I know there is nova code that uses it 14:44:51 sdague: ok thanks, once that merges, I'll merge the requirements bump 14:44:52 optionally 14:45:47 So.. they could wait a few days and release it after the cap. Or release it now and we cap with it in it 14:45:57 so, I think we need to figure out how to get the PTLs to understand what libraries shipped with the kilo release are for 14:46:02 except our testing until now was done with the previous version 14:46:16 so the former is safer 14:46:23 right 14:46:43 which is why requirements goes into freeze at M3 14:47:02 so that all our RC testing is basically on the same code 14:47:07 The trick is in absolute they want the client version in kilo to expose the features in kilo 14:47:20 that's irrelevant 14:47:23 only for different meaning of "in kilo" 14:47:33 right 14:47:44 just release a new version on release day 14:47:47 people can use it 14:47:53 So the optimal solution is.. for tehm to release it between the cap and the release day 14:48:02 yeh 14:48:11 I think we could convince redrobot to do that 14:48:20 it's the confused bit of CLI use and library us in kilo 14:48:31 as always 14:48:54 Let's see.. ironic 14:49:33 tagged 0.5.0 4 days ago 14:49:50 plans to do a 0.5.1 14:51:49 Looks like it's time for a "no client library release please" thread 14:52:30 to explain the difference between exposing features in CLI and screwing integrated release testing 14:53:57 yeh 14:55:31 sdague: are you pissed off enough to write it ? Or should I ? 14:56:19 no, I'm out of energy to be mad about this, especially as I'm actually still trying to get grenade split up for big tent support 15:00:18 ok, will do 15:08:51 sdague: could you quickcheck facts in https://etherpad.openstack.org/p/0VFegeLsl0 ? 15:09:51 wfm 15:09:55 thx again for helping me through this maze :) 15:18:58 morganfainberg: oh, you wanted to do a keystonemiddleware / python-keystoneclient too. We should discuss that as well 15:19:23 Yes. 15:21:00 The ksm release should be (will check) a .Z relapse to sync global req. it can wait for cap if needed. 15:21:28 I've been holding any major changes back to be sure we didn't introduce weird behavior. 15:21:57 Client has some pending fixes but likely nothing that needs to land in kilo (but would be nice to have) 15:22:07 Again, not the end of the world if it misses. 15:23:04 So.. I can hold these and wait for cap and we g-r update middleware and call it a day. 15:23:17 Once cap/ branch is cut. 15:23:34 * morganfainberg is trying to stay out of sdague 's way. 15:24:54 That's the safe attitude :) 15:32:21 ttx: what's the requirements sync you're waiting on swift for? what you and sdague were talking about? 15:32:29