14:07:19 <n0ano> #startmeeting nova-scheduler
14:07:20 <openstack> Meeting started Mon Jul 27 14:07:19 2015 UTC and is due to finish in 60 minutes.  The chair is n0ano. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:07:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:07:24 <openstack> The meeting name has been set to 'nova_scheduler'
14:07:32 <n0ano> just so the logging is correct
14:07:39 <n0ano> #topic liberty-specs
14:07:49 <n0ano> bauzas, lxsli are hee
14:07:58 <lxsli> #link http://eavesdrop.openstack.org/meetings/nove_scheduler/2015/nove_scheduler.2015-07-27-14.00.log.html
14:07:59 <bauzas> _o
14:08:02 <n0ano> g issues is bauzas you are rather overloaded, are there some patches you can hand off to interested 3rd parties?
14:08:16 <n0ano> s/^g/big
14:08:23 <bauzas> so, like I said, I'm done with implementing the RequestSpec object BP
14:08:35 <n0ano> bauzas, congratulationgs, that's a big one
14:08:53 * n0ano cannot type this morning, just interpolate what I'm trying to say
14:08:54 <bauzas> so, now, I'm like oncall, waiting for reviews
14:09:03 <bauzas> and then, the upload dance
14:09:16 <n0ano> bauzas, didn't you have a migration spec also?
14:09:52 <bauzas> n0ano: so, yeah, what we're missing is
14:10:02 <bauzas> 1/ resource-objects -> jay's on it
14:10:19 <bauzas> 2/ check-dest-on-migrations -> spec's been approved last week \o/
14:10:41 <bauzas> 3/ alloc-ratios-to-RT -> spec approved, implem begun
14:11:17 <bauzas> what's taken by alaski is persist-request-spec
14:12:08 <bauzas> so, here is the thing
14:12:44 <bauzas> I can play with alloc-ratios-to-RT because that's already started, with high chances of getting it done for L3
14:13:01 <bauzas> what I won't really have time for is the check-dest-on-mig BP
14:13:05 <bauzas> *that said*
14:13:28 <bauzas> check-dest-on-mig requires persist-req-spec from alaski like I said in f2f meeting
14:13:33 <bauzas> during midcycle
14:13:54 <bauzas> so, like I said, I'm pretty +1 with offloading my work
14:14:16 <bauzas> I'm just honestly wondering what can be offloaded, hence the spec reading etc.
14:14:45 <n0ano> we should be able to create some proto-type code based upon what alaski will do and then adjust it as his patches get approved
14:14:55 <bauzas> n0ano: that could work
14:15:25 <bauzas> n0ano: tbh, the persistence story is just for making sure that the scheduler knows everything about the original request before being called
14:15:32 <n0ano> I know I have some engineers that would love to work on this, I can have them start looking at it.
14:15:44 <bauzas> n0ano: since the spec is focusing on fixing the migration, that means that the instance has been already booted
14:15:57 <bauzas> n0ano: well, I heard about lxsli
14:16:06 <lxsli> yeah edleafe + I were both proposed
14:16:25 <bauzas> n0ano: I would certainly wait for jay before deciding anythong
14:16:30 <bauzas> anything even :p
14:16:47 <n0ano> lxsli, edleafe your call if you want to volunteer for this
14:16:53 <alaski> getting persistence for req-spec will be necessary for using it after scheduling, but any code that wants to use it can work off of bauzas req-spec object patch for prototyping
14:16:58 <bauzas> I know that edleafe is pretty busy too with the API stuff
14:17:17 <n0ano> alaski, tnx, that's what I was hoping for
14:17:24 <bauzas> alaski: yeah, that's my thoughts, the prototype can be worked on before that
14:17:38 <lxsli> yeah I can work on it
14:18:16 <bauzas> and you know, I'm French
14:18:33 <n0ano> I'm willing to let lxsli lead on this (I can get you help if you need it), I'm pretty sure jay would be comfortable with that
14:18:40 <bauzas> which means that in order to respect our local habits, I should certainly shut myself down during August
14:19:07 <n0ano> bauzas, I forgot about that, we will have to keep that in mind
14:19:07 <bauzas> I'm planning to take 2 weeks off
14:19:14 <bauzas> lxsli: your take on that ?
14:19:24 <bauzas> Aug1-15 probably
14:19:41 <n0ano> bauzas, only 2 weeks?  I'm surprised :-)
14:19:45 <lxsli> bauzas: on... you taking holiday? Shouldn't be a problem
14:19:51 <bauzas> n0ano: I have KVM Forum to attend
14:20:05 <lxsli> I'll end up taking mine in December as usual
14:20:21 <bauzas> lxsli: no, you on taking holiday too ? you're English, which means you're like French but with an hat instead of a frog
14:20:38 <n0ano> 2 months out of the gone, Aug. for the French, Dec for the Anglo's
14:20:53 <n0ano> s/the gone/the year gone
14:21:21 <bauzas> so, yeah, let's loopback that with jay anyway
14:21:31 <n0ano> bauzas, fer sur
14:21:44 <bauzas> véri ouelle
14:21:56 <n0ano> #action lxsli to take lead on implementing select destination on migration BP
14:22:02 <edleafe> sorry guys, getting in late
14:22:16 * edleafe reads scrollback...
14:22:24 <n0ano> edleafe, NP, you dodged a bullet, we gave all the work to lxsli
14:22:37 <bauzas> niark niark
14:22:46 <lxsli> yay
14:22:48 * bauzas makes little ugly noises
14:23:01 <edleafe> I do have some bandwidth available
14:23:27 <bauzas> edleafe: you're on the API subteam right?
14:23:40 <lxsli> motion: propose edleafe spend all his spare time hassling dan to review jay's spec
14:23:44 <n0ano> edleafe, do you want a cage match with lxsli on who does the migration work?
14:24:04 <bauzas> edleafe: I'm telling that, because since the API subteam has an extra time for merging, maybe you could help them too
14:24:14 <edleafe> n0ano: It wouldn't be a fair fight. :)
14:24:25 <bauzas> IIRC, lxsli is facing FF by Thursday
14:24:28 * lxsli thinks edleafe would fight mean
14:24:33 <n0ano> edleafe, what about your Cassandra work, that should be interesting
14:24:57 <lxsli> bauzas: waaait did I volunteer to do this by Thursday?!
14:25:05 <bauzas> lxsli: naaaaaaah
14:25:13 <bauzas> lxsli: I mean, you have some other BPs to care, right?
14:25:31 <edleafe> n0ano: that's been shelved
14:25:32 <bauzas> lxsli: I remember the DB purge
14:25:36 <lxsli> bauzas: oh right - those aren't priorities
14:25:51 <bauzas> lxsli: so, yeah, which means that by Thursday, you should get plenty of time
14:26:03 <n0ano> edleafe, really?  I hope not for long, I think it's interesting and shouldn't be dropped
14:26:21 <bauzas> n0ano: weren't you following the convo on Wed ?
14:26:22 <edleafe> n0ano: you were at the midcycle
14:26:40 <lxsli> n0ano: I thought the outcome was "interesting, but later"
14:26:41 <edleafe> n0ano: it wasn't deemed an important enough priority to spend any time on
14:26:57 <edleafe> lxsli: exactly - shelved
14:27:01 <bauzas> moving on, then ?
14:27:06 <n0ano> I'm with lxsli , that's what I heard, not forget about it
14:27:43 <lxsli> let's move on
14:27:49 <n0ano> OK
14:27:55 <edleafe> n0ano: that's what 'shelved' means
14:28:07 <lxsli> edleafe: we're agreeing with you :)
14:28:09 <edleafe> n0ano: put it on a shelf for now, and come back to it sometime in the future
14:28:18 <n0ano> #topic expose host capabilities
14:28:43 <n0ano> I kind of wanted jay here for this and I also wanted the email thread that johnthetubaguy was going to start on the ML
14:29:01 <n0ano> so we might be a little premature on this
14:29:30 <n0ano> basically, I think everyone agrees that overloading extra_specs is not the best way to expose host capabilities
14:29:38 <n0ano> so we need to create a new API for this
14:30:07 <bauzas> wait wait wait ?
14:30:16 <bauzas> I probably missed that then :)
14:30:28 <bauzas> what where and when ?
14:30:36 <bauzas> a new API ?
14:30:40 <n0ano> we talked about this late on wed, you probably dopped off, it's in the etherpad
14:30:56 * bauzas overlooks
14:31:23 <n0ano> bauzas, yeah, not something we'll do for Liberty of course but we neeed to start thinking about this for M or N
14:32:00 <bauzas> n0ano: aaaah that
14:32:21 <bauzas> n0ano: yeah I remember now the convo
14:32:30 <bauzas> n0ano: well, I think it's a little premature
14:32:38 <n0ano> I don't know if we need a new API call, an extension to a current API or what but I do think we need something other than overloaded extra_specs
14:32:47 <bauzas> n0ano: IIRC, the take was "let's keep that in mind, and discuss that back in Tokyo"
14:32:47 <lxsli> n0ano: which spec + line # please?
14:33:01 <lxsli> s/spec/pad/
14:33:02 <n0ano> bauzas, hence my desire to start a ML thread
14:33:11 <bauzas> n0ano: that's why you lost me with the "new API" stuff
14:33:35 <n0ano> bauzas, I was extrapolating, I don't see how we can do this without a new API
14:33:50 <n0ano> lxsli, it's the mid-cycle etherpad, let me find a link
14:33:50 <edleafe> n0ano: or a new design ;-)
14:33:52 <bauzas> n0ano: so you were talking about a REST API resource ?
14:34:08 <bauzas> lxsli: https://etherpad.openstack.org/p/liberty-nova-midcycle L92 and below
14:34:20 <n0ano> bauzas, don't know yet, that's why I want people to start thinking about it
14:34:33 <lxsli> Got it thanks
14:34:43 <bauzas> n0ano: okay, I plugged into your brain, I understand what you wanted to say
14:34:51 <n0ano> bauzas, tnx for the link, I always have trouble finding them
14:35:01 <bauzas> n0ano: in other words, we need a discovery mechanism
14:35:20 <lxsli> right yes cpu capabilities on power being a key sticking point iirc
14:35:36 <bauzas> n0ano: but I certainly think that this subject is by far widier than just the scheduler component
14:35:44 <n0ano> bauzas, both discovery and specify, I don't think extra_specs is the best way to specify them either
14:35:58 <n0ano> bauzas, I'm not sure I see that, who else would be concerned?
14:36:03 <bauzas> n0ano: because it touches the API, the flavors, the scheduler and the compute manager
14:36:28 <bauzas> by saying "the API", I'm talking about n-api
14:37:12 <bauzas> so I would certainly wait for johnthetubaguy's work :p
14:37:23 <n0ano> bauzas, I don't think I'm saying n-api but the user has to be able to specify things so it could wind up changing n-api also, it's too early to tell
14:37:26 <lxsli> he said he was pretty snowed opening L-2 right now
14:37:27 <bauzas> he volunteered on that, that's his curse :p
14:37:43 * johnthetubaguy wonders what work he is doing?
14:37:58 <bauzas> johnthetubaguy: https://etherpad.openstack.org/p/liberty-nova-midcycle L99
14:38:00 <johnthetubaguy> what did I promise to do now?
14:38:02 <n0ano> johnthetubaguy, you said you'd start a ML thread on exposing host capabilities
14:38:22 <n0ano> johnthetubaguy, if you're too busy, I can do that for you
14:39:03 <bauzas> can we just hold on that until at least jay's in ?
14:39:04 <bauzas> :p
14:39:27 <bauzas> I mean, that's his thoughts, I would certainly love to hear what he thinks about
14:39:34 <johnthetubaguy> oh, it coming back to me now
14:39:50 <bauzas> johnthetubaguy: too many beers in Rochester ? too bad
14:39:50 <n0ano> bauzas, WFM, this is longer term and doesn't require immediate action, I just don't want to forget about it
14:39:56 <johnthetubaguy> so folks here, feel free to start the ML thread, and ping me to respond
14:40:04 <johnthetubaguy> bauzas: sadly, no such problem
14:40:32 <bauzas> okay, my take on that is waiting for jay
14:40:36 <johnthetubaguy> the basic idea I had was, please discuss the user view in backlog specs where we agree the problem to solve
14:40:46 <bauzas> we need some clarification internally without writing anything :)
14:40:48 <johnthetubaguy> at the same time, we can talk about how we want to do flavors
14:40:57 <lxsli> n0ano: if you start the thread, please focus on defining the scope of the issue at first? If you propose a solution we'll get bogged down in that
14:40:58 <johnthetubaguy> then we can compare the solution with the list of problems we need to solve
14:41:20 <lxsli> ok much like john just said ^^
14:41:20 <johnthetubaguy> the idea being to stop worrying about extra specs vs something else, but agree the user concepts we need
14:41:20 <bauzas> johnthetubaguy: any user SLA should be part of the discussion IMHO - flavors and hints
14:41:28 <n0ano> lxsli, don't worry, I certainly have no intention of proposing a solution, I don't know what it is yet
14:41:36 <johnthetubaguy> lxsli: yeah, same difference
14:41:53 <johnthetubaguy> so summary, don't wait for me to start an ML thread, just go for it
14:42:12 <n0ano> johnthetubaguy, tnx, I'll just touch base with jay and then do something
14:42:35 <johnthetubaguy> I think we will have a better discussion if we focus on the user, and ignore the solution for now, and keep that conversation separate for now
14:42:41 <johnthetubaguy> I think thats all
14:42:48 <bauzas> yup
14:42:50 <bauzas> totally
14:42:53 <n0ano> #action n0ano to start ML on host capabilites after talking to jay
14:43:04 <n0ano> I think we're all in violent agreement
14:43:18 <bauzas> I was thinking Jay was in Florida, not in Bermudas :p
14:43:20 <johnthetubaguy> n0ano: +1
14:43:23 <lxsli> moving on?
14:43:29 <bauzas> hell yeah
14:43:36 <n0ano> lxsli, maybe
14:43:40 <n0ano> #topic opens
14:43:44 <bauzas> I got one
14:43:46 <n0ano> anything new for today
14:43:47 <lxsli> me too
14:43:48 <bauzas> bugs !
14:43:50 <n0ano> bauzas, go for it
14:44:08 <n0ano> bauzas, any specific ones or just in general
14:44:12 <bauzas> soooo, just to offtouch something to markus_z
14:44:23 <markus_z> present
14:44:25 <bauzas> the thoughts are
14:44:30 <bauzas> we know we have bugs
14:44:35 <bauzas> for the scheduler, we have 23
14:44:51 <bauzas> which is fairly decent
14:44:52 <bauzas> https://bugs.launchpad.net/nova/+bugs?field.tag=scheduler
14:44:52 <lxsli> I should fix some bugs
14:45:04 <bauzas> the idea is not to *fix* bugs
14:45:17 <lxsli> I can make new ones too!
14:45:23 <bauzas> but rather to see how to help markus_z with following the bugs
14:45:23 <markus_z> :)
14:45:44 <markus_z> bauzas: You mainly use the "scheduler" tag, right?
14:45:47 <bauzas> what I pretty appreciate is the Critical bugs review we do during Nova meetings
14:45:48 <n0ano> markus_z, is working on all 23 bugs?
14:45:54 <johnthetubaguy> making sure we advertise the bugs with good fixes to the core team, would be good
14:46:27 <bauzas> what I would like to see is how, as a subteam, we could leverage bugtracking at least for our component
14:46:53 <bauzas> ie. identify new high severity bugs, identify ones without assignees
14:46:53 <johnthetubaguy> its kinda covered here, BTW https://wiki.openstack.org/wiki/Nova/BugTriage
14:47:07 <n0ano> what johnthetubaguy said
14:47:10 <bauzas> and weekly review the ones
14:47:24 <bauzas> well, you should see a known name in there
14:47:28 <n0ano> bauzas, we can certainly add bugs as an ongoing agenda item
14:47:32 <johnthetubaguy> now I would love you to highlight stuff that needs review, and stuff that not being worked here, that sounds awesome
14:47:37 <bauzas> n0ano: that was my thoughts
14:47:38 <johnthetubaguy> cools
14:48:02 <n0ano> #action n0ano to add bugs as an ongoing agenda item to this weekly meeting
14:48:06 <johnthetubaguy> I know it doesn't work yet, but I am still wanting to push this: https://etherpad.openstack.org/p/liberty-nova-priorities-tracking
14:48:16 <johnthetubaguy> I hope that helps your patches get wider attention
14:48:25 <bauzas> okay, markus_z feel free to bug us during our weekly meetings if you need help on that specific area
14:48:38 <bauzas> markus_z: either triaging, reviewing, or owning
14:48:40 <markus_z> I've seen teams which "star" some of the reviews to focus attention on them
14:48:42 <n0ano> johnthetubaguy, I thought that was the way to get attention, is there another technique
14:48:48 <edleafe> markus_z: and feel free to ping me anytime
14:49:06 <markus_z> bauzas: edleafe: Thanks, I'll do that!
14:49:28 <bauzas> edleafe: I'd rather prefer something more conventional unless urgent queries
14:49:30 <n0ano> anyway, lxsli you had something
14:49:33 <johnthetubaguy> n0ano: its not really changed, just reminding really, good bug triage and adding things in the appropriate bit here: https://etherpad.openstack.org/p/liberty-nova-priorities-tracking
14:49:50 <n0ano> johnthetubaguy, got it
14:50:01 <bauzas> johnthetubaguy: yeah, what is changing now is that we assume that we can create bugs
14:50:26 <edleafe> bauzas: I don't think he needs to wait for a weekly meeting
14:50:33 <lxsli> n0ano: so I realise scheduler split is long-term but it's becoming increasingly clear we have no agreement on what that means and I think it's helpful to know if you're going east or west
14:50:46 <bauzas> oh man, 10 mins for that ?
14:50:51 <lxsli> n0ano: IE are we aiming for a holistic (pan-OpenStack) scheduler?
14:50:52 <edleafe> bauzas: hehe
14:50:57 <lxsli> think fast
14:51:16 <bauzas> should I rage-quit ? :)
14:51:25 <lxsli> show of hands? yes or no
14:51:26 <n0ano> lxsli, let's table this until next week, we don't have time and we really need jay online for this
14:51:42 <johnthetubaguy> lxsli: I was trying to write things up here: https://review.openstack.org/#/c/192260/
14:51:55 <lxsli> johnthetubaguy: yeah I put a few comments
14:52:02 <bauzas> are we putting a ballot on what we think on the Scheduler future ? sounds very Greek to me
14:52:04 <lxsli> bauzas put a few more
14:52:31 <bauzas> I thought we had an agreement :)
14:52:32 <lxsli> not binding, just to get an idea where we are
14:52:44 <bauzas> http://lists.openstack.org/pipermail/openstack-dev/2015-March/060179.html
14:53:01 <edleafe> lxsli: and I'll be writing up my ideas on changing the scheduler design
14:53:10 <bauzas> what we target mid-term is possibly a scheduler split - but not yet agreed on that
14:53:37 <lxsli> yeah we can clean up interfaces but at some point we need to agree on holistic or not
14:53:41 <bauzas> what we would certainly target mid-term is some way to schedule an instance based on non-nova affinity
14:53:50 <lxsli> you may have had that discussion previously and all agreed, but it certainly doesn't seem like it
14:54:08 <bauzas> what we haven't yet discussed is long-term, ie. a new project for scheduling more than just a VM
14:54:25 <bauzas> I certainly didn't signed-off for Gantt now
14:54:39 <edleafe> lxsli: the only thing we really agreed on is that the split would not drive the work; cleaning up the interfaces would
14:54:50 <edleafe> lxsli: the split may then happen, or it may not
14:54:56 <bauzas> edleafe: exactly
14:54:59 <n0ano> guys, no time, let's discuss this later
14:55:10 <lxsli> OK well that was helpful to me at least
14:56:02 <n0ano> OK, I need some time to prepare for my next meeting (not looking foward to that one)
14:56:10 <bauzas> what I want to stress on is the paradigm of booting an instance
14:56:26 <bauzas> if booting an instance, that sounds very Nova to me
14:56:41 <lxsli> I'd say making a claim is the key to a resource-allocator API
14:56:52 <lxsli> after that, use it or not it's all the same
14:57:39 <n0ano> gotta go, tnx everyone, we'll talk next week (if not before)
14:57:44 <n0ano> #endmeeting