15:00:01 <bauzas> #startmeeting gantt
15:00:02 <openstack> Meeting started Tue Mar 31 15:00:01 2015 UTC and is due to finish in 60 minutes.  The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:06 <openstack> The meeting name has been set to 'gantt'
15:00:27 <bauzas> aloha, anyone here ?
15:00:34 <edleafe> \o
15:00:41 <alex_xu> o/
15:00:47 <bauzas> n0ano is having a meeting conflict so I'm chairing for this week
15:01:10 <bauzas> okay, waiting a few mins and then we begin
15:01:23 <lxsli> o/
15:03:41 <bauzas> okay, let's begin and people will come
15:03:46 <bauzas> so
15:03:48 <bauzas> #link https://etherpad.openstack.org/p/nova-scheduler-meeting
15:03:57 <bauzas> sorry I had no time for sending out an email
15:04:06 <bauzas> feel free to add your points in there
15:04:32 <bauzas> #topic meeting name
15:04:49 <bauzas> so, perhaps some of you already saw http://lists.openstack.org/pipermail/openstack-dev/2015-March/060179.html
15:04:52 <bauzas> #link http://lists.openstack.org/pipermail/openstack-dev/2015-March/060179.html
15:05:22 <bauzas> that's bad to not have n0ano today but would like to get your views
15:05:34 <bauzas> soooooo
15:05:42 <edleafe> I always thought of Gantt related to scheduler like Cinder related to nova-volume
15:05:53 <bauzas> I would like to see this meeting the last time I'm calling it Gantt
15:05:59 <bauzas> until we really spin off Gantt
15:06:14 <edleafe> bauzas: +1 on calling this nova-scheduler
15:06:21 <bauzas> edleafe: agreed but we're now in the same state than Cinder :)
15:06:33 <bauzas> *not
15:06:41 <bauzas> dammit, stupid fingers
15:07:13 <edleafe> bauzas: exactly, which is why it is premature to call this Gantt
15:07:17 <bauzas> ok, anyone else ? feel free to give your point at the thread
15:07:21 <alex_xu> but we discussion what will look like for gantt at future at here also?
15:07:37 <bauzas> alex_xu: that's not actually bad
15:07:51 <bauzas> alex_xu: we can still discuss on the next features and the target
15:08:04 <bauzas> alex_xu: it will just help newcomers to join us
15:08:29 <bauzas> and my point goes to jay's comments about doubts of the legal issues we could raise
15:08:58 <bauzas> before actually being sure that Gantt is the right codename, we should also ask the Foundation if that's correct for a project name
15:09:13 <bauzas> I know how it's painful to rewrite the namespace...
15:09:31 <PaulMurray> wasn't gantt french?
15:09:38 <bauzas> (for teasers, just look at Climate/Blazar repo)
15:09:42 <edleafe> Not sure about legal problems. The name 'Gantt' for scheduling is over 100 years old
15:09:59 <edleafe> pretty generic at this point
15:10:04 <bauzas> PaulMurray: everything good is French, don't you know, English man ?
15:10:33 <bauzas> edleafe: yeah, but I would like to be sure we're not wrong
15:11:06 <bauzas> so, back to the topic, feel free to leave your comments on the thread
15:11:14 <bauzas> on the mean time...
15:11:28 <bauzas> #action bauzas to check with Foundation about possible legal issues with the "Gantt" codename
15:12:22 <bauzas> okay, let's continue, I just would like to see all your point before the next meeting
15:13:02 <bauzas> #info Comments appreciated on http://lists.openstack.org/pipermail/openstack-dev/2015-March/060179.html
15:13:14 <bauzas> #topic Patch status
15:13:26 <bauzas> anyone ? I'm passing
15:13:41 <bauzas> I'm quite busy with the cells fixable stuff
15:14:13 <edleafe> Saw that PaulMurray's first patch in the series finally merged. Congrats!
15:14:18 <bauzas> yay !
15:14:48 <PaulMurray> see what happens when your not looking !
15:14:53 <bauzas> at least we're in a better shape than before even if I wanted to have the RT objectified by Kilo :(
15:15:30 <PaulMurray> Well, we actually got 5 patches in a few days - including lxsli migration patches
15:15:35 <bauzas> PaulMurray: if that's a matter of *not* reviewing your changes, let me know and I'll make you a pleasure with this :)
15:16:00 <bauzas> PaulMurray: indeed, kudos to lxsli too
15:16:02 <PaulMurray> bauzas, you need to be careful with you language there - that sounded a bit .... wrong
15:16:14 <bauzas> PaulMurray: French joker card
15:16:48 <PaulMurray> bauzas, it was about core reviews....
15:17:12 <bauzas> PaulMurray: then I missed your point
15:17:13 <bauzas> :)
15:17:42 <PaulMurray> no, I mean we lacked core reviews until last minute - your language was still almost rude
15:17:49 <PaulMurray> :)
15:18:18 <ndipanov> lol
15:18:39 <PaulMurray> ndipanov, thanks for your help with the patches
15:18:54 <ndipanov> PaulMurray, I am very sad that stuff didn;t make it for kilo
15:18:58 <ndipanov> awesome work
15:19:09 <bauzas> indeed
15:19:16 <bauzas> there are some -1s IIRC
15:19:25 <PaulMurray> only you
15:19:28 <bauzas> (from me probably)
15:19:43 <bauzas> yay, shall I iterate over those still ?
15:19:45 <PaulMurray> and jenkins
15:20:00 <PaulMurray> I will rebase soon
15:20:05 <bauzas> man, I don't know who this Jenkins guy is, but he's quite rude too
15:20:29 <bauzas> anyway
15:20:43 <bauzas> any other scheduler-related stuff that we should discuss ?
15:21:12 <ndipanov> bauzas, 2 things I'd like to mention
15:21:19 <bauzas> ndipanov: go on
15:21:20 <ndipanov> that became apparent to me only lately
15:21:48 <ndipanov> 1 is that pci tracker as it stands now is reasonably buggy
15:22:14 <bauzas> well...
15:22:24 <bauzas> ndipanov: you know my opinion on that
15:22:28 <ndipanov> I am not sure how easy that is to fix, but I know what the main cause of it is
15:22:30 <ndipanov> yeah...
15:22:44 <bauzas> ndipanov: again, it's not a design problem
15:22:54 <ndipanov> I think it actually is
15:22:59 <bauzas> ndipanov: it's about the integration with the existing
15:23:03 <ndipanov> yes
15:23:08 <ndipanov> trye
15:23:10 <ndipanov> true
15:23:22 <bauzas> ndipanov: yeah I had a discussion with sean dague and dansmith about the PCI optionnality
15:23:32 <ndipanov> so expect work going into that as soon as we are using objects in RT (Paul's patches land)
15:23:57 <bauzas> ndipanov: well, the problem is also that PCI is always tracking stuff while filters are perhaps not enabled
15:24:23 <ndipanov> that's a whole other story
15:24:28 <bauzas> true
15:24:34 <bauzas> and too broad for discussing it there
15:25:03 <ndipanov> second is that there have been several issues with "resources" such as pci and numa
15:25:03 <bauzas> ndipanov: so yeah, I expect PaulMurray's work on objectifying the RT could help us a lot
15:25:19 <ndipanov> that I feel are basically the same class of errors
15:25:32 <bauzas> ndipanov: any precise issues that you could share with us ?
15:25:36 <ndipanov> yes
15:25:43 * ndipanov looks for bugs
15:26:14 <bauzas> ndipanov: in the meantime, could we jump onto the next topic and come back to your point for the open discussion ?
15:26:35 <bauzas> the next topic is Vancouver summit talks
15:27:04 <bauzas> okay, guessing it's a yes
15:27:15 <ndipanov> https://bugs.launchpad.net/nova/+bug/1417667
15:27:16 <openstack> Launchpad bug 1417667 in OpenStack Compute (nova) "migration/evacuation/rebuild/resize of instance with dedicated cpus needs to recalculate cpus on destination" [Medium,In progress] - Assigned to Bart Wensley (bartwensley)
15:27:17 <bauzas> #topicVancouver discussion ideas
15:27:20 <ndipanov> yes
15:27:24 <bauzas> erm
15:27:26 <bauzas> #topic Vancouver discussion ideas
15:27:28 <ndipanov> ping me once open-discussion happens
15:27:32 <bauzas> ndipanov: sure thing
15:27:45 <bauzas> so, any ideas so far ?
15:28:59 <bauzas> just to be clear, I have no precise information about how the Design Summit will be held, only that we'll have a nice sightseeing from the place we'll be :)à
15:29:36 <bauzas> ttx proposed a discussion about the Design Summit format and talks for today's cross-project meeting
15:29:57 <bauzas> #link http://lists.openstack.org/pipermail/openstack-dev/2015-March/060258.html
15:30:21 <bauzas> I shouldn't be able to attend today's meeting (damn DST) but feel free to attend
15:31:14 <edleafe> I'll try to make it
15:31:21 <bauzas> cool
15:31:33 <bauzas> anyway, I propose to defer our discussions until next week
15:31:40 <edleafe> I have another call then, but I can lurk
15:31:43 <bauzas> so that we should get a better picture about that
15:31:46 <bauzas> also
15:32:30 <bauzas> mikal proposed an etherpad for tracking *nova related* discussions http://lists.openstack.org/pipermail/openstack-dev/2015-March/060024.html
15:32:38 <bauzas> #link https://etherpad.openstack.org/p/liberty-nova-summit-ideas
15:32:59 <bauzas> feel free to point out any point about our concerns that are related to Nova
15:33:49 <bauzas> at the moment, the only related point to the scheduler is about the split, but I guess we should have more to discuss
15:34:50 <bauzas> okay, last but not least topic unless someone's screaming in the next minute
15:35:39 <bauzas> let's openly open the open discussion
15:35:58 <bauzas> #topic open discussion
15:36:15 <bauzas> so, ndipanov had some bugs to provide us related to the PCI and NUMA resource tracking
15:36:42 <bauzas> ndipanov: ping
15:39:38 <edleafe> pinged him in openstack-nova
15:40:08 <bauzas> we can wait a few more mins, he's possibly afk
15:40:28 <bauzas> any other subject people are wanting to discuss meanwhile ?
15:40:45 <bauzas> oh
15:40:58 <bauzas> that reminds me one big thing I forgot to mention
15:41:22 <bauzas> #link https://review.openstack.org/#/c/168682/
15:41:36 <bauzas> #link https://review.openstack.org/#/c/168883/
15:41:48 <bauzas> both are related to the existing Gantt repo
15:42:02 <bauzas> which is actually just a wrong thing
15:42:13 <bauzas> (speaking of the existing repo)à
15:42:52 <edleafe> bauzas: I wasn't involved in that Gantt work. Is there value in keeping it?
15:43:00 <edleafe> bauzas: or should we start clean?
15:43:08 <bauzas> edleafe: honestly, nothing but a trace
15:43:26 <bauzas> edleafe: the real problem is how painful it is to remove a repo or rename it
15:44:09 <ndipanov> bauzas, right
15:44:13 <bauzas> edleafe: so we keep it as a reference but with a big disclaimer saying that the code is just messy
15:44:15 <edleafe> bauzas: ok, but these are simply to get them out of infra, right?
15:44:25 <bauzas> edleafe: not really
15:44:30 <ndipanov> https://bugs.launchpad.net/nova/+bug/1417667
15:44:32 <openstack> Launchpad bug 1417667 in OpenStack Compute (nova) "migration/evacuation/rebuild/resize of instance with dedicated cpus needs to recalculate cpus on destination" [Medium,In progress] - Assigned to Bart Wensley (bartwensley)
15:44:33 <ndipanov> is the bug
15:44:42 <bauzas> edleafe: all of the decisions would require a manual intervention
15:44:51 <bauzas> anyway
15:44:56 <bauzas> back to ndipanov's point
15:45:02 <ndipanov> right
15:45:06 <ndipanov> so these kind of problems
15:45:12 <ndipanov> exist with
15:45:12 <bauzas> oh this
15:45:18 <ndipanov> what I can only describe as
15:45:26 <ndipanov> "stateful" resources
15:45:40 <bauzas> mmm
15:45:44 <ndipanov> where next allocation is the function of previous allocations
15:45:49 <ndipanov> not only thieir count
15:46:08 <ndipanov> two of those that we have are numa and pci stuff
15:46:27 <bauzas> ndipanov: I see, the problem being that's a bucket of instances, and not a single instance boot, right ?
15:46:34 <ndipanov> no
15:46:41 <bauzas> okay, then I misunderstood
15:47:01 <ndipanov> so the problem is when migrating/resizing
15:47:16 <ndipanov> and evacuating (although I am not sure how that should work)
15:47:21 <bauzas> oooooh understood
15:47:27 <bauzas> policies are not enforced
15:47:36 <ndipanov> em
15:47:37 <ndipanov> no
15:47:39 <bauzas> are we sure that the reporter didn't ask for a destination host ?
15:48:12 <bauzas> by saying "policies", I was meaning that the filters were not taken in account ( not the nova policy thing)
15:48:22 <ndipanov> well that's one thing
15:48:40 <alex_xu> ndipanov: because the request spec and status after boot was stored in single object?
15:48:44 <bauzas> ndipanov: you know that migrations are able to bypass the scheduler if a dest host is specified ?
15:49:18 <ndipanov> so the thing is
15:49:27 <ndipanov> the other thing
15:49:29 <bauzas> ndipanov: we totally get rid of the scheduler when we're migrating to a specified dest host
15:49:34 <ndipanov> is that we track migrations via flavor
15:49:45 <bauzas> yup
15:49:59 <ndipanov> but you can't do that for pci/numa
15:50:03 <ndipanov> and similar resources
15:50:11 <ndipanov> because it is not only the "count"
15:50:14 <ndipanov> that is important
15:50:18 <ndipanov> but the actual allocation
15:50:26 <ndipanov> at the time of claim
15:50:56 <PaulMurray> its not the fact that there is a device - its which one
15:50:59 <bauzas> ndipanov: but claims are reported as usage right ?
15:51:04 <ndipanov> because it may be different at the time of the RT loop because it is a function of all previous allocations on the host
15:51:10 <ndipanov> yes PaulMurray that's exactly it
15:51:47 <ndipanov> this likely means that we have to keep a record of said allocations with the migration row
15:51:51 <ndipanov> which is fine
15:51:55 <ndipanov> I guess
15:52:27 <ndipanov> but 1) it needs to be written 2) I wonder if there is a more general API we could have
15:52:32 <ndipanov> once we actually have resources
15:52:41 <bauzas> ndipanov: I'm quite blind on the NUMA stuff (with much regret)
15:52:41 <ndipanov> so my question is
15:53:14 <ndipanov> would it be ok to sprinkle these 2 special cases as columns
15:53:16 <bauzas> ndipanov: but I was thinking that we were tracking that for example pCPU0 was pinned as an usage
15:53:28 <ndipanov> we are
15:53:37 <ndipanov> but you can't recreate which one from just the flavor
15:53:54 <ndipanov> you have to store the actual allocation somewhere
15:54:07 <bauzas> ndipanov: oh I see, that's not persisteed
15:54:08 <ndipanov> for boot - we store it on the instance
15:54:13 <ndipanov> but for migration...
15:54:22 <PaulMurray> ndipanov, if claims become a first class object, would that be the place?
15:54:31 <ndipanov> PaulMurray, maybe
15:54:39 <ndipanov> yes
15:54:41 <bauzas> I tend to say that we definitely miss bp/resource-objects
15:54:51 <ndipanov> yes
15:54:53 <ndipanov> so my question was
15:55:10 <ndipanov> should we hack on fixing it and hope to generalize it later with Claim/resource objects
15:55:15 <ndipanov> or the other way around
15:55:38 <bauzas> well, bp/resource-objects was expected to be worked during Kilo
15:55:51 <bauzas> so we should loop back with jaypipes
15:56:07 <ndipanov> bauzas, the thing is that it's a bug
15:56:16 <ndipanov> but one that seems to be easily generalizable
15:56:22 <ndipanov> if there were a place to generalize it
15:56:48 <bauzas> ndipanov: agreed, but I think the generalization has to be done alas bp/resource-objects
15:57:25 <ndipanov> right
15:57:41 <ndipanov> ok well
15:57:44 <bauzas> ndipanov: that said, I would appreciate your bugfix
15:57:51 <ndipanov> there is a patch that proposes this for numa already
15:57:57 <bauzas> ndipanov: because it gives us a path for fixing it
15:58:16 <ndipanov> I will look into the pci side of things as well
15:58:17 <bauzas> ndipanov: oh right, the bug is mentioning it
15:58:30 <ndipanov> and then hopefully we'll meet in the middle with resource objects
15:58:39 <bauzas> ndipanov: https://review.openstack.org/163440 is the one about NUMA ?
15:58:52 <bauzas> caution : not having yet reviewed the change
15:58:54 <ndipanov> yes!!
15:59:03 <bauzas> woaw, fat one then
15:59:14 <bauzas> but that sounds doable
15:59:35 <bauzas> ndipanov: do you think we should target it for RC1 ?
15:59:57 <bauzas> ndipanov: I haven't yet reviewed the change so I don't know if it's landable yet
16:00:17 <bauzas> damn, we're running out of time
16:00:31 <ndipanov> bauzas, with db migrations...
16:00:31 <bauzas> let's discuss that offline and free up the lock
16:00:33 <ndipanov> I think not
16:00:33 <edleafe> bauzas: it hasobject version bumps
16:00:43 <bauzas> ndipanov: edleafe: ooooh
16:00:46 <ndipanov> I don't think it's that critical
16:00:52 <bauzas> then yes, it will be fixed in Liberty
16:00:56 <ndipanov> worth a relnote for sure
16:00:59 <bauzas> ok guys, take care
16:01:04 <bauzas> #endmeeting