15:01:04 <n0ano> #startmeeting gantt
15:01:07 <openstack> Meeting started Tue Dec  2 15:01:04 2014 UTC and is due to finish in 60 minutes.  The chair is n0ano. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:10 <openstack> The meeting name has been set to 'gantt'
15:01:19 <n0ano> Anyone here to talk scheduler?
15:01:23 <lxsli> o/
15:01:23 <edleafe> \o
15:01:58 <jaypipes> o/
15:02:13 <PaulMurray> hi
15:02:15 <bauzas> \o
15:02:19 <lxsli> ccccombo breaker
15:02:26 <jaypipes> :)
15:02:32 <n0ano> note I actually got the time right this week, hopefully it's the start of a trend
15:02:36 <n0ano> anyway...
15:02:38 <bauzas> yey!
15:02:40 <jaypipes> yay, me too! :)
15:02:59 <n0ano> #topic forklift status
15:03:02 <jaypipes> n0ano: ok, so some biggish news...
15:03:12 <n0ano> baited breath
15:03:29 <jaypipes> n0ano: got agreement from danpb to merge his get_available_resource() blueprint into my resource-objects blueprint.
15:03:50 <jaypipes> n0ano: so I pulled his blueprint from the Gantt/kilo wiki page.
15:04:00 <bauzas> jaypipes: will you have time to work on ? :)
15:04:19 <bauzas> jaypipes: I know that you're quite also committed to the NUMA objects stuff :)
15:04:22 <jaypipes> n0ano: me, sahid, and ndipanov made a lot of progress on objectifying nova/virt/hardware.py last week and this week.
15:04:37 <jaypipes> bauzas: well, it's a dependent requirement
15:05:03 <n0ano> jaypipes, implication being we control out destiny a little better, right?
15:05:10 <n0ano> s/out/our
15:05:14 <jaypipes> bauzas: something that is also relevant to your detach service work: https://review.openstack.org/#/c/138236/
15:05:18 <jaypipes> n0ano: yes.
15:05:41 <jaypipes> n0ano: and will allow the NUMA pinning/huge page folks to make progress without any dependencies on our own work.
15:05:51 <bauzas> jaypipes: this review is already provided on my own patch series
15:06:15 <n0ano> jaypipes, to be clear, that means the separate BP goes away and we just have one BP to cover both topics, right?
15:06:18 <bauzas> jaypipes: that was just part of a week work :)
15:06:23 <jaypipes> n0ano: correct.
15:06:45 <bauzas> jaypipes: I think we need to discuss really, because I made one week to provide this so I don't want you to spend 1 week too :)
15:06:52 <jaypipes> bauzas: your BP was to detach the service from the compute node, not to make the scheduler use objects...
15:07:00 <bauzas> jaypipes: I'm just rebasing my work and you'll see
15:07:29 <bauzas> jaypipes: in order to do the detach service work, I needed to do this
15:08:35 <bauzas> jaypipes: I actually provided the new patch series now
15:09:06 <bauzas> jaypipes: because I fixed the last Jenkins issues
15:09:24 <bauzas> https://review.openstack.org/#/c/138294/
15:09:34 <jaypipes> bauzas: your patch series seems to me to take on a lot more than detaching service from the cmopute node
15:10:01 <bauzas> jaypipes: that's needed because we need to
15:10:07 <bauzas> 1/ keep the service_id field
15:10:14 <jaypipes> bauzas: part of the reason I did my patch was to make an incremental thing that did not need any DB changes or anything...
15:10:15 <bauzas> 2/ provide another way to get the service info
15:10:26 <bauzas> 3/ provide live data migrations
15:10:41 <bauzas> so I had to change all the calls to the objects side
15:11:00 <jaypipes> bauzas: I really don't see why.
15:11:22 <bauzas> jaypipes: we can't remove the service_id field
15:11:27 <jaypipes> bauzas: all my patch does is make the host manager use ComputeNodeList.get_all() instead of db.compute_node_get_all(), and fixes the unit tests.
15:11:28 <bauzas> jaypipes: in the DB
15:11:39 <jaypipes> bauzas: my patch doesn't touch service ID.
15:12:05 <bauzas> jaypipes: I also needed to keep the compute['service'] dict
15:12:23 <bauzas> jaypipes: so I changed the way to get it by using the object field
15:13:02 <bauzas> jaypipes: anyway, read my patch series, and I hope you'll understand
15:13:09 <bauzas> jaypipes: I'll review your own too
15:13:14 <jaypipes> bauzas: please look at my patch... I don't see any reason it cannot go in before your series. it doesn't touch the schema of compute node nor does it change the service relationship. it just fixes the host manager to call the objects instead of boiling th eocean.
15:13:27 <bauzas> jaypipes: yeah agreed
15:13:28 <jaypipes> bauzas: I will review all of yours this morning. it's my top priority.
15:13:37 <bauzas> jaypipes: I'm not saying we couldn't do that earlier
15:13:53 <bauzas> jaypipes: but when I worked on it last week, there was no patch on it
15:13:58 <bauzas> jaypipes: so I did the job
15:14:10 <bauzas> jaypipes: and I can see that Jenkins is still unhappy with your patch
15:14:28 <jaypipes> bauzas: but I'm seeing that your patch series does it backwards... i.e. it changes the compute node structure and *then* changes the host manager to use obejcts.
15:14:28 <bauzas> jaypipes: so, I'm just saying that I don't want that both of us spend 1 week for doing this
15:14:44 <bauzas> jaypipes: is that frankly a problem ?
15:15:29 <jaypipes> bauzas: I will review your patch series this morning and let you know.
15:15:41 <bauzas> jaypipes: again, it's not a matter of doing this or not, just a matter of making sure we're not doing the same things both of us
15:16:06 <bauzas> jaypipes: because your time and mine are precious :)
15:16:11 <jaypipes> agreed.
15:16:14 <ndipanov> bauzas, jaypipes for us late arrivers can you re-ling the patch
15:16:21 <ndipanov> link *
15:16:35 <jaypipes> ok, let's move on. we can disucss the object/detach stuff on the patch seriers.
15:16:41 <jaypipes> ndipanov: you haven't missed anything yet
15:16:44 <n0ano> hopefully, the point of BPs was to identify what is being done so we don't have overlap, is there a process gap we need to address?
15:16:53 <bauzas> ndipanov: https://review.openstack.org/#/c/138294/ about objectifying db.compute_node_get and get_all
15:17:11 <bauzas> ndipanov: https://review.openstack.org/#/c/138236/1 about objectifying call in HostManager
15:17:31 <ndipanov> mega cool bauzas
15:17:54 <bauzas> ndipanov: the former is part of a series for detach-service BP
15:17:55 <ndipanov> although the last one is red like me after a morning on the beach in June
15:18:00 * ndipanov too white
15:18:03 <bauzas> ndipanov: the latter is separate
15:18:28 <jaypipes> n0ano: the point of the blueprints is to work on the stuff that is detailed in the blueprint, yes.
15:18:43 <n0ano> well, if we want to move on, I wanted to look at our tracking page https://wiki.openstack.org/wiki/Gantt/kilo#Tasks
15:18:49 <ndipanov> bauzas, ok will review these
15:19:02 <bauzas> ndipanov: thanks
15:19:16 <n0ano> I'm still concerned that, out of 8 major items, only 2 have been approved and K1 deadline is soon
15:19:59 <bauzas> n0ano: I provided the links to both the K2 specs for me in https://etherpad.openstack.org/p/kilo-nova-priorities-tracking
15:20:16 <bauzas> n0ano: I'm waiting reviews on them
15:20:55 <bauzas> n0ano: https://review.openstack.org/89893 has -2 from johnthetubaguy but we googled hangout last week and we agreed on another way to do this
15:21:25 <bauzas> n0ano: I'll also provide all the alternatives in the 'alternatives' section, so reviewers could +1/-1 them
15:21:36 <bauzas> n0ano: that's planned to do so by EOW
15:21:42 <n0ano> looking at the updated table it looks a little better, the CPU pinning is the only K1 item that hasn't been accepted yet
15:23:29 <jaypipes> n0ano: CPU pinning is only on the table because it has a dependency on the objectification cleanups that we've been working on that are not tracked by any blueprints.
15:23:39 <n0ano> in re: accepted BPs, now the question is how are the patches to implement them, PaulMurray & bauzas can you comment on the first two
15:24:25 <PaulMurray> n0ano, shall I go first
15:24:50 <n0ano> PaulMurray, go for it
15:25:31 <bauzas> PaulMurray: sure
15:25:33 <PaulMurray> n0ano, there are two points really - we have a patch to get pci_stats (becomeing pci_device_stats) in to compute node
15:25:51 <PaulMurray> and then some refactoring tests going on
15:26:07 <PaulMurray> I can see that only two patches are there for that the moment, but there is more lined up
15:26:14 <PaulMurray> that would be blocked by those
15:26:21 <PaulMurray> so we will get those up shortly
15:26:40 <PaulMurray> the main point about pci_device_stats is to decide how to list tags
15:27:00 <PaulMurray> the patch gives a first stab, but will change now I have some feedback from yunhong
15:27:18 <PaulMurray> so if we can get those through I can get the rest lined up
15:27:26 <n0ano> so sounds like you are getting input from the PCI people, that's good
15:28:07 <PaulMurray> lxsli, is doing tests and will help with more as well
15:28:17 <PaulMurray> n0ano, that's about it for that one
15:28:50 <n0ano> PaulMurray, cool, sounds like good progress and line of sight for K1, tnx
15:29:05 <bauzas> PaulMurray: I had no time for reviews the last days, but I'll provide some comments, sure
15:29:14 <PaulMurray> bauzas, thanks
15:29:43 <n0ano> bauzas, anything else to say about detach service from compute node?
15:30:04 <bauzas> n0ano: well, it's on-going, because I had to refactor all my stuff last week by using objects
15:30:28 <bauzas> n0ano: so, that still requires 3 patches or so in the series (atm, there 8 patches)
15:30:46 <bauzas> n0ano: the direction is quite OK, I just need to provide the last changesd
15:30:56 <n0ano> hmm, I notice that our tracking page says this is K1 but the BP now says K2, which is correct
15:30:59 <bauzas> n0ano: the first patches are there for review anywauy
15:31:06 <bauzas> n0ano: why so ?
15:31:24 <bauzas> n0ano: you mean detach-service ?
15:31:32 <bauzas> n0ano: it's targeted for K1
15:31:42 <n0ano> bauzas, yeah, https://blueprints.launchpad.net/nova/+spec/detach-service-from-computenode
15:31:54 <bauzas> n0ano: mmm, will discuss with johnthetubaguy about this
15:32:09 <johnthetubaguy> bauzas: whats up?
15:32:24 <johnthetubaguy> bauzas: anyone can move the milestone on the BP, if thats what you want
15:32:25 <bauzas> johnthetubaguy: nothing really important now, just a wrong milestone for a BP $
15:32:36 <bauzas> johnthetubaguy: oh ok, will do then
15:32:57 <johnthetubaguy> bauzas: I will probably move all BPs that are not NeedsCodeReview into kilo-2 very soon though
15:33:29 * n0ano wonders who changed it and if there's a history to launchpad
15:33:30 <bauzas> johnthetubaguy: well, it seems the Launchpad bot did do his wrk
15:33:43 <bauzas> johnthetubaguy: refresh the page
15:34:11 <johnthetubaguy> :S
15:34:16 <n0ano> now the BP is back to K1
15:34:22 <bauzas> n0ano: I did that
15:34:34 <bauzas> n0ano: and I changed to 'Needs Code Review'
15:34:36 * n0ano has trouble keeping up
15:35:07 * johnthetubaguy bravely runs away...
15:35:23 <n0ano> bauzas, implication being that all the patches to implement it are posted?
15:35:43 <bauzas> n0ano: that's incremental
15:35:55 <johnthetubaguy> n0ano: you are correct, thats what it should mean
15:36:21 <bauzas> johnthetubaguy: then, moving it back to "in progress"
15:36:27 * bauzas likes doing paperwork :)
15:36:54 <n0ano> I'm more concerned about doing the work but some paperwok is helpful
15:37:17 <n0ano> anyway, good progress, no matter what the status there are patches that need reviewing
15:38:42 * n0ano watches the wind blow over my trach can :-(
15:39:14 <n0ano> I think we've dealt with the current dashboad == everyone do reviews
15:39:21 <n0ano> #topic opens
15:39:40 <n0ano> anything new anyone wants to raise today?
15:39:41 <bauzas> sh*it, I quickly fixed some merge problems, and I made 2 errors in my series
15:40:07 <n0ano> bauzas, NP, fix it quickly and we won't even notice :-)
15:40:09 <bauzas> as said ndipanov, I need some solar cream for my red skin
15:41:20 <n0ano> well, not hearing anything
15:41:34 <n0ano> I say we all get back to work
15:41:47 <bauzas> crickets?
15:41:47 <n0ano> tnx everyone, talk to you again next week
15:41:51 <bauzas> thanks
15:41:57 <n0ano> #endmeeting