15:01:19 <n0ano> #startmeeting gantt
15:01:20 <openstack> Meeting started Tue Mar 10 15:01:19 2015 UTC and is due to finish in 60 minutes.  The chair is n0ano. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:23 <openstack> The meeting name has been set to 'gantt'
15:01:29 <n0ano> anyone here to talk about the scheduler?
15:01:46 <alex_xu> o/
15:01:48 <edleafe> o/
15:02:35 <ajo> bye :)
15:02:48 <PaulMurray> o/
15:03:37 <n0ano> let's get started then
15:03:45 <n0ano> #topic patch status
15:03:50 <lxsli> o/
15:03:57 <n0ano> taking things a little out of order while waiting for bauzas to join
15:04:31 <n0ano> rather than talking about the patches themselves I think the better use of our time is to talk about reviews...
15:04:50 <n0ano> specifically edleafe & PaulMurray do you have any patches that need reviews right now?
15:05:02 <PaulMurray> n0ano, you bet cha
15:05:10 <edleafe> me too
15:05:22 <PaulMurray> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/make-resource-tracker-use-objects,n,z
15:05:24 <n0ano> (it was kind of a rhetorical question), PaulMurray go ahead
15:05:32 <edleafe> I added them to the etherpad: https://etherpad.openstack.org/p/kilo-nova-priorities-tracking
15:05:44 <PaulMurray> There are a bunch by me that are passing ci
15:06:00 <PaulMurray> and a bunch by lxsli that need a rebase
15:06:11 <PaulMurray> please look and review :)
15:06:24 <bauzas> \o
15:06:28 <edleafe> PaulMurray: you should add them to the etherpad, too
15:06:28 * bauzas waves late
15:06:36 <PaulMurray> n0ano, ok
15:06:41 <PaulMurray> n0ano, I also need to add
15:06:43 <bauzas> sorry was diverted by a bug
15:06:48 <n0ano> bauzas, np
15:07:01 <PaulMurray> one more - is that allowed while no one is looking (I mean after FPF)
15:07:04 <edleafe> PaulMurray: oh, wait - I see them there already
15:07:31 <n0ano> PaulMurray, all but 1 of your patches on that page need a rebase, should we wait off on those?
15:07:43 <PaulMurray> really?
15:07:46 <edleafe> PaulMurray: if it's part of an existing patch, I believe it's ok
15:08:35 <PaulMurray> edleafe, I can spin it that way - otherwise I am sure it would be allowed as an exception
15:08:35 <n0ano> PaulMurray, I just refreshed the page and that's what it says
15:09:00 <PaulMurray> n0ano, I'm looking at them now, I have a chain of 4 that all look ok to me
15:09:02 <edleafe> PaulMurray: it all depends on *why* you are adding it
15:09:33 <edleafe> n0ano: the links on the etherpad don't match his series
15:09:44 <edleafe> PaulMurray: you need to update the etherpad to get them in sync
15:10:00 <n0ano> edleafe, ahh, that would explain it
15:10:22 <PaulMurray> edleafe, ah, I see - yes it does need updating, will do now
15:10:41 <n0ano> I think I need to create a dashboard on the wiki for patches similar to the one we have for specs, that'd be easier than the etherpad
15:10:51 * n0ano hates etherpads for tracking purposes
15:11:04 <PaulMurray> n0ano, is there some process I need to follow to add a patch - it is needed to complete
15:11:06 <bauzas> n0ano: why ?
15:11:08 <edleafe> n0ano: yeah, but that's where core reviewers are supposed to be looking
15:11:17 <PaulMurray> objects for RT - to allow online upgrade
15:11:18 <bauzas> n0ano: I mean, we already have the core etherpad
15:12:11 <n0ano> the etherpad is never obvious, all the important info is always randomly located throughout the page, I can never see the forest for the trees
15:12:42 <n0ano> anyway, rather than a new wiki table I guess we can just try and make sure the tracking etherpad is up to date
15:13:37 <edleafe> PaulMurray: is the patch part of an existing series?
15:13:44 <PaulMurray> edleafe, yes
15:13:45 <edleafe> PaulMurray: if so, just add it
15:14:01 <PaulMurray> edleafe, I was guessing no one would notice anyway
15:14:40 <edleafe> PaulMurray: it totally fits with the spirit of the FPF
15:14:55 <edleafe> focusing on what needs to merge for Kilo
15:15:09 <n0ano> so is the assumption that any patch on the traking page is ready for review unless there's something specific (like needs rebase) on it?
15:15:21 <edleafe> n0ano: yep
15:16:11 <n0ano> OK, then we know our marching orders, review all the open patches on that page
15:16:40 <n0ano> is there any specific patch that is problematic that needs discussion?
15:17:10 <edleafe> n0ano: I really need the early patches to merge
15:17:22 <edleafe> rebase hell is killing my productivity :)
15:17:45 <n0ano> edleafe, no good answer on that, I feel your pain
15:18:13 <bauzas> edleafe: eh
15:18:13 <PaulMurray> n0ano, this one seems to be blocking things: https://review.openstack.org/#/c/137817/
15:18:47 <PaulMurray> lxsli has this at the head of his series
15:19:56 <PaulMurray> it belongs to sahid - are you here sahid
15:20:39 <lxsli> ndipanov's comments are from just yesterday
15:20:42 <n0ano> looks like ndipanov has issues with it's current incarnation, sahid will have to address those concerns
15:20:49 <edleafe> PaulMurray: speaking of holding things up, do you have any issue with my fix for the PciDevTracker merging before your patch for the RT compute_node change?
15:20:52 <edleafe> PaulMurray: https://review.openstack.org/#/c/145619/
15:21:57 <PaulMurray> edleafe, i think its a trivial change for me to rebase - so i don't mind as long as
15:22:12 <PaulMurray> edleafe, I get some eyes on mine to help them through
15:22:26 <edleafe> PaulMurray: ok, great
15:22:52 <edleafe> Let's all make sure to review PaulMurray's patches so that cores can see consensus
15:23:07 <n0ano> edleafe, +1
15:23:41 <n0ano> if nothing else on specific patches let's move on
15:23:50 <n0ano> #topic specs on hold
15:24:01 <n0ano> bauzas, this is you, you indicated last week you have a plan?
15:24:24 <bauzas> n0ano: oh was thinking you were just mentioning the reqspec BP ?
15:25:14 <n0ano> bauzas, yeah, both request spec anc change select_destinations are on hold on the tracking page, what's up?
15:25:24 <bauzas> n0ano: just to be clear, there is no magic bullet about any plan - just saying that we need to work in parralel on working on the migration/split while we also work on the missing BPs
15:25:47 <bauzas> n0ano: and I wanted to wait for FF to happen before stating about what was missing
15:25:59 <bauzas> n0ano: about the resqpec BP, that's another point
15:26:21 <bauzas> n0ano: so I provided an implementation series, and I had good feedback
15:26:57 <bauzas> n0ano: my point was that it was far better to work on a separate RPC method instead of modifying the select_dest() signature
15:27:00 <n0ano> well, since the specs were approved does thins mean you need to change the design or is this just holding up on the implementation
15:27:26 <bauzas> n0ano: and also rework on the RequestSpec object, as some fields were either unnecessary/confusing
15:28:00 <edleafe> bauzas: despite jaypipes' objection, this really can't fit into Kilo
15:28:01 <bauzas> n0ano: I said it was far better to defer to Liberty and possibly ask for backport before FF if successful
15:28:10 <bauzas> edleafe: agreed
15:28:25 <bauzas> I mean, that's all about paperwork
15:28:34 <n0ano> so this sounds more like implementation so we just needs a little more time to get it right
15:28:40 <bauzas> a spec is just an approval step
15:29:06 * n0ano freezes can be a pain even if they are a great motivator
15:29:06 <bauzas> so my point is to say : forget about the specs and focus on the implementation
15:29:18 <n0ano> bauzas, +1
15:29:32 <bauzas> in the meantime, I'll cover the spec stuff by asking for Liberty fast approval
15:29:37 <bauzas> shouldn't be a big deal
15:29:47 <n0ano> bauzas, famous last words :-)
15:29:53 <bauzas> but I'll drop the 2nd spec
15:30:00 <edleafe> n0ano: was just going to say the same thing :)
15:30:30 <n0ano> bauzas, OK, sounds like you're driving this fine we'll just see how it goes
15:30:30 <bauzas> well, my trustness increased a lot once I had bp/isolate-sched-db merged in 3 days
15:30:52 <n0ano> let's move on then
15:30:56 <n0ano> #topic opens
15:31:00 <n0ano> anything new?
15:31:01 <bauzas> and bp/detach-service has good press
15:31:13 <sahid> PaulMurray: i'm here yes
15:31:47 <n0ano> sahid, scroll back, we were wondering about https://review.openstack.org/#/c/137817/
15:31:48 <sahid> i going to work on ttps://review.openstack.org/#/c/137817/
15:31:53 <sahid> yep
15:32:14 <sahid> we need to talk to jay with ndipanov
15:33:29 <sahid> the issue is alse in relation with this bp https://blueprints.launchpad.net/nova/+spec/allocation-ratio-to-resource-tracker
15:33:32 <sahid> also
15:34:57 <bauzas> sahid: hum, old story here
15:35:05 <n0ano> sahid, that allocation BP hasn't even been started, are you dependant upon it?
15:35:19 <bauzas> sahid: I mean, that BP is not started yet
15:35:47 <sahid> n0ano: not dependant but should be interesting to speak about it with jay
15:36:13 <sahid> about to think of the direction of the work done here ttps://review.openstack.org/#/c/137817/
15:36:51 <PaulMurray> sahid, the primary objective of the RT objects work at the moment
15:37:00 <PaulMurray> is to gat rid of any conductor calls from RT
15:37:08 <PaulMurray> to allow on line upgrade
15:37:24 <PaulMurray> sahid, I think your change is not necessary for that - is that right?
15:38:33 <sahid> PaulMurray: i think so yes
15:39:24 <PaulMurray> sahid, the changes lxsli has after you in the series are needed, lxsli do you really need sahid change to go first?
15:39:50 <lxsli> PaulMurray: it made the NUMA tests considerably easier but it's possible I could rebase off
15:40:13 <PaulMurray> (n0ano, bauzas  sorry I think we have gone off topic for a moment)
15:40:35 <n0ano> PaulMurray, not too much, this is important so I don't have a problem finishing this up
15:40:37 <sahid> PaulMurray: the point is only few people can review the work done
15:40:58 <PaulMurray> lxsli, there is still an ordering issue between your changes and mine I think because both on RT and RT-tests
15:41:23 <bauzas> PaulMurray: eh that's opens
15:41:26 <n0ano> but is sounds like if lxsli can make his changes independent from sahid that would be best
15:41:27 <PaulMurray> so it might be ok if we get mine through and then worry about it later?
15:41:43 <PaulMurray> like later in the week hopefully....
15:41:52 <lxsli> when's the next deadline?
15:42:18 <PaulMurray> FF is.....
15:42:27 <n0ano> FF is 3/12
15:42:34 <lxsli> Yow. OK thanks
15:42:40 <bauzas> https://wiki.openstack.org/wiki/Kilo_Release_Schedule
15:42:56 <bauzas> n0ano: nope
15:43:01 <bauzas> n0ano: 3/19th
15:43:09 <n0ano> note, deep freeze is 3/19
15:43:23 <PaulMurray> bauzas, yes, I see 3/19
15:43:26 <lxsli> Right, that's a bit easier, still I'll prio this
15:43:30 <n0ano> bauzas, you're right, 3/12 is oslo, my bad
15:43:47 <PaulMurray> n0ano, yes, you gave me a shock for a moment then...
15:44:01 <n0ano> PaulMurray, just making sure you heart still works :-)
15:44:15 <lxsli> n0ano ever worked in a match factory?
15:44:56 <n0ano> lxsli, I think I almost just created a fire :-)
15:45:06 <n0ano> anyway, are we good on this subject for now?
15:45:12 <sahid> perhaps use the time to rework that work to review what is already done...
15:45:28 <sahid> to review
15:46:04 <sahid> ... i mean instead of working to separate the changes, why not to use that time to review the work already done
15:46:48 <n0ano> sahid, I worry about depend patches, if we can do things independently things will go much smoother
15:46:50 <lxsli> My patches are (afaik) ready to go whereas it's unknown how long it'll take to make ndipanov happy
15:46:56 <bauzas> sahid: I'm an optimist, we can do both :)
15:47:07 <n0ano> lxsli, +1 (my thought exactly)
15:47:10 <ndipanov> lxsli, which ones
15:47:14 <bauzas> well, provided someone's not hitting a bug that takes all his time :)
15:47:14 <lxsli> but yes if your patch suddenly goes through I'll be happy!
15:47:36 <n0ano> ndipanov, https://review.openstack.org/#/c/145619/
15:47:36 <lxsli> ndipanov: https://review.openstack.org/#/c/137817/
15:47:45 <ndipanov> lol those are 2 different patches
15:47:55 <n0ano> ndipanov, ignore me, bad paste
15:48:23 <PaulMurray> ndipanov, https://review.openstack.org/#/c/137817/ is blocking
15:48:32 <ndipanov> I see
15:48:39 <ndipanov> well I don't know what to tell you guys
15:48:43 <sahid> well i can understand, i just say that that effort can be done to make thing moving insteadof rewrite and rewrite and..
15:48:52 <ndipanov> I hate that we have that
15:49:05 <ndipanov> attempt to put "ratio" into limits
15:49:09 <ndipanov> that's just like
15:49:14 <ndipanov> sloppy
15:49:36 <PaulMurray> ndipanov, the work it is blocking is for on line upgrade - we can reorder if that patch not likely to be resolved
15:49:39 <n0ano> we're not trying to resolve 137817 here, just seeing how we can handle the dependency
15:50:00 <ndipanov> n0ano, can it be dropped from the critical path
15:50:03 <PaulMurray> ndipanov, so if its likely to be sorted quicly we can keep the order
15:50:09 <sahid> n0ano: perhaps thinking about how to resolve can help to handle dependency
15:50:09 <ndipanov> hmmm
15:50:18 <ndipanov> well
15:50:25 <PaulMurray> ndipanov, if not we can reoder to get the upgrade stuff in
15:50:30 <n0ano> ndipanov, we think so, lxsli is the one that would have to change his patch
15:50:45 <ndipanov> ok let me review the whole series today
15:50:58 <PaulMurray> ndipanov, thanks, much appreciated
15:50:59 <ndipanov> (once I'm done with some documentation(
15:51:02 <ndipanov> and then I'll vote with that in mind
15:51:03 <ndipanov> I mean
15:51:25 <ndipanov> I don't think it's critical so if it's stopping useful work - I can just let it go
15:51:44 <PaulMurray> ndipanov, your call :)
15:52:34 <ndipanov> yeah - I wasn't too constructive on that one - I just kept looking at that patch without looking at the big picture
15:52:37 <ndipanov> but I have an idea
15:53:34 <n0ano> how about if ndipanov does a +1 on 137817 by tomorrow we'll stay the course, otherwise lxsli can rework his patch to not be dependent upon this one
15:54:03 <PaulMurray> n0ano, +1
15:54:21 <lxsli> n0ano: +1
15:54:35 <n0ano> sounds good...
15:54:44 <n0ano> anything else new in the last 5 minutes we have?
15:54:57 <ndipanov> n0ano, -1 - s/rework/re-work/
15:55:03 * ndipanov kids
15:55:08 <lxsli> too soon
15:55:12 <ndipanov> lol
15:55:37 <bauzas> https://review.openstack.org/#/c/162180/ comments are welcome
15:55:46 <n0ano> ndipanov, are you sure, I'll have to check www.m-w.com on that :-)
15:56:12 <PaulMurray> bauzas, you see my comment already?
15:56:51 <bauzas> PaulMurray: yeah
15:57:10 <n0ano> anyway, I think we can call it a meeting and move anything else over to the nova channel
15:57:16 <bauzas> PaulMurray: I don't see how it could add more nodes to be checked
15:57:19 <n0ano> tnx everyone, talk to you next week
15:57:26 <n0ano> #endmeeting