14:52:25 <ttx> #startmeeting incub_sync
14:52:26 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:52:29 <openstack> The meeting name has been set to 'incub_sync'
14:52:30 <ttx> #topic Manila
14:52:40 <ttx> it's one of /those/ days
14:52:43 <bswartz> so the news is not good for us
14:52:51 <bswartz> we've fixed a ton of bugs, but new ones keep coming in
14:53:02 <ttx> #link https://launchpad.net/manila/+milestone/kilo-rc1
14:53:12 <ttx> bswartz: it's not a big deal, ideally you all would RC1 next week
14:53:17 <bswartz> everyone claims their bugs are critical
14:53:23 <ttx> well of course
14:53:45 <ttx> How about I push a "open liberty" patch and you -2 it until ytou're ready for RC1 ?
14:54:01 <bswartz> what would that achieve?
14:54:19 <ttx> Then we can async
14:54:30 <ttx> You approve it when you're OK, and I can pick it up
14:54:41 <ttx> That serves as a formal signoff
14:54:44 <bswartz> well I was just planning to send you a commit hash when we've got the bugs to zero
14:54:58 <ttx> we'll still need to push a version bump
14:55:04 <bswartz> 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 <ttx> and I still need to cut the stable/kilo branch from the previous commit
14:55:11 <ttx> yes
14:55:24 <bswartz> that works for me
14:55:25 <ttx> that ensures nothing slips "between" cycles
14:55:48 <bswartz> how much time would you say we have left?
14:56:22 <ttx> 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 <ttx> So you have until April 30 :)
14:56:34 <ttx> BUT
14:56:44 <ttx> Usually releasing a RC1 gets new people to test the thing
14:56:49 <ttx> and new critical bugs to be uncovered
14:56:57 <bswartz> yeah that was my thinking
14:56:58 <ttx> so it's a good thing to do, at least 2 weeks before final
14:57:07 <ttx> I'd say you have until end of next week
14:57:17 <bswartz> that's more time than I'd like to wait, but okay
14:57:17 <ttx> after that that will start to impact the quality adversely
14:57:23 <bswartz> at least we're not about to run into a wall
14:58:00 <ttx> bswartz: ok, please -2 temporarily https://review.openstack.org/172104
14:58:29 <ttx> 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 <bswartz> okay thank you
14:58:59 <ttx> Alright, have a good week bugfixing then
14:59:11 <bswartz> or a bad week, in my case
14:59:14 <ttx> hehe
14:59:39 <bswartz> okay gotta run
14:59:56 <ttx> run run
15:00:00 <ttx> redrobot: around?
15:00:06 <redrobot> ttx o/
15:00:15 <ttx> #topic Barbican
15:00:28 <ttx> #link https://launchpad.net/barbican/+milestone/kilo-rc1
15:00:34 <ttx> Still 3 RC bugs up
15:00:52 <ttx> I guess you're on track for RC1 next week too
15:01:14 <ttx> Let me push a "open liberty" version bump patch and you -2 it until you're ready for RC1 ?
15:01:30 <redrobot> sure thing, that sounds great
15:01:41 <redrobot> I'm hoping we'll have these bugs fixed early next week.
15:01:52 <ttx> OK, please -2 temporarily: https://review.openstack.org/172106
15:02:07 <ttx> When ready you approve that, and I'll cut the release branch from the previous commit
15:02:35 <redrobot> ok, sounds good.
15:02:43 <ttx> Questions?
15:03:15 <redrobot> none at this time.  Thanks, ttx
15:03:23 <ttx> alright, nice & fast
15:03:29 <ttx> flaper87: ready when you are
15:17:08 <ttx> Kiall: around?
15:17:12 <ttx> flaper87: around?
15:21:36 <Kiall> ttx: I am, last patch is still gating.. We hit, of all things, a kernel bug during the gate. lol.
15:22:13 <ttx> can we sync on designate now ?
15:22:17 <Kiall> Yes, we can
15:22:50 <ttx> #topic Designate
15:23:06 <ttx> #link https://launchpad.net/designate/+milestone/kilo-rc1
15:23:15 <Kiall> 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 <ttx> I count 3 RC bugs, not "one patch" ?
15:23:50 <Kiall> Those are to be bumped - only Critical/Blocker will hold us on rc1
15:23:56 <ttx> Well, you should RC1 once you have the go-ahead on that, not after
15:24:05 <ttx> I mean, not before
15:24:29 <ttx> 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 <ttx> and ask people to test something that is not anything like the release API-wise
15:24:59 <Kiall> Sounds good, I figured you would say that :) I'll push the team to review ASAP.
15:25:07 <ttx> So I'd rather hold until next week
15:25:14 <ttx> It's fine for incubated projects anyway
15:25:21 <ttx> Busy enough with the others right now
15:25:45 <ttx> That said I'd like to push the open-liberty version bump so that it's ready when you need it
15:25:56 <Kiall> Sure, that's fine with me!
15:26:05 <ttx> let me do that
15:26:41 <ttx> Please -2 temporarily: https://review.openstack.org/172116
15:26:53 <ttx> My other question would be with the client
15:27:13 <ttx> Do you need a new release ? It's a bit late to do that now
15:27:22 <ttx> but then your current one is a bit stale
15:27:32 <Kiall> No, no new release is needed..
15:28:10 <ttx> OK, maybe answer that <Kilo stable branches for "other" libraries> answering you're just fine as is thank you very much
15:28:10 <Kiall> and stale just means it still works ;)
15:28:27 <ttx> since I suggested designateclient update there
15:28:44 <ttx> so that nobody goes wild
15:28:59 <Kiall> Kilo stable branches for "other" libraries <-- This a ML thead? I missed it.
15:29:06 <ttx> yes openstack-dev
15:29:12 <ttx> That's the topic
15:29:16 <ttx> I mean "subject"
15:29:26 <ttx> under the  [all] topic
15:29:35 <Kiall> Sure, I'll have a read and reply after this meet
15:29:53 <Kiall> (Too many replies to read during the meet)
15:32:15 <Kiall> Just prodded the team around that mark V2 Stable BP, will get that closed our early next week at latest.
15:34:29 <Kiall> Anything else before we wrap up for today?
15:34:43 <ttx> nope
15:34:50 <ttx> flaper87: ready when you are
15:34:56 <Kiall> Cool, will read that thread now
15:35:00 <Kiall> Thanks as always :)
15:35:17 <ttx> morganfainberg: care to ask your question here ? -infra is a bit busy with 3 parallel discussions right now
15:35:34 <morganfainberg> sure
15:35:37 <morganfainberg> so...
15:35:52 <morganfainberg> we can't land changes in master for keystoneclient, middleware, novaclient (i think) among other things
15:36:08 <morganfainberg> because these projects do not have stable/juno & stable/icehouse branches
15:36:29 <morganfainberg> example
15:37:01 <morganfainberg> https://review.openstack.org/#/c/166438/
15:37:12 <morganfainberg> because the dependencies cannot be resolved for juno
15:37:17 <morganfainberg> it explodes
15:37:43 <morganfainberg> the juno job is "use master unless stable/juno branch is available, then use that"
15:37:54 <morganfainberg> our options are "create stable branches retoactively"
15:37:54 <ttx> yes
15:38:05 <morganfainberg> or remove that check/gate job
15:38:07 <ttx> That would not be the first time we do that
15:38:16 <ttx> (create stable branches retroactively)
15:38:27 <morganfainberg> i don't mind which way we go
15:38:45 <morganfainberg> but i'd like to do one more release of keystoneclient and keystonemiddleware before kilo g-r is cut
15:39:15 <morganfainberg> but this is blocking it up.
15:39:18 <ttx> morganfainberg: will that require the min version to be bumped as well ?
15:39:23 <morganfainberg> nope
15:39:27 <morganfainberg> just the cap.
15:39:27 <ttx> ok good
15:39:47 <ttx> sdague: I think creating branches retroactively is the lesser of the two evils there. Thoughts ,
15:39:48 <ttx> ?
15:40:22 <morganfainberg> 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 <morganfainberg> we are here today
15:40:38 <fesp> <- flaper87 <- ttx
15:40:53 <fesp> (here whenever you're ready)
15:40:55 <ttx> 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 <ttx> #topic Zaqar
15:41:24 <ttx> I can parallelize up to 3 discussion before becoming crazy
15:41:24 <fesp> o/
15:41:34 <sdague> ttx: ok, whatever you think
15:41:40 <ttx> #link https://launchpad.net/zaqar/+milestone/kilo-rc1
15:41:51 <fesp> ttx: https://review.openstack.org/#/c/171438/ <- this patch fixes the problem blocking ceilometer and zaqar
15:41:54 <morganfainberg> 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 <ttx> famous last words
15:42:04 <fesp> as soon as that lands, there are 2 patche sto recheck and then we can cut it
15:42:07 <morganfainberg> for middleware
15:42:11 <morganfainberg> but thats just me.
15:42:30 <morganfainberg> i don't want to speak on behalf of any other projects ;)
15:42:37 <ttx> fesp: let me propose the liberty version bump so that it's ready for when you are ready
15:42:47 <fesp> ttx: sounds perfect
15:42:53 <fesp> other than that, I think we're good
15:42:55 <fesp> nothing else to add
15:42:58 <ttx> fesp: please -2 temporarily: https://review.openstack.org/172125
15:43:12 <ttx> Plan is to tag rc1 on incubated projects sometimes next week
15:43:29 <ttx> morganfainberg: so you need me to create the branch at this point, right
15:43:36 <fesp> ttx: done
15:43:45 <morganfainberg> ttx, if that is the path. yes.
15:43:50 <ttx> morganfainberg: branch_es_
15:43:57 <fesp> ttx: I'll ping you as soon as those patches land
15:43:58 <morganfainberg> ttx, and i'm happy with that path.
15:43:59 <ttx> fesp: okk great, have a good day!
15:44:04 <fesp> thank you, you too!
15:44:06 <ttx> morganfainberg: let me check a few things
15:44:39 <morganfainberg> 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 <morganfainberg> so we can do semver sane updates.
15:44:56 <morganfainberg> and include backports
15:45:08 <morganfainberg> but that is a slightly related-but-not-the-same conversation
15:45:12 <ttx> morganfainberg: so we'd branch stable/juno for keystonemiddleware at 1.5.0?
15:45:16 <ttx> or earlier ?
15:45:26 <morganfainberg> ttx, 1.4.0, current cap
15:45:49 <ttx> oh, it's capped on stable/juno now ? Great
15:45:59 <morganfainberg> uhm.. wait a sec...
15:46:14 <morganfainberg> https://github.com/openstack/requirements/blob/stable/juno/global-requirements.txt#L40
15:46:16 <morganfainberg> yeah
15:46:29 <morganfainberg> 1.4.0 is the cap in stable/juno for middleware
15:46:32 <ttx> We'll have to check if we need security backports there though
15:46:52 <ttx> Could you check recent advisories for that ? Or should I prod someone on the VMT to do that ?
15:47:05 <ttx> see if we actually don't already need a 1.4.1 :)
15:48:08 <ttx> So... keystonemiddleware stable/juno at 02abaa1d2711a3d5fc0dd020f05133618e5b7dde (1.4.0)
15:48:31 <morganfainberg> ttx, we have an open bug that likely should be backported
15:48:45 <morganfainberg> ttx, in fact... i think you commented [or tristan did] today
15:48:45 <ttx> cool. Nice past
15:49:20 <morganfainberg> we will need to look through all the advisories and make sure they're backported though
15:49:24 <ttx> python-keystoneclient stable/juno at 	4ee6e3302ae53c8858c0e48c27a46c292e771afb (1.1.0) ?
15:49:28 <morganfainberg> looking
15:49:43 <morganfainberg> correct
15:49:44 <morganfainberg> 1.1.0
15:50:12 <ttx> so the good thing here is that you did not consume any 1.1.1 or 1.4.1
15:50:21 <ttx> otherwise the .Z would have been tainted
15:50:40 <ttx> so it looks like all lights are green
15:50:59 <morganfainberg> yeah
15:51:01 <ttx> Ready to pull trigger if you confirm.
15:51:10 <morganfainberg> checking now
15:51:26 <ttx> Do you need to do the same for stable/icehouse ?
15:51:53 <morganfainberg> ttx, confirmed on the juno branches
15:52:07 <morganfainberg> ttx, i am going to say probably yes.
15:52:16 <morganfainberg> we're likely to hit similar issues...
15:52:23 <ttx> let's check if the .Z is clean there
15:52:29 <morganfainberg> looking now
15:53:08 <morganfainberg> no middleware for icehouse
15:53:09 <ttx> python-keystoneclient capped to 0.11.2
15:53:23 <ttx> was there a 0.11.3... ?
15:53:43 <morganfainberg> and no 0.11.3
15:53:44 <ttx> you sir seem to be lucky
15:53:47 <morganfainberg> for keystoneclient
15:54:04 <morganfainberg> ttx, it was all planned! and i'm sticking to that story :P
15:54:19 <ttx> so for stable/icehouse... 	6d85d182a2cbd50f0e6a8477c97a84e149addbce (0.11.2)
15:54:40 <morganfainberg> yesyes
15:54:45 <ttx> Alright, let's do this
15:54:57 <morganfainberg> i'm sure other client libs are going to need this
15:55:07 <morganfainberg> but it might get ugly with tainted .Z
15:55:25 <ttx> keystonemiddleware stable/juno at 02abaa1d2711a3d5fc0dd020f05133618e5b7dde DONE
15:56:09 <ttx> python-keystoneclient stable/juno at  4ee6e3302ae53c8858c0e48c27a46c292e771afb DONE
15:56:42 <ttx> python-keystoneclient stable/icehouse  6d85d182a2cbd50f0e6a8477c97a84e149addbce  DONE
15:56:56 <ttx> All set, let's hope we just didn't break the world
15:57:00 <morganfainberg> ttx, thank you very much sir.
15:57:12 <morganfainberg> i'm going to go issue a nice recheck on some stuff
15:57:26 <morganfainberg> and i do agree.... no breakage *knock on wood*
15:57:32 <ttx> Please indicate that you intend to do another keystoneclient release on that ML thread -- you only mentioned keystonemiddleware
15:57:40 <morganfainberg> will do
15:57:48 <ttx> I'll use that thread as an external memory storage
15:57:57 <morganfainberg> just going to confirm KSC has something to release before responding
15:58:00 <morganfainberg> i am near certain it does
15:58:35 <ttx> OK, please check if anything needs backporting too
16:06:45 <morganfainberg> ttx, yep. will do
16:07:29 <morganfainberg> 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 <ttx> ok
16:12:21 <ttx> I'll be back in a couple hours to push ceilometer and neutron.
16:31:28 <mestery> ttx: back
18:35:36 <mestery> ttx: Neutron is ready to tag, all 4 Liberty opening patches have merged.
18:39:57 <ttx> mestery: ok, I'm on it
19:09:59 <ttx> mestery: done
19:10:05 <ttx> ceilometer is done too
19:10:11 <mestery> ttx: Woot!
19:10:23 * ttx checks if something else looks close
19:10:28 <ttx> before calling it a day
19:12:52 <ttx> ok, looks like we won't have another winner tonight
19:13:42 <ttx> back tomorrow
06:40:27 <ttx> mikal: FTR there is no pause. When https://review.openstack.org/#/c/171078/ is merged, Liberty starts
06:40:39 <ttx> I cut the release branch from the previous commit in history
06:42:04 <ttx> So if you're ready you should probably approve that
06:42:42 <ttx> (otherwise I'll check with zz_johnthetubagu when he is no longer zz)
07:08:54 <mikal> 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 <mikal> You'll need John to remove his -2 though
07:09:07 <ttx> Oh.
07:09:14 <ttx> Right.
07:09:32 <ttx> mikal: anything that sneaks in before that review will be in Kilo, I fear
07:09:50 <ttx> I'll make sure he approves it first thing when he gets up
07:10:34 <mikal> Yeah, two things have snuck in already, but they look harmless to me
07:10:45 <mikal> I thought I was meant to provide a SHA, but perhaps I am confused
07:11:22 <ttx> 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 <mikal> Ahhh, ok
07:11:34 <mikal> Fair enough then
07:11:43 <mikal> Regardless, I think I've done those thigns now
07:11:55 <ttx> Indeed
07:12:13 <ttx> I'll make magic happen from there
07:12:51 <mikal> Thanks
08:20:16 <johnthetubaguy> mikal: ttx: that change should be in the gate now
08:21:32 <ttx> yep, saw that, thx!
08:21:37 <johnthetubaguy> np
08:21:59 <johnthetubaguy> sorry we are using some pacific island time again!
09:14:28 <johnthetubaguy> ttx: just checking, now we are merged, I guess liberty is open?
09:14:36 <ttx> yes
09:14:52 <ttx> Triggering the big machine now to cut proposed/kilo
09:15:00 <johnthetubaguy> ttx: cool, I thoughts that how it worked, cool
09:15:03 <johnthetubaguy> ttx: cool
09:15:21 <johnthetubaguy> ttx: thanks for you help pushing on this, as always!
09:15:40 <ttx> cheers and congrats!
09:55:04 <ttx> nikhil_k: Looks like you're ready to go ?
11:01:14 <mikal> I guess we should send a "liberty is open for nova" email to -dev?
11:02:49 * mikal sends that email
11:29:37 <ttx> mikal: Sure. it's announced at the end of the rc1 email but a bit hidden
12:59:10 <sdague> ttx: so what's left for RCs?
12:59:25 <ttx> Glance Horizon Ironic and Swift
12:59:32 <sdague> ok
12:59:48 <ttx> I'll have to doublecheck if we need to wait on Swift, but I guess we do
12:59:55 <sdague> they have a time line? curious when we can cut over g-r
13:00:03 <ttx> Ironic Monday, Swift Tuesday
13:00:11 <ttx> Glance and Horizon hopefully today
13:00:17 <sdague> ok, sounds reasonable
13:00:44 <ttx> yes, it's not going too bad.
13:00:50 <ttx> Let me compare with previous cycle(s)
13:02:58 <ttx> For Juno last RC1s were done by Oct 6 (swift) Oct 3 (others) for an Oct 16 release
13:03:21 <ttx> For Icehouse last RC1s were done by Apr 4 (swift) and Apr 2 (others) for a Apr 17 release
13:03:36 <ttx> So we are 10 days earlier.
13:03:48 <sdague> cool
13:03:55 <ttx> err well
13:04:30 <ttx> By Tuesday we'll be D-16 while at Juno we were D-10 and for Icehouse D-13
13:04:46 <ttx> so 3-6 days earlier, rather
13:06:20 <ttx> yes and for Juno we waited until after Swift to unfreeze requirements.
13:07:00 <sdague> so, is there a reason for that? because swift doesn't do the requirements sync like other projects anyway
13:07:15 <ttx> which is why I was looking into it
13:07:52 <ttx> It might have just been laziness
13:08:45 <ttx> sdague: They could hold on requirements syncs for a few days. They don't really do them anyway
13:09:56 <ttx> But then if they hit Tuesday it's a bit of a non-issue
13:19:15 <sdague> agree
14:08:28 <ttx> david-lyle: ping me when around
14:08:35 <ttx> nikhil_k: ping me when around
14:18:33 <nikhil_k> ttx: hi
14:20:12 <ttx> nikhil_k: glance looks ready from where I stand... Anything you're waiting for ?
14:20:50 <nikhil_k> double checking
14:21:59 <nikhil_k> ttx: looks good
14:22:11 <ttx> nikhil_k: ok, feel free to approve that open-liberty patch then
14:22:18 <nikhil_k> ttx: will you be sending a bulk email to ML with RCs?
14:22:22 <ttx> https://review.openstack.org/#/q/branch:master+topic:open-liberty,n,z
14:22:31 <nikhil_k> ttx: Just want to wait a few days to see how RC1 is
14:22:33 <ttx> yes, I'll take it from there, just approve the review :)
14:22:36 <nikhil_k> then consider RC2
14:22:55 <nikhil_k> ttx: so we can open Liberty even if we want RC2?
14:23:18 <ttx> yes
14:23:24 <ttx> let me explain
14:23:30 <ttx> You push the libert version bump on master
14:23:31 <nikhil_k> ttx: ok, please do..
14:23:48 <ttx> then I cut a kilo release branch from the commit just before this one
14:24:00 <ttx> And I tag that same commit as RC1
14:24:18 <ttx> Then if you need an RC2 you push the bugfix to master, backport it for proposed/kilo
14:24:25 <ttx> and we tag proposed/kilo again as RC2
14:24:26 <ttx> etc
14:24:34 <nikhil_k> perfect
14:24:36 <nikhil_k> makes sense
14:24:47 <nikhil_k> and about communication for this?
14:25:12 <nikhil_k> Would you email cover the RC1 part and I can try to explain this to people in a meeting?
14:25:13 <ttx> I mention liberty being open in the RC1 announcement
14:25:20 <ttx> Doc is at https://wiki.openstack.org/wiki/Release_Cycle
14:25:21 <nikhil_k> Cool
14:25:34 <ttx> or https://wiki.openstack.org/wiki/Branch_Model
14:25:40 <nikhil_k> people have questions even with the doc :|
14:26:43 <nikhil_k> Thanks for the links
14:27:15 <nikhil_k> ttx: approving the review now
14:28:30 <nikhil_k> ttx: done. https://review.openstack.org/#/c/171227/
14:28:40 <ttx> cool, will branch and tga ocne that's in
14:28:44 <ttx> tag once*
14:30:57 <nikhil_k> thanks
14:33:56 <david-lyle> ttx: here
14:34:15 <ttx> david-lyle: should we wait anymore ?
14:34:37 <david-lyle> The only reason to wait is django-openstack-auth version
14:34:58 <david-lyle> I have https://review.openstack.org/#/c/172123/1 posted
14:35:21 <david-lyle> but not entirely sure that's sufficient to remove the py26 job from the gate for d-o-a
14:35:42 <ttx> let's ask on #-infra
14:36:12 <david-lyle> ok, I did yesterday, but I think it got lost in the other things happening
14:36:21 <ttx> sdague: so it looks like we have incoming: python-cinderclient django_openstack_auth python-barbicanclient python-ironicclient
14:36:45 <sdague> so.... why?
14:37:22 <sdague> we've done *all* our validation against the older versions for the servers
14:37:51 <ttx> let's see...
14:38:14 <ttx> thingee says "we do have some good fixes" but could skip it
14:38:25 <sdague> I feel like any client releases need a High priority bug
14:38:34 <ttx> for django_openstack_auth I'll let david-lyle explain
14:39:13 <david-lyle> it's requirements mismatch
14:39:17 <ttx> 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 <sdague> but, that barbicanclient statement is nonsense
14:40:04 <ttx> 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 <sdague> there are no consumers of those features as a library in the kilo release
14:40:12 <david-lyle> 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 <sdague> david-lyle: ok, that's a legit bug
14:40:53 <sdague> and I'd say that's valid to get this out
14:42:15 <ttx> david-lyle: you need the py26 disable in first right
14:42:51 <david-lyle> yes, https://review.openstack.org/#/c/172123/1
14:43:06 <david-lyle> have I mentioned how much I'd like to run away from Django recently
14:43:19 <sdague> david-lyle: ok, +A on the project-config change
14:43:31 <ttx> we can probably resist the cinder one, since thingee wasn't originally planning to push for it
14:44:08 <sdague> yeh, honestly, these library releases are mostly totally gratuitous, and *unneeded* in any way by the kilo release
14:44:18 <ttx> 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 <sdague> I know there is nova code that uses it
14:44:51 <david-lyle> sdague: ok thanks, once that merges, I'll merge the requirements bump
14:44:52 <sdague> optionally
14:45:47 <ttx> 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 <sdague> 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 <ttx> except our testing until now was done with the previous version
14:46:16 <ttx> so the former is safer
14:46:23 <sdague> right
14:46:43 <sdague> which is why requirements goes into freeze at M3
14:47:02 <sdague> so that all our RC testing is basically on the same code
14:47:07 <ttx> The trick is in absolute they want the client version in kilo to expose the features in kilo
14:47:20 <sdague> that's irrelevant
14:47:23 <ttx> only for different meaning of "in kilo"
14:47:33 <ttx> right
14:47:44 <sdague> just release a new version on release day
14:47:47 <sdague> people can use it
14:47:53 <ttx> So the optimal solution is.. for tehm to release it between the cap and the release day
14:48:02 <sdague> yeh
14:48:11 <ttx> I think we could convince redrobot to do that
14:48:20 <sdague> it's the confused bit of CLI use and library us in kilo
14:48:31 <ttx> as always
14:48:54 <ttx> Let's see.. ironic
14:49:33 <ttx> tagged 0.5.0 4 days ago
14:49:50 <ttx> plans to do a 0.5.1
14:51:49 <ttx> Looks like it's time for a "no client library release please" thread
14:52:30 <ttx> to explain the difference between exposing features in CLI and screwing integrated release testing
14:53:57 <sdague> yeh
14:55:31 <ttx> sdague: are you pissed off enough to write it ? Or should I ?
14:56:19 <sdague> 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 <ttx> ok, will do
15:08:51 <ttx> sdague: could you quickcheck facts in https://etherpad.openstack.org/p/0VFegeLsl0 ?
15:09:51 <sdague> wfm
15:09:55 <ttx> thx again for helping me through this maze :)
15:18:58 <ttx> morganfainberg: oh, you wanted to do a keystonemiddleware / python-keystoneclient too. We should discuss that as well
15:19:23 <morganfainberg> Yes.
15:21:00 <morganfainberg> The ksm release should be (will check) a .Z relapse to sync global req. it can wait for cap if needed.
15:21:28 <morganfainberg> I've been holding any major changes back to be sure we didn't introduce weird behavior.
15:21:57 <morganfainberg> Client has some pending fixes but likely nothing that needs to land in kilo (but would be nice to have)
15:22:07 <morganfainberg> Again, not the end of the world if it misses.
15:23:04 <morganfainberg> So.. I can hold these and wait for cap and we g-r update middleware and call it a day.
15:23:17 <morganfainberg> Once cap/ branch is cut.
15:23:34 * morganfainberg is trying to stay out of sdague 's way.
15:24:54 <ttx> That's the safe attitude :)
15:32:21 <notmyname> ttx: what's the requirements sync you're waiting on swift for? what you and sdague were talking about?
15:32:29 <notmyname> I thought the dependency freeze was march 19
15:35:12 <ttx> notmyname: once we cut stable/kilo requirements branch, we'll apply caps. That will trigger updates to proposed/kilo branches in various projects
15:35:28 <ttx> The question was whether we need to wait for Swift's RC1 to do that
15:35:44 <notmyname> ah, gotcha
15:35:48 <ttx> The perceived answer is that since you don't blindly apply requirements syncs from the bot, it doesn't matter that much
15:36:17 <ttx> and if you stick to Tuesday you might not be the last one anyway
15:37:00 <notmyname> ok
15:40:27 <ttx> ok, tagging glance now
15:41:31 <ttx> david-lyle: I think we'll have to wait until Monday for yours, so that you straighten everything today. If all is green feel free to approve the open-liberty review. i'll pick it up first thing Monday morning
15:42:09 <david-lyle> ttx: sounds good, couple things have merged to get d-o-a moving, couple more needed
15:42:30 <david-lyle> will continue to make progress and hopefully all is ready before monday
15:42:35 <ttx> awesome
09:36:06 <mikal> ttx: what's the right way to target https://bugs.launchpad.net/nova/+bug/1442656 against a nova rc2?
09:36:09 <openstack> Launchpad bug 1442656 in OpenStack Compute (nova) "live migration fails, because incorrect arguments order passed to method" [Critical,Fix committed] - Assigned to Timofey Durakov (tdurakov)
09:39:50 <ttx> mikal: until we formally open a RC2 (and basically tell all testers to hold testing until we issue it), the best is to use the kilo-rc-potential tag
09:40:02 <mikal> Yep, its already got that
09:40:10 <mikal> And I put a comment in the bug noting that it sounded like a thing to me
09:40:19 <ttx> Then we'll pick it up (especially if it's marked critical) when we consider opening
09:40:30 <mikal> Ok, cool
09:40:44 <mikal> Also, thanks for putting that Chris thing on the tc agenda
09:40:47 <mikal> I appreciate it
09:40:59 <ttx> I'd say any critical bug in the rc-potential list should result in a RC respin
09:41:21 <ttx> mikal: I'd have done it on my side but I guess I should still ask "upstream" permission
09:41:22 <mikal> That sounds logical to me
09:41:46 <mikal> ttx: I think its a good idea to talk it through with the TC because it sets a precident for the future
09:42:09 <ttx> right
09:43:00 <ttx> The messaging changes too. If it's just me, it's "I would like to dedicate", whereas if it's the TC, we can say "OpenStack contributors would like"
09:43:35 <ttx> or at least "Technical Committee would like"
09:44:03 <mikal> True
09:44:29 <mikal> A few of us have independently come up with that idea though, so I don't expect it to meet resistance
09:48:54 <johnthetubaguy> mikal: ttx: I think there were a few bugs merged we might want in RC2, there is a vmware one too, it should be tagged with kilo-rc-potential
09:49:19 <mikal> johnthetubaguy: that's the gary one, right?
09:49:32 <johnthetubaguy> mikal: yeah, https://bugs.launchpad.net/nova/+bug/1440968
09:49:34 <openstack> Launchpad bug 1440968 in OpenStack Compute (nova) "AttributeError: 'module' object has no attribute 'DatastorePath'" [High,Fix committed] - Assigned to Sabari Murugesan (smurugesan)
09:50:09 <johnthetubaguy> mikal: there is this one too: https://bugs.launchpad.net/nova/+bug/1442602
09:50:10 <openstack> Launchpad bug 1442602 in OpenStack Compute (nova) "live migration fails during destination host check" [High,Fix committed] - Assigned to Dan Smith (danms)
09:50:50 <mikal> Yep, they're all tagged, so I guess we wait for the release team to open a rc2
09:50:56 <johnthetubaguy> right
09:51:25 <johnthetubaguy> agreed, just to let you know, we have a good few to go in there
09:51:47 <mikal> Yep
10:06:23 <ttx> johnthetubaguy: fwiw the RC2 also needs to include the latest requirements sync, and that one won't appear until all projects have done their RC1
10:06:33 <ttx> So we probably won't tag the RC2 before Thursday
10:06:42 <ttx> Doesn't mean we can't open the backport window tomorrow
10:07:06 <johnthetubaguy> ttx: ah, thanks, thats a good heads up, hadn't thought of the requirements stuff
10:07:28 <ttx> johnthetubaguy: due to the fuckup with libs we have late adjustements there
10:07:46 <ttx> That and the translations stuff which always happen at RC2 too
10:08:14 <ttx> Anyway, all RC1s should be completed by Tuesday evening
10:08:24 <ttx> fingers crossed
10:08:30 <johnthetubaguy> cool
14:46:48 <ttx> david-lyle: ping me when around
14:46:54 <ttx> devananda: ping me when around
14:47:10 <ttx> notmyname: still on track for RC1 tagging tomorrow ?
14:48:02 <devananda> ttx: g'morning - just making my first cup of coffee
14:48:49 <ttx> alright, ping me when you have ideas clear. Would like to cut your RC1s soonish
14:50:43 <notmyname> ttx: the goal for today (pacific time) is to get things sorted and ready to go. the goal for tomorrow (again, pacific time tomorrow) is to do the merge and land the last few patches to master. we've got several queued up waiting for ec to land
14:50:55 <notmyname> ttx: I will send you an email as soon as I have the SHA
14:51:03 <ttx> notmyname: sounds good
14:51:14 <notmyname> today will be a busy day :-)
15:21:47 <david-lyle> ttx: o/
15:21:54 <ttx> david-lyle: hi!
15:22:13 <ttx> david-lyle: did you manage to entangle the mess ? Any help / review needed there ?
15:22:46 <david-lyle> one last patch to go into d-o-a, a test was added that is not Django 1.7 compatible
15:23:10 <david-lyle> I've never worked with a project that breaks compatibility so often
15:23:30 <david-lyle> just anywhere and everywhere
15:23:43 <david-lyle> we'll merge that and release
15:23:51 <david-lyle> then put up the requirements patch
15:24:09 <david-lyle> waiting for the dev with the patch to come on line
15:24:24 <ttx> then you tag d-o-a and then one last patch to horizon before tagging ?
15:24:24 <ttx> django? yeah
15:24:37 <david-lyle> yes
15:24:42 <david-lyle> and yeah django
15:24:48 <ttx> the requirements patch... you need to push it to openstack/requirements first right ?
15:24:50 <ttx> ok, ping me when you did that so that I can help there
15:24:53 <david-lyle> yes
15:25:03 <david-lyle> yes, thanks
15:25:22 <ttx> ideally we'd make enough progress on this so that we can have all the things approved and in the pipe today
15:25:33 <ttx> david-lyle: we could build a series of Depends-On patches
15:25:57 <david-lyle> that is my hope, if the dev doesn't come online soon, I'll just create the patch myself
15:25:59 <ttx> (once the tag on d-(o-a is in, since we can't depend on that
15:26:29 <ttx> but the last global-requirements -> requirements -> open-liberty chain can be coded up
15:26:53 <ttx> if it's all-approved today I can babysit it tomorrow morning and cut RC1
15:27:03 <david-lyle> that would be great
15:27:38 <ttx> so yeah, two steps. d-o-a and tag, then push the other three with depends-on set so that they merge in order
15:28:18 <david-lyle> ok, I will set them up that way
15:29:16 <ttx> devananda: how is that coffee going ?
15:29:41 <devananda> ttx: good. we just digressed into another debate about [micro]version behavior though...
15:30:05 <devananda> ttx: quick summary: one outstanding patch in each of diskimage-builder and python-ironicclient need to land
15:30:41 <devananda> ttx: and it looks like one, maybe two, patches needed in the server
15:30:53 <devananda> all are already proposed and getting a final round of reviews right now
15:32:22 <ttx> devananda: ok, so likely to all br ready later today ?
15:32:44 <ttx> devananda: feel free to amend the open-liberty commit so that it has the rights depends-on
15:33:06 <devananda> hope so
15:33:12 <ttx> or rebase it on top of the final commit you have
15:34:32 <ttx> OK, I'll be back in ~4 hours to get a new status. Feel free to paste review URLs we are depending on, that way I can pley recheck if needed
15:34:39 <ttx> play*
20:18:48 <devananda> ttx: looks like our last server-side patch has landed
20:19:39 <devananda> ttx: i'd like to chat about a client fix that just landed and how/when we should tag stable/kilo of the client, release 0.5.1 on that, and then go to 0.6.0
20:19:44 <devananda> i'm still fuzzy onthat process
20:31:53 <devananda> getting lunch, will keep an eye out for pings here though I may not respond right away
21:40:45 <ttx> devananda: we can discuss that at the 1:1 tomorrow
21:41:07 <devananda> sure
21:42:02 <devananda> ttx: so, with those landed, I believe I'm all set to tag RC today
21:42:43 <ttx> devananda: you don't need to tag, just need to get that open-liberty patch in and I'll cut the branch and the tag frfom the previous commit tomorrow morning
21:42:57 <devananda> right, that's what I meant :)
21:43:18 <ttx> so, yes, +2 away !
21:43:57 * ttx is going to bed
08:01:16 * ttx grabs coffee
08:06:01 <ttx> stevebaker: you attend on behalf of asalkeld right ?
08:12:33 <ttx> johnthetubaguy: o/
08:13:35 <johnthetubaguy> ttx: good morning
08:13:55 <ttx> let me start logging
08:14:02 <openstack> ttx: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
08:14:06 <ttx> err
08:14:09 <ttx> #endmeeting