09:02:18 <ttx> #startmeeting ptl_sync
09:02:19 <openstack> Meeting started Tue Mar 24 09:02:18 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:02:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:02:22 <ttx> #topic Heat
09:02:23 <openstack> The meeting name has been set to 'ptl_sync'
09:02:32 <ttx> #link https://launchpad.net/heat/+milestone/kilo-rc1
09:03:08 <ttx> OK, so objective for today is to make sure all things here are blockers before we can do a RC1
09:03:08 * asalkeld updating a bp state
09:03:19 <ttx> Let's start with blueprints first
09:03:33 <asalkeld> ok
09:03:33 <ttx> So you have two exceptions left
09:03:50 <ttx> Did you have anything requested on-list left unadressed ?
09:04:05 <ttx> or is it the complete set here ?
09:04:14 <asalkeld> that's it
09:04:29 <ttx> https://blueprints.launchpad.net/heat/+spec/convergence-push-data
09:04:39 <asalkeld> that is very close
09:04:43 <asalkeld> and one patch
09:04:45 <ttx> https://review.openstack.org/#/c/161306/ ?
09:04:58 <asalkeld> yip that's it
09:05:00 <ttx> Cool, so that one whould be done by end of week
09:05:10 <asalkeld> totally'
09:05:22 <asalkeld> the mistral one is more work, but it's in contrib/
09:05:26 <ttx> #info convergence-push-data one patch away, to be completed before EOW
09:05:39 <ttx> We still need it for RC1 though
09:05:53 <asalkeld> so if it makes it great, and if not - I am not overly stressed
09:06:09 <ttx> #info mistral-resources-for-heat is contrib/, not really blocking RC1
09:06:19 <asalkeld> agree
09:06:52 <ttx> Bugs now... Is this list the result of deferring previously-targeted work, or an analysis of all current issues reported ?
09:07:09 <ttx> i.e. did you go through all bugs and target those ?
09:07:14 <asalkeld> ttx: what i did was go through ALL High bugs
09:07:34 <asalkeld> and either target for rc1, or move to lower priority
09:07:43 <ttx> ok
09:07:48 <asalkeld> so those could change
09:08:09 <asalkeld> but i thought it was good to highlight high priortiy bugs
09:08:12 <ttx> You need to have assignees on all of them, otherwise it's unlikely they will get done for RC1 in any reasonable timeframe
09:08:23 <asalkeld> ok, i'll chase that
09:08:40 <ttx> #info 26 bugs targeted
09:08:42 <asalkeld> i should probably ditch some
09:08:58 <ttx> yeah, it's a bit of a large list ,for a blockers list
09:09:08 <asalkeld> ok, i'll get stuck in
09:09:18 <ttx> You can use kilo-rc-potential as a tag to build an extra list of nice-to-have
09:09:31 <ttx> and keep rc1 targeting as a blockers list
09:09:39 <asalkeld> ok, good idea
09:09:58 <ttx> That way we use the RC1 page as a timer... when all is completed we know we could do a RC1
09:10:09 <ttx> but then people can pick and fix bugs from the rc-potential list too
09:10:18 <asalkeld> aaa, like a backlog
09:10:39 <asalkeld> will do
09:10:45 <ttx> it's more of a "must-fix" vs. "should fix" thing
09:10:57 <asalkeld> ok
09:11:04 <ttx> If you deplete the must-fix list too quickly, we can add more "should-fix" to it, too :)
09:11:21 <asalkeld> lets hope we get to hat
09:11:23 <asalkeld> that
09:11:41 <ttx> asalkeld: the game is usually more like... every week you remove half of the remaining ones from the blockers list
09:12:04 <ttx> but ideally that would be must-fix and should-fix
09:12:07 <asalkeld> either re-target or fix
09:12:22 <asalkeld> thanks ttx
09:12:38 <ttx> so yes, on the bugs side, please assign people, reduce it to real release blockers, and build a backlog list using the tag
09:12:55 <ttx> We'll see how that number progresses next week and how fast we burn them down
09:13:10 <ttx> asalkeld: have a nice day!
09:13:15 <ttx> (or night)
09:13:17 <asalkeld> you too ttx
09:13:22 <ttx> johnthetubaguy: hi!
09:13:36 <johnthetubaguy> ttx: good morning
09:13:40 <ttx> #topic Nova
09:13:46 <ttx> #link https://launchpad.net/nova/+milestone/kilo-rc1
09:14:24 <ttx> I'm admirative of that small list of BPs, but I suspect that's not including all the requests you had on the list
09:14:43 <ttx> Is there any we should discuss the addition of ? Or you turned them all down already ?
09:14:54 * ttx admits not having parsed the FFE requests from the ML yet
09:15:06 <johnthetubaguy> hey, sorry, lots my IRC connection there
09:15:29 <ttx> what's the last thing you had ?
09:15:59 <johnthetubaguy> I saw small list of BPs
09:16:03 <johnthetubaguy> and is there any others
09:16:09 <johnthetubaguy> then you mentioned the ML
09:16:17 <ttx> johnthetubaguy: my question was, is that list the complete list of FFEs or should we discuss any addition ?
09:16:54 <ttx> Can't find any on the ML actually, so I guess the "soft FF at k-2" worked
09:16:57 <johnthetubaguy> so I don't know of any others, we are basically not advertising that its possible to get an exception very well
09:17:17 <johnthetubaguy> yeah, it has slowed things down at least
09:17:24 <johnthetubaguy> I think the list is good for now, basically
09:17:30 <ttx> https://blueprints.launchpad.net/nova/+spec/online-schema-changes
09:17:56 <ttx> pending on https://review.openstack.org/#/c/154521/ ?
09:18:07 <johnthetubaguy> yes, thats the only patch for the BP basically
09:18:21 <johnthetubaguy> I need to talk to johannes about that one to check what his plans are
09:18:29 <ttx> Looks like reviewing has stalled on this one
09:18:35 <ttx> (lacking new patchset)
09:18:44 <johnthetubaguy> I know he is busy on other things, so I need to ask what could be moved
09:19:06 <ttx> also feels like something you wouldn't want to merge at the last minute
09:19:14 <johnthetubaguy> I will push on that, its something we all want merged if possible
09:19:34 <ttx> I'm fine with it, but it needs to land earlier rather than later
09:19:50 <ttx> needs testing
09:19:52 <johnthetubaguy> its a parallel execution path that will be experimental, but yes, needs to land, ASAP
09:19:59 <ttx> hmm
09:20:12 <ttx> if it's really parallel and experimental, I guess it's not /that/ urgent
09:20:25 <johnthetubaguy> yeah, its basically like an alternative way to do migrations
09:20:29 <ttx> I misinterpreted it
09:20:33 <johnthetubaguy> you can use it, or the old way, both work
09:20:44 <ttx> (but then, it's not the first time you tell me about it, I just keep on forgetting)
09:20:46 <johnthetubaguy> (and they lock each other out)
09:20:59 <johnthetubaguy> no worries, its low ish risk, anways
09:21:10 <johnthetubaguy> the other one is very different...
09:21:19 <ttx> https://blueprints.launchpad.net/nova/+spec/v3-api-policy
09:21:56 <ttx> Right, this one seems like a collection of poatches that are easier to land individually, but loads of them
09:22:04 <ttx> Also unclear if that can be "finished"
09:22:41 <johnthetubaguy> so… I think we might want to mark this complete, and stop the review on the other things today ish
09:22:55 <johnthetubaguy> mostly, as you say, not sure it will get finished
09:23:09 <ttx> At the very minimum we need to set a deadline
09:23:25 <ttx> Like : review and merge before Thursday, rest is deferred
09:23:45 <johnthetubaguy> I am good with that
09:24:04 <johnthetubaguy> I will try reach out and ask them to abandon the stuff thats not very close
09:24:06 <ttx> That gives the people working on it a last chance to scramble on reviews
09:24:32 <ttx> not sure how much it makes sense as partial work
09:24:57 <ttx> Looks like a cleanup
09:25:09 <johnthetubaguy> yeah, some is just cleanup
09:25:13 <ttx> enforce at API layer rather than DB
09:25:22 <johnthetubaguy> yeah, its moving checks
09:25:36 <johnthetubaguy> basically means the v3 policy will eventually all be easy to understand
09:25:58 <johnthetubaguy> but we are not there yet, even if we merge all the patches that are up
09:26:02 <ttx> ok, let's give tyhem two more days and then call the partial work complete
09:26:02 <johnthetubaguy> as I understand it, anyways
09:26:19 <ttx> That way we should be done with FFEs (except shit happens) at EOW
09:26:28 <ttx> which is pretty good compared to previous occurences
09:26:56 <johnthetubaguy> yeah, sounds good
09:26:59 <ttx> Then there is work to do on the RC bug list
09:27:15 <johnthetubaguy> ah, yes, I did ask folks to start looking for blockers
09:27:19 <ttx> Did you do a pass on the critical/high issues yet ? Or is the current list the result of deferrals ?
09:27:35 <johnthetubaguy> I honestly haven't dug into that yet
09:27:50 <ttx> For example, there is no point in keeping in the list work that was deferred successively since juno-2
09:27:57 <johnthetubaguy> agreed
09:28:14 <johnthetubaguy> except for the embarrassing one we want someone to fix, but we best find someone to fix it
09:28:24 <ttx> I'd rather have realistic blockers, and keep unlikely fixes in the kilo-rc-potential list
09:29:13 <ttx> embarassing one = https://bugs.launchpad.net/nova/+bug/1383465
09:29:14 <openstack> Launchpad bug 1383465 in OpenStack Compute (nova) "[pci-passthrough] nova-compute fails to start" [Critical,In progress] - Assigned to Yongli He (yongli-he)
09:29:14 <ttx> ?
09:29:23 <johnthetubaguy> yes, thats the one
09:29:26 <ttx> I think we could unassign it
09:29:32 <ttx> that would reflect better the situation
09:29:34 <johnthetubaguy> yeah, thats a good idea
09:29:38 <ttx> I'll do it
09:30:09 <johnthetubaguy> ah, done it
09:30:26 <johnthetubaguy> the tag is kilo-rc-potential right?
09:30:42 <johnthetubaguy> so I guess everything targeted is a blocker, stuff with the tag could be a blocker
09:30:48 <ttx> OK, so objectives for this week -- finalize both FFE, build a list of must-fix in rc1 and good-to-fix in kilo-rc-potential
09:31:22 <johnthetubaguy> gotcha
09:31:25 <johnthetubaguy> sounds good
09:31:33 <ttx> that is alml, have a great week!
09:31:35 <ttx> all*
09:31:51 <johnthetubaguy> cool, thanks, and you
13:00:04 <eglynn> ttx: ready when you are
13:00:17 <ttx> #topic Ceilometer
13:00:31 <ttx> #link https://launchpad.net/ceilometer/+milestone/kilo-rc1
13:01:00 <ttx> So if I'm to trust that list you have no exception yet
13:01:17 <eglynn> yeap, so nothing critical as yet and obviously no FFEs
13:01:31 <ttx> good all around
13:01:43 <eglynn> what date-ish did you have in mind for the rc1 tag?
13:01:44 <ttx> Did you parse the bug list into a set of blockers ?
13:02:01 <ttx> or are those carried-over from k3 ?
13:02:10 <eglynn> mostly carry-overs
13:02:28 <ttx> So I'd say starting next week we can start tagging RC1s
13:02:44 <ttx> you need to go through the bug list to make sure there are no leftovers
13:02:57 <ttx> and then refine the list so that it's actually RC1 blockers there
13:03:12 <ttx> then when the list is empty we can tag RC1 and carry on with our liberty lives
13:03:13 <eglynn> sure, cool
13:03:26 <eglynn> so next week a bit earlier than envisaged by https://wiki.openstack.org/wiki/Kilo_Release_Schedule ?
13:03:44 <eglynn> or just getting ahead for the project that we can?
13:03:45 <ttx> The release schedule shows the likely dates
13:04:02 <eglynn> a-ha, k
13:04:04 <ttx> RC1 is tagged when all known issues are fixed :)
13:04:15 <ttx> all (significant) known issues
13:04:29 <ttx> so we just need to be reasonably sure it's good
13:04:37 <eglynn> cool, got it
13:04:41 <ttx> and parsing the bug list is the first step to gaining that confidence
13:05:02 <eglynn> cool, I'm on it :)
13:05:11 <ttx> so by next week, we'll reduce the RC1 buglist to real blockers, you can move oithers to kilo-rc-potential to keep them somewhere
13:05:28 <ttx> ("kilo-rc-potential" tag)
13:05:51 <ttx> that's a good "nice-to-fix" list
13:06:08 <eglynn> cool, got it
13:06:25 <ttx> That's all I had -- easy when no FFE :)
13:06:34 <eglynn> then post-RC1, only release-critical fixes, right?
13:06:51 <ttx> post-RC1, we need some critical issue to open a new RC window
13:06:59 <eglynn> (so slight incentive there not to rush into rc1 earlier?)
13:07:07 <ttx> then we can pile up a reasonable amount of other fix backports
13:07:19 <ttx> eglynn: I wouldn't say that...
13:07:31 <ttx> You need some significant bug to fix to make it worth the pain
13:07:44 <ttx> but then you can collect bugs that are fixed in master and backport them easily
13:08:21 <eglynn> cool, got it
13:08:25 <ttx> so, yes, no rush obviously, but "minor" bugfixes can get it in future RCs alright
13:08:37 <ttx> especially if you're far from release date
13:09:10 <ttx> the trick is to have at least one RC you can fall back to and release on common release date
13:09:28 <eglynn> cool, makes sense
13:09:41 <ttx> alright, have a good week!
13:09:58 <ttx> SergeyLukjanov: ready when you are
13:10:40 <SergeyLukjanov> ttx, hi
13:10:43 <SergeyLukjanov> ttx, I'm here
13:10:44 <ttx> #topic Sahara
13:10:45 <eglynn> you too, thanks for your time!
13:10:50 <ttx> #link https://launchpad.net/sahara/+milestone/kilo-rc1
13:10:57 <ttx> I see 3 FFEs in your future
13:11:19 <ttx> Is that the complete list at this point ?
13:11:23 <SergeyLukjanov> ttx, correct, no new FFEs expected, current ones are pretty near to be done
13:11:32 <ttx> ok, let's have a look
13:11:38 <ttx> https://blueprints.launchpad.net/sahara/+spec/add-timeouts-for-polling
13:11:49 <ttx> one more patch ?
13:12:00 <SergeyLukjanov> 1 CR left
13:12:01 <SergeyLukjanov> yup
13:12:06 <ttx> #info add-timeouts-for-polling -- one more patch, to be completed before EOW
13:12:31 <ttx> https://blueprints.launchpad.net/sahara/+spec/default-templates
13:12:46 <ttx> 6 easy patches ?
13:13:14 <SergeyLukjanov> ttx, yeah, we're now ensuring that stuff done in the same way for all plugins
13:13:20 <ttx> #info default-templates -- 6 easy patches, probably complete by EOW
13:13:34 <ttx> https://blueprints.launchpad.net/sahara/+spec/edp-job-types-endpoint
13:14:11 <ttx> Is taht one or two more patches ?
13:14:14 <SergeyLukjanov> ttx, 1 important CR left (MapR)
13:14:36 <ttx> https://review.openstack.org/#/c/166494/ looks further away
13:14:42 <SergeyLukjanov> ttx, few more patches preferred but we'll accept them only if done before EOW
13:14:55 <SergeyLukjanov> ttx, it's preferred but optional
13:15:10 <ttx> #info edp-job-types-endpoint -- one patch almost there, one optional patch, to be completed before EOW
13:15:22 <ttx> OK, looks under control
13:15:41 <SergeyLukjanov> ttx, yup, it's going as expected
13:15:52 <ttx> 20 bugs on the RC1 list, is that the result of a bug scrub, or just the carry-overs from previous milestones ?
13:16:02 <SergeyLukjanov> ttx, no topics from my side for today's cross project
13:16:11 <SergeyLukjanov> ttx, carry-overs
13:16:30 <ttx> Would be good to do a bug scrub and target the release blockers instead
13:16:42 <ttx> and move optional nice-to-haves to kilo-rc-potential tag
13:17:00 <ttx> So that by next week we know how far from RC1 we actually are
13:17:11 <SergeyLukjanov> ttx, ack, I'll ensure list cleaned up by EOW
13:17:24 <SergeyLukjanov> ttx, there a lot of docs related bugs in the list
13:17:24 <ttx> sounds good. Have a great week then
13:17:26 <SergeyLukjanov> and test
13:17:37 <SergeyLukjanov> ttx, thank you! you too
13:17:52 <ttx> cheers!
14:25:22 <ttx> mestery: I have a call at our usual time (last week before DST here), so if we can talk now, the better
14:25:44 <mestery> ttx: I'm running the neutron meeting now, lets see if I can multi-task. Go!
14:25:54 <ttx> #topic Neutron
14:26:09 <ttx> #link https://launchpad.net/neutron/+milestone/kilo-rc1
14:26:27 <ttx> So that is more FFEs that I'd like to have
14:26:38 <mestery> YEs, we're discussing them now
14:26:38 <mestery> the two IPAM ones I just moved out
14:26:40 <mestery> We're working our way down the list
14:26:47 <mestery> I guess meeting in an hour would have been better ;)
14:26:48 <ttx> ok, maybe I should talk to you later then :)
14:26:50 <mestery> as I'd have more info
14:26:56 <mestery> yeah, I guess that makes more sense
14:26:59 <mestery> Either later today or tomorrow?
14:27:01 <mestery> Your choise
14:27:18 <ttx> later today should be fine, will ping you
14:27:26 <ttx> #undo
14:27:27 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0x7135850>
14:27:30 <ttx> #undo
14:27:31 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x7135e50>
14:27:38 <mestery> Thanks ttx!
14:27:40 <ttx> oooh. Multiple undoi levels!
14:27:47 <mestery> lol
14:28:02 <ttx> wasn't sure that would work. Meetbot is already smarter than Word 95
14:28:38 <ttx> nikhil_k: interested in going now ?
14:28:48 <nikhil_k> ttx: yes
14:28:50 <nikhil_k> hi
14:28:52 <ttx> #topic Glance
14:29:03 <ttx> #link https://launchpad.net/glance/+milestone/kilo-rc1
14:29:22 <ttx> So I see two FFEs, is that the complete list you have ?
14:29:46 <nikhil_k> yes
14:30:17 <ttx> Your email mentioned pass-targets-to-policy-enforcer, that was moved out, right?
14:30:35 <nikhil_k> ttx: yes, that is implemented
14:30:48 <nikhil_k> https://blueprints.launchpad.net/glance/+spec/pass-targets-to-policy-enforcer
14:30:56 <ttx> oh, back in k3, nice
14:31:00 <ttx> Let's look at those remaining ones
14:31:06 <ttx> https://blueprints.launchpad.net/glance/+spec/artifact-repository
14:31:22 <ttx> Is that waiting on https://review.openstack.org/#/q/topic:bp/artifact-repository,n,z ?
14:31:27 <nikhil_k> yes
14:31:54 <ttx> How far is it ? Keeping such a large feature non-landed is concerning
14:32:23 <ttx> and I don't see a lot of progress lately
14:32:40 <nikhil_k> I'm trying to get people to review it and review myself
14:33:04 <nikhil_k> It's been discussed and talked over for months so, I think we will go with it for now
14:33:14 <nikhil_k> I can update you more on Thursday
14:33:15 <ttx> Right, I would prefer not to have the same discussion in one week
14:33:25 <nikhil_k> ok sure
14:33:30 <ttx> So let's give it one more week. If it can't land then, it never will
14:33:47 <nikhil_k> ok, thanks for letting me know
14:34:00 <ttx> #info artifact-repository a bit lagging, must land before next Tuesday or we'll defer
14:34:14 <ttx> https://blueprints.launchpad.net/glance/+spec/catalog-index-service
14:34:41 <ttx> That one also seems to be lagging -- feature is slightly less critical, but still
14:35:13 <ttx> I'm inclined to give it the same rule
14:35:23 <ttx> to be merged befor
14:35:28 <ttx> e next Tuesday
14:35:32 <nikhil_k> (sure)
14:36:08 <ttx> #info catalog-index-service a bit lagging too, must land before next Tuesday or we'll defer
14:36:32 <ttx> Once that is covered we need to build the RC1 buglist
14:36:49 <nikhil_k> sounds good
14:36:54 <ttx> i.e. you should parse bug lists and see what should be blocking release and RC1
14:37:14 <ttx> all the nice-to-haves could be tracked using kilo-rc-potential instead
14:37:15 <nikhil_k> roger
14:37:20 <ttx> so that we only have blockers in the RC1 list
14:37:34 <ttx> so ideally we'd have that list at our sync next week
14:37:48 <ttx> but you may be distracted by those FFEs in the mean time
14:37:55 <ttx> (one of the reasons those are harmful)
14:38:02 <ttx> do what you can :)
14:38:12 <nikhil_k> heh, thanks
14:38:31 <ttx> nikhil_k: have a good and busy week :)
14:38:44 <nikhil_k> ttx: :)
14:38:53 <nikhil_k> ttx: have a nice one yourself!
14:38:59 <ttx> david-lyle: interested in talking now ?
14:39:20 <ttx> or we can do our usual time, my call should be over by then
14:49:23 <david-lyle> ttx: ready, if now works
14:50:02 <ttx> david-lyle: o/
14:50:06 <ttx> #topic Horizon
14:50:20 <ttx> https://launchpad.net/horizon/+milestone/kilo-rc1
14:50:35 <ttx> I see 3 FFEs, any more on the (heh) horizon ?
14:50:57 <david-lyle> 1 possible for SSO with Keystone, fairly small change
14:51:21 <david-lyle> would be great to have but needs a little more work
14:52:01 <ttx> link?
14:52:08 <david-lyle> I can add it, and remove if we can't get it in shape
14:52:10 <david-lyle> finding
14:52:18 <ttx> yes, add it and we'll review it now
14:52:48 <david-lyle> https://blueprints.launchpad.net/horizon/+spec/federated-identity
14:53:00 <david-lyle> added in
14:53:11 <david-lyle> keystone folks will be happy
14:53:13 <ttx> how far is this one ?
14:53:29 <david-lyle> patches are up, horizon side needs a couple of fixes
14:53:30 <ttx> is that only those two patches ?
14:53:45 <david-lyle> django_openstack_auth pieces needs another round too
14:53:47 <david-lyle> yes
14:53:52 <ttx> I'm fine with cutting some slack to horizon since you need to play catch-up with features all the time
14:54:17 <david-lyle> ok, I'll work with keystone to get them finalized
14:54:26 <ttx> Is that something you think could land before our next sync ?
14:54:36 <david-lyle> I would hope so
14:54:43 <david-lyle> especially the horizon side
14:54:55 <ttx> #info federated-identity -- late feature catch-up, ideally would merge before Tuesday next week
14:54:59 <david-lyle> just very small issues on that piece
14:55:05 <ttx> https://blueprints.launchpad.net/horizon/+spec/django18
14:55:21 <david-lyle> that is a testing in the gate issue
14:55:25 <david-lyle> the patch is in Horizon
14:55:43 <david-lyle> so at worst, global requirements doesn't include Django > 1.6
14:55:52 <david-lyle> and people use it anyway
14:56:03 <ttx> so we could consider this one complete, just badly tested until we get our s*t together ?
14:56:23 <david-lyle> well it's misleading because we can't update global-requirements
14:56:26 <david-lyle> but yeah
14:56:27 <ttx> I'm inclined to consider it implemented and log a RC1 bug about testing
14:56:33 <david-lyle> it could be a line in the release notes
14:56:46 <ttx> which we could turn into a release note if we can't fix it, yes
14:56:53 <ttx> let's do that
14:57:08 <david-lyle> ok, I'll update and add bug
14:57:17 <ttx> https://blueprints.launchpad.net/horizon/+spec/angularize-identity-tables
14:57:39 <ttx> hmm, a bit unclear what that hinges on
14:57:48 <david-lyle> that still has a little more work on getting the patch in order
14:57:58 <ttx> lots of patches marked WIP in https://review.openstack.org/#/q/topic:bp/angularize-identity-tables,n,z
14:58:22 <ttx> I'm inclined to give it one more week, do you think that's doable in that timeframe ?
14:58:59 <david-lyle> I think so
14:59:27 <david-lyle> Really only one patch, the others are small utilities and I just -2'd one that was attached incorrectly
15:00:08 <ttx> #info angularize-identity-tables -- needs to be finalized before next week
15:00:17 <ttx> https://blueprints.launchpad.net/horizon/+spec/fwaas-router-insertion
15:00:20 <david-lyle> the WIP should be removed from the commit messate
15:00:38 <david-lyle> late feature in neutron
15:00:53 <ttx> ack, let's put it in the same bucket as the first one
15:00:53 <david-lyle> amotoki is reviewing and I will as well
15:00:59 <david-lyle> sure
15:01:06 <ttx> #info fwaas-router-insertion -- late feature catch-up, ideally would merge before Tuesday next week
15:01:25 <ttx> quick look at the buglist
15:01:36 <ttx> I think most of those are carry-overs
15:01:49 <ttx> would be good to refine it to a manageable list of blockers
15:02:04 <ttx> even if that means tagging kilo-rc-potential all the nice-to-haves
15:02:11 <david-lyle> yes, none of those are blockers at this point
15:02:21 <david-lyle> I'll clean up the list
15:02:29 <ttx> ack
15:02:36 <ttx> david-lyle: thanks! need to run
15:02:47 <david-lyle> thanks
15:40:15 <ttx> thingee: o/
15:40:29 <ttx> Got time to sync now?
15:41:18 <thingee> ttx: yes sorry. I joined the room and didn't notice weechat was lagging. Got dropped from the wifi :(
15:41:33 <ttx> no pb, was on a call anyway :)
15:41:37 <ttx> #topic Cinder
15:41:49 <ttx> https://launchpad.net/cinder/+milestone/kilo-rc1
15:41:57 <ttx> That's an easy one, no FFE so far
15:42:16 <ttx> apart from the driver unremovals, did you have any FFE request ?
15:42:17 <thingee> ttx: not much targeted yet. Started triaging yesterday to make sure nothing big is missing
15:42:26 <thingee> nope
15:42:48 <ttx> sounds all good to me
15:56:02 <ttx> mestery: I'm around now if you are
15:56:12 <mestery> ttx: Ack, lets get this party started! :)
15:56:17 <ttx> #topic Neutron
15:56:26 <ttx> #link https://launchpad.net/neutron/+milestone/kilo-rc1
15:56:34 <ttx> so... 7
15:56:40 <mestery> Down to 9 specs, 2 of which are vendor drivers
15:56:41 <mestery> Yes
15:56:42 <ttx> That's more reasonable, but let's see them in detail :)
15:56:43 <mestery> effectively 7
15:56:48 <mestery> OK, lets go!
15:56:54 <ttx> https://blueprints.launchpad.net/neutron/+spec/subnet-allocation
15:57:08 <mestery> That one we all agreed we need and can merge.
15:57:14 <mestery> So we have two main core reviewers on it, I expect it to land by next week or so.
15:57:42 <ttx> Lots of work needed still
15:57:50 <ttx> OK, let's give it another week if it's a top prio
15:57:52 <mestery> Yup, but I have been informed it's all doable
15:57:54 <mestery> Cool
15:58:12 <ttx> #info subnet-allocation -- should land before next 1:1, reconsider if not
15:58:23 <ttx> https://blueprints.launchpad.net/neutron/+spec/hyper-v-ovs-agent
15:58:40 <mestery> That one needs to be split into smaller patches, and if that happens we're confident it can merge by later this week.
15:58:43 <mestery> It's all on the patch author now
15:58:59 <mestery> It's low risk because it moves some code around and adds new Hyper-V specific code.
15:59:07 <ttx> How about we drop it if that can't be merged in the coming week ?
15:59:12 <mestery> WFM
15:59:22 <ttx> with that many exceptions, I'm more worried with distraction than code impact tbh
15:59:32 <mestery> Agreed
15:59:45 <ttx> #info hyper-v-ovs-agent -- needs to fully land by next Tuesday
15:59:54 <ttx> https://blueprints.launchpad.net/neutron/+spec/restructure-l3-agent
16:00:11 <mestery> 3 patches left, we're confident we can finish this one by Friday as well
16:00:31 <mestery> Sorry, 4.
16:00:53 <ttx> #info restructure-l3-agent -- 4 patches left, finalization of a partially merged feature. should land before next 1:1, reconsider if not
16:01:08 <ttx> https://blueprints.launchpad.net/neutron/+spec/ipv6-router
16:01:29 <mestery> We're waiting on a tempest functional job for this one, and it depends on a patch from the multiple-prefix one.
16:01:40 <mestery> So this one is iffy, and again, if it doesn't land by Friday it should be out.
16:02:03 <ttx> #info ipv6-router -- needs to fully land by next Tuesday
16:02:18 <ttx> https://blueprints.launchpad.net/neutron/+spec/multiple-ipv6-prefixes
16:02:29 <ttx> same bag?
16:02:38 <mestery> Yup
16:02:52 <ttx> #info multiple-ipv6-prefixes -- related to previous one, needs to fully land by next Tuesday
16:03:04 <ttx> https://blueprints.launchpad.net/neutron/+spec/netscaler-lbass-v2-driver
16:03:24 <mestery> That one needs a working CI, which it doesn't have.
16:03:27 <ttx> how much time did you gave them
16:03:29 <ttx> ?
16:03:31 <mestery> We've given it and the radware one until Friday to merge.
16:03:54 <ttx> #info netscaler-lbass-v2-driver -- needs CI up, must merge before EOW
16:04:03 <ttx> https://blueprints.launchpad.net/neutron/+spec/radware-lbaas-driver
16:04:05 <ttx> same I suspect
16:04:17 <ttx> #info radware-lbaas-driver --  needs CI up, must merge before EOW
16:04:19 <mestery> Yup
16:04:21 <mestery> same
16:04:53 <ttx> OK, if we stick to those deadlines we should be good. My only gripe is that none of them actually looks like it's very close
16:05:17 <ttx> Means that it will be distracting, and despite the distraction we need to start focusing on bugs
16:05:18 <mestery> I hear you, but I've been firm on kicking things out that don't make the deadlines.
16:05:28 <mestery> I moved out pluggable IPAM to a room full of gripes today.
16:05:35 <ttx> In particular we'll need a list of RC1 blockers for next week
16:05:38 <mestery> Agreed
16:05:48 <mestery> We've started moving bugs out of RC which are not blockers.
16:05:50 <mestery> I have more work to do there.
16:05:54 <ttx> you can move the wishlist stuff to a kilo-rc-potential tag to keep track of them if you need to
16:06:13 <mestery> OK
16:06:16 <ttx> also a bug scrub on the general bug list is helpful to catch previously-overlooked issues
16:06:18 <mestery> those are plugin decomp tracking items
16:06:26 <mestery> Good idea
16:06:30 <ttx> just in case
16:06:53 <ttx> and then keep an eye on recently-filed bugs, as people start testing the thing we say is mostly there :)
16:07:05 <ttx> That is all I had
16:07:18 <mestery> Same for me.
16:07:22 <mestery> We're close ttx! :)
16:07:29 <mestery> Just need to get the proverbial ball over the goal line.
16:07:31 <mestery> ;)
16:07:32 <ttx> once you refine the bug list, make sure you have assignees for each blocker
16:07:38 <mestery> Ack
16:07:46 <ttx> otherwise they tend not to get a lot of attention :)
16:07:54 <ttx> alright then,n have a great and busy week :)
16:08:04 <ttx> you can relax when RC1 is done :)
16:08:36 <mestery> LOL
16:08:36 <mestery> Yeah, no kidding!
16:08:49 <mestery> And my son had tonsil surgery and ear tubes put in last week, so it's been nuts between that, the baby, and RC
16:08:54 * mestery needs to take a vacation
16:09:00 <ttx> mestery: I can only relax once the summit is done, so...
16:09:13 <mestery> ttx: :)
16:09:16 <mestery> thanks ttx!
16:09:18 <ttx> I entered "The Tunnel"
16:09:25 <mestery> lol
16:09:33 <ttx> there is light on the other side
16:09:42 <ttx> I can feel it
16:09:50 <mestery> Go towards the light!
16:13:58 <SlickNik> ttx: around?
16:14:03 <ttx> SlickNik: yes
16:14:09 <ttx> we can talk now
16:14:41 <SlickNik> Sounds good — forgot I needed to go to a doctor's appointment later, so this would be better. :)
16:14:46 <ttx> #topic Trove
16:15:01 <ttx> #link https://launchpad.net/trove/+milestone/kilo-rc1
16:15:15 <ttx> I see two FFEs left
16:15:18 <SlickNik> One of our FFE BPs is done
16:15:34 <ttx> I sthat the full set you've been asked for ?
16:15:51 <SlickNik> Yes, those two are all that's left and are pretty close.
16:15:54 <ttx> https://blueprints.launchpad.net/trove/+spec/db2-plugin-for-trove
16:16:10 <ttx> I think we need a deadline for that one, as it's a key feature
16:16:16 <SlickNik> I've moved the others to liberty since they will not make it.
16:16:22 <ttx> what would be reasonable ? Before next Tuesday ?
16:16:36 <SlickNik> The deadline I'm telling folks is end of this week.
16:16:42 <ttx> ok
16:16:56 <ttx> #info db2-plugin-for-trove -- must land before EOW
16:17:03 <ttx> https://blueprints.launchpad.net/trove/+spec/implement-vertica-cluster
16:17:22 <SlickNik> Same thing with this one.
16:17:24 <ttx> Looks about as far, same deadline ?
16:17:24 <ttx> ok
16:17:40 <ttx> #info implement-vertica-cluster -- must land before EOW
16:17:50 <SlickNik> Good progress made — and I think it's got a good shot of landing before the end of the week.
16:18:01 <ttx> Looking at the bug list now
16:18:18 <ttx> So ideally that list would be the list of release blockers we need to solve before we can tag a RC1
16:18:31 <ttx> nice-to-haves should move to using the kilo-rc-potential tag
16:18:37 <ttx> so that you can find them
16:18:50 <SlickNik> That list has some punts from kilo-3 but which are not release blockers
16:18:57 <SlickNik> Let me go through them and clean that list up.
16:19:03 <ttx> right, so you should refine it and make sure the remaining stuff are blockers
16:19:16 <ttx> not necessarily now, but before next week
16:19:41 <SlickNik> #action SlickNik to clean up RC1 bugs to make sure they are true release blockers
16:19:41 <ttx> Doing a quick pass on Lcunhpad bugs to make sure you didn't overlook a critical issue is generally a good idea too
16:19:46 <SlickNik> Sounds good.
16:20:02 <ttx> that is all I had. Questions ?
16:20:05 <SlickNik> Will do that as well.
16:20:30 <SlickNik> No more questions from me. Thanks for your help!
16:20:34 <ttx> np!
16:20:44 <ttx> devananda: ping me when around
16:51:17 <ttx> morganfainberg: ohai
16:51:42 <morganfainberg> \o
16:51:52 <ttx> #topic Keystone
16:51:59 <morganfainberg> Lots of FFE requests.
16:52:03 <ttx> #link https://launchpad.net/keystone/+milestone/kilo-rc1
16:52:12 <morganfainberg> Sec moving off phone to desktop.
16:52:14 <ttx> yeah, but only one on the page so far
16:52:16 <ttx> sure
16:52:30 <morganfainberg> ok
16:52:33 <ttx> so let's start with that one
16:52:37 <ttx> https://blueprints.launchpad.net/keystone/+spec/model-timestamps
16:52:56 * morganfainberg forgot to put the others on the rc-1 as blocked
16:52:56 <ttx> is it one you support, or just some random person targeting it ?
16:53:10 <morganfainberg> that one i support, there is no API impact (or shouldn't be)
16:53:11 <ttx> we'll add them as we go
16:53:32 <ttx> how close is that ?
16:53:45 <ttx> we can give it until end of week alright
16:53:46 <morganfainberg> it should be a minor refactor. needs a rebase and probably 1 patchset
16:54:02 <ttx> more worried about distraction than impact tbh
16:54:04 <morganfainberg> i'm planning on handling the minor update [filter extra data before it hits the API]
16:54:15 <morganfainberg> it's the lowest priority though
16:54:27 <morganfainberg> lets just punt it till liberty
16:54:32 <ttx> #info model-timestamps -- to be merged before next Tuesday
16:54:39 <morganfainberg> it can land right off the bat next cycle.
16:54:44 <ttx> oh yes
16:54:46 <ttx> #undo
16:54:47 <openstack> Removing item from minutes: <ircmeeting.items.Info object at 0x8b58350>
16:55:02 <ttx> leaves room for more interesting ones
16:55:10 <morganfainberg> yeah and we have a bunch :(
16:55:20 <ttx> yes, you look like Nova now
16:55:26 <ttx> so let's see...
16:55:51 <ttx> I see a thread about domain configuration SQL support, fetching spec
16:56:08 <ttx> Looks like https://blueprints.launchpad.net/keystone/+spec/domain-config-ext
16:56:10 <morganfainberg> the Domain SQL is a couple follow up patches that didn't land
16:56:12 <morganfainberg> yeah
16:56:19 <morganfainberg> rather than rush them we opted for FFE
16:56:30 <morganfainberg> it should be ~3 small-ish reviews
16:56:36 <ttx> sounds good, finishing the work
16:56:36 <morganfainberg> most are heavily reviewed already
16:56:42 <ttx> should not take more than a week, right
16:56:55 <morganfainberg> correct
16:57:04 <ttx> #info domain-config-ext -- to be fully merged before Tuesday next week
16:57:05 <morganfainberg> should be merged this week if the exception is granted
16:57:19 * ttx adds
16:57:49 <ttx> next up is idp-id-registration
16:58:01 <ttx> https://blueprints.launchpad.net/keystone/+spec/idp-id-registration
16:58:04 <morganfainberg> this is ready to go. it was blocked by a critical bug
16:58:12 <morganfainberg> it should easily merge today or tomorrow
16:58:17 <ttx> so should merge in the coming days ? ok
16:58:33 <ttx> #info idp-id-registration -- to be completed before EOW
16:58:59 <morganfainberg> and by my count we have 2 big ones next.
16:59:23 <ttx> next up is the reseller stuff
16:59:32 <ttx> is that https://blueprints.launchpad.net/keystone/+spec/reseller ?
16:59:35 <morganfainberg> yeah
16:59:46 <morganfainberg> i'd really like to see this land in kilo. i think it's a tall order
17:00:05 <ttx> For this one it depends more on the disruption it may create to existing code
17:00:20 <morganfainberg> so, the code in keystone will see a lot of disruption
17:00:23 <ttx> it feels like it has wrecking potential
17:00:28 <morganfainberg> the code for anyone else should be zero
17:00:52 <morganfainberg> it shuffles a lot of things. it was a big priority this cycle to get in, but like everything else got slammed into k3 timeline
17:00:58 <morganfainberg> which meant things didn't land
17:01:13 <ttx> how long do you think it can take ?
17:01:23 <morganfainberg> it could land next week EOW
17:01:28 <morganfainberg> if everyone core jumped on it
17:01:30 <ttx> I'm worried we might introduce regressions we don't have time to spot
17:01:40 <morganfainberg> i think that is a concern
17:01:55 <ttx> let's table it for the time being and see the other one
17:02:12 <ttx> wrapped assertions?
17:02:20 <morganfainberg> hmm?
17:02:31 <morganfainberg> oh
17:02:32 <morganfainberg> yeah
17:02:33 <ttx> is the last one about wrapped assertions?
17:02:35 <morganfainberg> SAML
17:02:43 <morganfainberg> was thinking code assertion not SAML assertion
17:02:48 <ttx> trying to find the blueprint
17:03:15 <morganfainberg> it's not a BP
17:03:17 <morganfainberg> it's a bug
17:03:29 <morganfainberg> it should be converted to a BP: https://bugs.launchpad.net/keystone/+bug/1426128
17:03:30 <openstack> Launchpad bug 1426128 in Keystone "Add ECP related bits to saml generation code" [Wishlist,In progress] - Assigned to Rodrigo Duarte (rodrigodsousa)
17:03:42 <morganfainberg> this is small in scope, but impacts API
17:04:03 <ttx> I guess if it lands in the coming days harm is limited
17:04:07 <morganfainberg> yeah
17:04:12 <ttx> is it ready to land ?
17:04:12 <morganfainberg> and it's totally isolated
17:04:15 <morganfainberg> very close
17:04:19 <morganfainberg> i'd say tuesday for sure
17:04:30 <ttx> could you speed-create the BP for it ?
17:04:34 <morganfainberg> yeah
17:04:35 <morganfainberg> sec
17:04:39 <ttx> so that we end up with the clean list
17:05:20 <ttx> If you really want it, I'm inclined to give reseller a try, since everything else should be landed by next week
17:05:29 <morganfainberg> https://blueprints.launchpad.net/keystone/+spec/ecp-wrapped-saml-assertions
17:05:36 <ttx> it's the only one that has potential to really overflow
17:05:51 <ttx> ok, targeted to rc1
17:05:55 <morganfainberg> my biggest concern with reseller is that is it changing how domains are working
17:06:03 <morganfainberg> they become projects with a flag
17:06:13 <morganfainberg> the rest of reseller is fairly innocuous/isolated
17:06:15 <ttx> #info ecp-wrapped-saml-assertions -- need to land before next Tuesday
17:06:40 <ttx> morganfainberg: would it be a btter idea to land it early in liberty ? So that people can start play out with it if they want to ?
17:07:18 <morganfainberg> i think it's a wash if it lands now or then. we have a high demand for the features this cycle [lots of people asking for it], but the risk is higher
17:07:36 <ttx> I think you laredy landed more thanb your share of Kilo features tbh
17:07:44 <ttx> plenty of edge cases to test already
17:07:49 <morganfainberg> lets say liberty then.
17:07:51 <ttx> and the sooner we get to that the better
17:07:56 <morganfainberg> it'll disappoint some folks.
17:08:07 * morganfainberg knew this was going to be the result tbh.
17:08:40 <ttx> you can blame me. I'm very willing to cut Horizon some slack due to its position in the stack... Keystone, not so much
17:08:43 <morganfainberg> we also have a ton of bugs to triage through
17:08:58 <morganfainberg> uh. no. we share the blame here. i let everything wedge into k3
17:08:59 <morganfainberg> ;)
17:09:06 <ttx> If it were a couple days away that would not be the same discussion
17:09:15 <ttx> but we are talking end of next week here
17:09:19 <morganfainberg> next cycle i hope we make FF for keystone milestone-2
17:09:36 <morganfainberg> then we have a whole milestone for things to slip like this if needed
17:09:38 <morganfainberg> :P
17:09:44 <ttx> yeah, nova-style
17:09:48 <morganfainberg> exactly
17:09:53 <morganfainberg> esp. with where Keystone is in the stack
17:10:26 <morganfainberg> all of these (i think) are also string-freeze exceptions
17:10:36 <morganfainberg> do i need to send messages to the i18n list?
17:10:49 <morganfainberg> or is FFE sufficient for that
17:10:54 <ttx> at least one thread on the ML so that they are able to know, yes
17:11:01 <ttx> can be a single post for all
17:11:04 <morganfainberg> ack
17:11:14 * ttx tries to update BP status
17:11:30 <morganfainberg> i expect to be bug triaging and punting bugs off RC that aren't important this week as well
17:11:34 <ttx> I think I can set them all to Needs Review
17:11:41 <ttx> I'll let you unblock the patches
17:11:55 <ttx> yes, the next step is to refine the bug list so that it's actually blockers only
17:11:59 <morganfainberg> sounds good. i will make the ECP ones get commit updates
17:12:06 <ttx> and keep the nice-to-haves using the kilo-rc-potential tag
17:12:12 <morganfainberg> yep.
17:12:15 <ttx> so that we ahve a list to track starting next week
17:12:26 <morganfainberg> someone went a bit gung-ho and added every open bug to rc
17:12:29 <morganfainberg> i think.
17:12:30 <morganfainberg> :P
17:12:36 <morganfainberg> every recently opened bug that is
17:12:47 <ttx> let them use the tag instead :)
17:12:56 <morganfainberg> i will be asking them to do that.
17:13:01 <morganfainberg> cause *bugs*
17:13:03 <morganfainberg> ;)
17:13:12 <morganfainberg> anyway next week should have FFEs done and bug list sane
17:13:17 <ttx> also get someone assigned to that blueprint you just created
17:13:20 <ttx> that is all!
17:13:46 <morganfainberg> done
17:13:51 <morganfainberg> assigned to stevemar
17:14:13 <ttx> notmyname: sorry for the lateness
17:14:21 <ttx> morganfainberg: have a good day, talk to you later!
17:14:29 <notmyname> looks liek you had import stuff to discuss :-)
17:15:00 <ttx> not every day that keystone has more exception requests than Nova, Cinder and Neutron combined
17:15:08 <morganfainberg> haha
17:15:13 <ttx> #topic Swift
17:15:14 <notmyname> wow
17:15:34 <notmyname> so in swift-landia, we're hard at work on our final push to getting an erasure code beta for kilo
17:15:48 <ttx> how is that going ? Still on track ?
17:15:56 <notmyname> the patch chains being tracked are the starred patches on...
17:15:57 <notmyname> #link http://goo.gl/uRzLBX
17:16:01 <notmyname> our review dashboard
17:16:45 <notmyname> the plan is to finish up work on feature/ec this week and start the merge to master next week
17:17:38 <notmyname> there's a lot do to, so it's hard to say if it's "on track". but we'll definitely have a beta in kilo :-)
17:17:51 <ttx> some beta at least :)
17:18:06 <ttx> ok, so I expect we'll have more to discuss starting next week
17:18:17 <notmyname> about the merge process?
17:18:40 <ttx> yeah, and the RC1 timing
17:18:57 <notmyname> we're still shooting for april 10 as a guideline
17:18:58 <ttx> you have the merge process pretty much under control right
17:19:21 <notmyname> yes, I think that will be tedious, but not especially hard (the git logistics)
17:19:33 <notmyname> I'll need to work with -infra for the final merge
17:19:38 <ttx> I don't expect to be useful there, but if you need me for anything, let me know
17:19:43 <notmyname> ok, thanks
17:19:49 <ttx> anything else ?
17:19:55 <notmyname> during the merge process, we'll freeze master
17:20:03 <notmyname> to avoid conflicts causing delays
17:20:07 <ttx> #info still shooting for april 10 as a guideline for swift rc1
17:20:28 <notmyname> that's pretty much everything right now: all EC, all the time
17:20:55 <ttx> alright
17:20:59 <ttx> I'll let you go back to that
17:21:05 <notmyname> have a good evening
17:21:18 <ttx> nothing to discuss at cross-project meeting, so we'll skip it
17:21:23 <ttx> one more hour back
17:21:32 <notmyname> ok
17:21:49 <ttx> That concludes our syncs for today, thanks everyone
17:21:51 <ttx> #endmeeting