14:00:05 <edleafe> #startmeeting nova_scheduler
14:00:06 <openstack> Meeting started Mon Jul 11 14:00:05 2016 UTC and is due to finish in 60 minutes.  The chair is edleafe. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:09 <openstack> The meeting name has been set to 'nova_scheduler'
14:00:17 <edleafe> anyone here to talk about the scheduler?
14:00:18 <_gryf> o/
14:00:19 <alex_xu> o/
14:00:23 <Yingxin> o/
14:00:36 <mlavalle> o/
14:01:14 <edleafe> Let's wait another minute
14:01:14 * bauzas refuels coffee with one hand and waves with the other
14:01:31 <woodster_> o/
14:01:39 <edleafe> bauzas: terrible ending yesterday, no?
14:02:34 <bauzas> edleafe: graaah
14:02:56 <jaypipes> morning everyone sorry for being late (in US west coast time zone for this and next week)
14:03:18 <edleafe> jaypipes: good segueway...
14:03:30 <edleafe> #topic Skip next week's meeting?
14:03:43 <edleafe> Many will be en route to the midcycle
14:03:45 * mriedem lurks
14:03:50 * edleafe included
14:04:02 <edleafe> Of course, someone else could run the meeting
14:04:08 <edleafe> or we could just skip it
14:04:13 <edleafe> thoughts?
14:04:22 <bauzas> ++
14:04:27 <bauzas> +1 for skippinh
14:04:49 <mriedem> most meetings will skip next week, if not all
14:04:57 <jaypipes> edleafe: yeah, skip that one I think.
14:05:34 <edleafe> #agreed Skip next week's meeting
14:05:38 <edleafe> Moving on
14:05:51 <edleafe> #topic Mid-cycle discussions
14:06:08 <edleafe> The only new one is Nested Resource Providers
14:06:11 <edleafe> #link https://etherpad.openstack.org/p/nested-resource-providers
14:06:26 <edleafe> jaypipes: anything to say about that now?
14:06:33 <edleafe> Or should we save it for F2F?
14:07:36 * edleafe realizes that was supposed to be in 'Opens'.
14:07:50 <bauzas> well, f2f is good to me
14:08:13 <bauzas> given we could first discuss on the current implementations and see where we are before discussing on the next items
14:08:15 <mriedem> midcycle etherpad is here for reference https://etherpad.openstack.org/p/nova-newton-midcycle
14:08:25 <jaypipes> edleafe: f2f
14:08:35 <mriedem> i expect a lot of discussion at the midcycle will be about what needs to get done in newton,
14:08:37 <mriedem> like the placement api
14:08:40 <edleafe> #link https://etherpad.openstack.org/p/nova-newton-midcycle
14:08:49 <edleafe> mriedem: yeah
14:08:52 <mriedem> and looking toward host capabilities for ocata
14:09:28 <edleafe> The other was Separating qualitative requirements from quantitative in a request
14:09:31 <edleafe> #link https://review.openstack.org/313784
14:09:59 <edleafe> That I think ties into alex_xu's post:
14:10:01 <edleafe> ResourceProviderTags
14:10:01 <edleafe> #link http://lists.openstack.org/pipermail/openstack-dev/2016-July/099032.html
14:10:09 <alex_xu> edleafe: thanks
14:10:17 <jaypipes> mriedem: I'm preparing content for next week to discuss all those things as well as the Ironic aspects of the resource-providers work and nested resource providers (which handle the NUMA stuff)
14:10:31 <jaypipes> edleafe: ++
14:10:45 <alex_xu> I and Yingxin works on this propose, as part of solution for Capabilities. Propose using Tags to manage Capabilities with ResourceProvider
14:11:02 <jaypipes> mriedem: got alaski, cdent, tdurakov and rpodolyaka here in CA this week for a sprint.
14:11:16 <jaypipes> mriedem: we will all be up in Hillsboro next week
14:11:26 <jaypipes> alex_xu: ++
14:11:26 <edleafe> Cool, so let's make sure that we are familiar with the issues before we meet
14:11:42 <jaypipes> edleafe: agreed. lots of reading and writing to do this week.
14:11:48 <edleafe> jaypipes: would be happy to help review / add to content before midcycle
14:11:51 <alex_xu> jaypipes: looking for your comment :)
14:12:21 <bauzas> alex_xu: I did read your proposal, looks interesting
14:12:23 <Yingxin> yes, the main idea is to manage capabilities under the scope of resource providers
14:12:24 <mriedem> jaypipes: if you want everyone to level set before the midcycle, i'd suggest a ML info thread later in the week
14:12:25 <jaypipes> edleafe, mriedem: before Thursday, I will send a ML post with summary of latest resource-providers (quantitative) progress. Can you do same for qualitative side?
14:12:32 <alex_xu> bauzas: thanks
14:12:36 <jaypipes> mriedem: heh, beat me to it :)
14:12:37 <mriedem> jaypipes: you read my mind
14:12:58 <jaypipes> mriedem: yeah, will do that after some meetings today
14:13:02 <edleafe> jaypipes: sure. I'll coordinate with alex_xu
14:13:12 <bauzas> jaypipes: alex_xu made a nice proposal about using the existing resource_providers API for the qualitative resources too
14:13:16 * johnthetubaguy looks forward to the email
14:13:30 <jaypipes> mriedem: I finally figured out NUMA resources and modeling all that jazz while in the shower this morning (yes I know, weird...)
14:13:31 <bauzas> devil is in the details of course, but I like the idea
14:13:34 <_gryf> jaypipes, the NUMA case is similar to FPGA case - where whole FPGA can be resoucre, and accelerator which it contains might be one at the same time
14:13:39 <edleafe> #action jaypipes to post summary of resource provider state later this week
14:13:42 <alex_xu> edleafe: cool
14:14:07 <edleafe> #action edleafe and alex_xu to post to ML about qualitative status
14:14:11 <jaypipes> bauzas: is that the ResourceProviderTags proposal?
14:14:24 <bauzas> indeed
14:14:51 <alex_xu> I and Yingxin will try to work on the spec and work out more detail, to figure out more devil :)
14:14:53 <jaypipes> _gryf: perhaps, will continue to thnk about the FPGA action plans in relation to resource providers.
14:15:00 <mriedem> aren't resource providers made of aggregates which have metadata (tags)?
14:15:03 <jaypipes> bauzas: cool, will read today.
14:15:24 <bauzas> basically, a resource provider can expose tags
14:15:27 <jaypipes> alex_xu: link to that patch?
14:15:47 <alex_xu> jaypipes: we didn't have spec yet, just about email http://lists.openstack.org/pipermail/openstack-dev/2016-July/099032.html
14:15:58 <jaypipes> gotcha
14:16:00 <_gryf> jaypipes, I can share with you what I already know, although I'm not going to participate midcycle…
14:16:28 <jaypipes> _gryf: sounds good. or better yet email the ML and get the conversation going there, yeah?
14:16:30 <alex_xu> mriedem: yea, but aggregate for a group host
14:16:42 <_gryf> jaypipes, yup, that would be great
14:16:53 <jaypipes> _gryf: or pass on info to pawel who I will see on Friday in Portland ;)
14:16:55 <bauzas> _gryf: well, I would certainly wait for a bit of the resource providers infrastructure in place before including FPGA, tbh
14:16:57 <alex_xu> mriedem: and aggregate metadata is not very easy to manage
14:17:06 <_gryf> jaypipes, I will :)
14:17:43 <jaypipes> _gryf: no, really, an ML post would be better :)
14:18:20 <Yingxin> mriedem: that means if we want to attatch a capability to a host, we don't need to create a host aggregate
14:18:54 <_gryf> bauzas, that's the plan, but I'd like to be sure, that we don't close for "special cases".
14:19:10 <bauzas> _gryf: gotcha
14:19:11 <edleafe> Yingxin: yeah, aggregates of 1 don't make a lot of sense :)
14:19:14 <alex_xu> Yingxin: ++
14:19:28 <_gryf> jaypipes, sure.
14:19:29 <mriedem> so would we have resource providers of 1?
14:19:31 <Yingxin> yup, we can also attatch a capability directly to a resource pool
14:19:36 <jaypipes> One-man Wolfpack.
14:19:50 <mriedem> i'll just shut up and read specs eventually
14:19:57 <jaypipes> mriedem: lol
14:20:08 <edleafe> mriedem: sure. A host is a RP of RAM, CPU, disk, etc
14:20:12 <jaypipes> BTW, alex_xu and Yingxin will you be in Portland?
14:20:27 <jaypipes> edleafe: not necessarily disk ;)
14:20:27 <alex_xu> i will be there.
14:20:34 <mriedem> well,
14:20:46 <mriedem> there are a class of things i'd expect the virt driver and nova to provide as capabilities, not the operator
14:20:51 <mriedem> e.g. i support file injection
14:20:52 <edleafe> better yet: who here will *not* be at the midcycle?
14:20:52 <Yingxin> I'm supporting him in china :)
14:20:59 <jaypipes> mriedem: yep, zactly.
14:21:05 <alex_xu> Yingxin: :)
14:21:06 <jaypipes> Yingxin: ok! :)
14:21:08 <mriedem> e.g. i support volume multiattach, or device tagging
14:21:18 <mriedem> ok
14:21:18 <johnthetubaguy> mriedem: yeah, more auto configuring of somethings is going to be really handy
14:21:27 <_gryf> edleafe, i'm not going to participate in midcycle
14:21:45 <jaypipes> mriedem: yep, those are the "standardized" host capabilities I refer to in this spec: https://review.openstack.org/#/c/309762/
14:22:00 <diga_> edleafe: sorry, got late
14:22:04 <jaypipes> mriedem: of course, there's many more non-standardized capabilities, as edleafe would remind you ;)
14:22:18 <edleafe> jaypipes: :)
14:22:31 <johnthetubaguy> I am not sure if I will be there yet (to be precise, I have nothing booked yet), still hoping I can get passport etc sorted in time
14:22:41 <jaypipes> johnthetubaguy: :(
14:22:50 <edleafe> johnthetubaguy: ugh.
14:23:15 <johnthetubaguy> yeah, getting messed around by house builders too, but slowly getting sorted
14:23:31 <bauzas> oh grah
14:24:12 * johnthetubaguy makes secret British anger face
14:24:44 <mgould> johnthetubaguy: that's indistinguishable from normal British face, right? :-)
14:25:02 <mgould> <- is British
14:25:15 <johnthetubaguy> mgould: possibly slightly different eyebrows I guess?
14:25:36 <bauzas> johnthetubaguy: I wasn't expecting the Brexit to apply so fast :p
14:25:58 <edleafe> OK, anything else we need to discuss in advance of the midcycle?
14:25:58 <jaypipes> hahaha
14:26:02 <johnthetubaguy> bauzas: heh
14:26:10 <jaypipes> edleafe: not from my end.
14:26:25 <bauzas> nothing urgent to review ?
14:26:38 <bauzas> I'm still in the weeds of reviewing the placement API
14:26:46 <mriedem> i was going to say, placement API
14:26:49 <edleafe> bauzas: nothing added to the agenda
14:26:55 <mriedem> i only spent some time on that a couple of weeks ago
14:27:15 * mgould would like to ask about extra_specs matching; should I wait for AOB?
14:27:19 <mriedem> but if we're going to have a placement API in newton, we should make sure we're happy with what cdent has proposed by the time we leave the midcycle
14:27:31 <johnthetubaguy> mriedem: +1
14:27:33 <bauzas> yeah, and having the placement a bit different from the other bits I know makes my review time a bit longer :)
14:27:50 <bauzas> but I guess, no surprise here :)
14:28:15 <bauzas> mriedem: that's why I'm tempted to only review the bits and make sure we can fast iterate during the sprint if needed
14:28:20 <edleafe> mgould: Opens is next
14:28:22 <bauzas> I'd certainly love some consensus on those bits
14:28:32 <mgould> edleafe: thanks!
14:28:44 <edleafe> bauzas: yeah, I have the same issue
14:28:55 <bauzas> triggering +W on such huge changes like a whole new WSGI stack is chilling me
14:29:12 <edleafe> bauzas: I'm assuming that it won't be perfect on the first try. :)
14:29:25 <bauzas> yeah, but that's an API, right ? :)
14:29:36 <johnthetubaguy> microversions FTW
14:29:39 <edleafe> bauzas: the good thing is that it's not in use yet, so we won't break anything
14:29:40 <bauzas> like the ones we contractually assume as being stable ? :)
14:30:03 <bauzas> sure, I'm not saying it's impossible, just that's it's a big event :)
14:30:15 <edleafe> Can we start with microversion 0.1, indicating that it *isn't* stable yet?
14:30:26 <bauzas> do we have the framework for this ?
14:30:36 <johnthetubaguy> I think while its an internal API, I feel happier about raising the min_version of the placement API, wibble upgrade worries
14:31:21 <jaypipes> mgould: let's discuss that in #openstack-nova after meeting, yeah?
14:31:36 <edleafe> jaypipes: cool
14:31:40 <edleafe> Let's move on
14:31:42 <mgould> jaypipes: sure, thanks
14:31:47 <edleafe> #topic Opens
14:31:56 <edleafe> Other services directly accessing the Scheduler and/or request database
14:31:59 <edleafe> Watcher has updated their spec for integrating with Nova:
14:32:01 <edleafe> #link https://review.openstack.org/#/c/329873
14:32:08 <edleafe> Other services directly accessing the Scheduler and/or request database
14:32:11 <edleafe> Watcher has updated their spec for integrating with Nova:
14:32:13 <edleafe> #link https://review.openstack.org/#/c/329873
14:32:24 * edleafe fails copy/paste
14:32:40 <edleafe> They plan to submit a Nova backlog spec before the midcycle
14:32:40 <edleafe> We need to clarify the projected availability of the Placement API, and strategies to use until that is available.
14:33:02 <edleafe> Anyone from Watcher here to add to this?
14:33:16 <acabot_> Watcher will have its midcycle in Hillsboro next week
14:33:32 <edleafe> Yep, same time and place as Nova
14:33:53 <bauzas> not the same building tho
14:34:08 <acabot_> we hope to discuss with you guys about this spec
14:34:31 <mriedem> honestly i want to spend a very minimal amount of time in hillsboro talking about this
14:34:33 <jaypipes> edleafe: honestly, I can try to get to reading that Watcher spec but its going to be a stretch.
14:34:38 <acabot_> it would be great that you had a look to this before the midcycle
14:35:08 <edleafe> wow, two "honestly" replies :)
14:35:17 <mriedem> honestly for serious
14:35:21 <acabot_> mriedem : do you think we could submit a Nova backlog spec instead of this ?
14:35:30 <mriedem> but we could spend all of tuesday about scheduler and RP
14:35:39 <bauzas> oh gosh
14:35:49 <acabot_> I dont want to take your midcycle time, just trying to find a way to explain our issue
14:35:51 <bauzas> spending one full day about scheduler <3
14:35:52 <mriedem> acabot_: submit whatever for review, but i'm just saying, we already have a full list for next week https://etherpad.openstack.org/p/nova-newton-midcycle
14:35:55 <jaypipes> edleafe: they need the placement API not only to expose all the resource providers stuff (our current Newton priority) but also to have it offer a select_destinations() replacement. That ain't gonna happen in Newton for sure.
14:35:59 <mriedem> and a lot that's not close to getting done for newton
14:36:05 * edleafe thought we would spend all three days on scheduler and RP :)
14:36:09 * bauzas was ironic
14:36:32 <mriedem> we also have cinder/neutron stuff on wednesday, and i figured a hodge podge on thursday
14:36:48 <acabot_> mriedem : no pb, I fully understand
14:36:49 <jaypipes> mriedem: isn't scheduelr a hodge-podge? ;P
14:36:53 <mriedem> anyway, my point is, i don't want the watcher spec to be a distraction for newton
14:36:59 <edleafe> jaypipes: oh, for sure. The big question is the guesstimate of when a placement API for that would be available
14:37:17 <mriedem> edleafe: we won't know that until after the midcycle probably
14:37:18 <jaypipes> edleafe: you know how I feel about guestimates :)
14:37:20 <acabot_> mriedem : its definitely not a newton priority by the way ;-)
14:37:25 <bauzas> mriedem: well, I wouldn't certainly hope more than just a brief discussion on the Watcher issue, but a short overlook would be interesting tho
14:37:45 <mriedem> bauzas: sure, unconference at the midcycle
14:37:54 <bauzas> mriedem: that sounds good to me
14:37:56 <acabot_> bauzas : +1
14:38:00 <bauzas> a perfect slot for this
14:38:01 <edleafe> mriedem: yeah, unconference sounds right
14:38:20 <jaypipes> acabot_: I can be bribed with cookies. just FYI.
14:38:25 <acabot_> mriedem : any agenda available for unconference ?
14:38:29 <jaypipes> acabot_: and bauzas can be bribed with cheese.
14:38:39 <edleafe> acabot_: Or sushi. jaypipes LOVES sushi
14:38:41 <acabot_> jaypipes : ;-)
14:38:44 <jaypipes> lol
14:38:49 <mriedem> acabot_: no, i wasn't being literal about unconference
14:38:53 <mriedem> our etherpad of items is here https://etherpad.openstack.org/p/nova-newton-midcycle
14:38:59 <acabot_> sushi, cheese and sushi would be great !
14:39:03 <mriedem> we do loose scheduling of the agenda for the midcycle
14:39:08 <mriedem> which is the beauty of a midcycle
14:39:35 <acabot_> mriedem : thx
14:39:46 <edleafe> Next up
14:39:55 <edleafe> mgould: extra_specs matching?
14:40:31 <mgould> oh, I thought we were discussing that in the normal channel afterwards
14:40:38 <mgould> but I can ask now
14:40:46 <edleafe> go for it
14:41:30 <mgould> comments in the implementation suggest <all-in> should match capabililties which are lists
14:41:44 <bauzas> I think mgould wants to discuss about http://lists.openstack.org/pipermail/openstack-dev/2016-July/098936.html
14:41:47 <mgould> I've proposed patches to test this
14:41:49 <mgould> yes, exactly
14:42:09 <bauzas> honestly, that sounds an implementation detail, but I could be wrong
14:42:12 <mgould> since then, rloo found places in nova wehre the argument is force-stringified before matching
14:42:20 <mgould> which means you get substring matching rather than sublist matching
14:42:29 <mgould> this is a bug, right?
14:42:32 <bauzas> mgould: so the thing is, you want to define an oslo lib, right?
14:42:40 <mgould> see final coment on https://review.openstack.org/#/c/339596/
14:42:43 <mgould> bauzas: yes
14:43:01 <mgould> the oslo.lib people are saying "this doesn't enforce input types, we don't like it"
14:43:12 <bauzas> mgould: so, my take on this is that yes, strings as arguments are doom
14:43:19 <bauzas> mgould: for a lib
14:43:29 <mgould> OK
14:43:37 <mgould> but within nova, you don't care?
14:44:01 <bauzas> mgould: given we only have a few callers, it's certainly a nice move, but not really useful
14:44:17 <mgould> see also https://github.com/openstack/nova/blob/90ec46c87fbf572805c7758377431e26c93622a4/nova/scheduler/filters/compute_capabilities_filter.py#L87, which stringifies the capability, giving substring matching
14:44:37 <bauzas> mgould: I'm pretty sure you could clean that up :)
14:44:43 <mgould> OK
14:44:57 <edleafe> mgould: yeah, that looks wrong
14:45:01 <bauzas> mgould: but like I said, here I think you should focus on the lib
14:45:01 <mgould> I'll submit a patch to fix that, then
14:45:23 <mgould> right, OK
14:45:30 <edleafe> Any other opens?
14:45:43 <jaypipes> mgould: I will respond on the ML thread. need to read your proposal fully...
14:45:50 <mgould> jaypipes: thanks!
14:45:54 <Yingxin> jaypipes: bauzas: Is there still a plan to move the claims from RTs to schedulers？
14:46:08 <bauzas> Yingxin: ssssssht :p
14:46:31 <Yingxin> I'm still thinking of the bp eventually-consistent stuff
14:46:44 <alex_xu> Yingxin: :)
14:46:52 <bauzas> Yingxin: there are patches up for having contextmanagers (call it "claims' if you will) in the scheduler codepath
14:46:53 <jaypipes> Yingxin: yes. :)
14:46:57 <Yingxin> And there's a long post in ML :P
14:47:11 <jaypipes> bauzas: which patches are those?
14:47:25 <jaypipes> Yingxin: I saw your post, haven't had a chance to digest it yet :(
14:47:31 <bauzas> jaypipes: sec
14:48:17 <bauzas> jaypipes: but that's not the idea of "claiming a resource', that's just for making sure we have a correct infrastructure for distributed writes on a synchronized section
14:48:59 <Yingxin> bauzas: which patch is it?
14:49:01 <bauzas> https://review.openstack.org/#/c/262938/
14:49:08 <bauzas> no real surprise
14:49:53 <Yingxin> bauzas: thanks
14:50:07 <edleafe> OK, anything else?
14:50:15 <jaypipes> Yingxin: I added a block on the eventual consistent and scheduler claims thing to the agenda. Long-term discussion...
14:50:24 <bauzas> yup, I agree
14:50:55 <bauzas> (on putting it to the agenda if we have time and if mriedem is not killing us for eating all the time)
14:51:11 <Yingxin> bauzas: oh that's also my patch
14:51:21 <bauzas> Yingxin: hence my "no surprise here"
14:51:45 <jaypipes> hehe
14:52:45 <bauzas> if we're done with this, I'd like to advocate for a long-standing patch
14:53:11 <bauzas> I'd love some reviews with https://review.openstack.org/#/c/244489/
14:53:30 <bauzas> before calling out of moving claims, we need to make sure we do claim on
14:53:36 <bauzas> *all* our operations
14:53:42 <bauzas> which is not the case atm, see ^
14:53:56 <mriedem> that reminds me
14:54:05 <mriedem> moshele has a thread in the dev list about cleaning up some RT stuff for pci/sriov
14:54:06 <bauzas> jaypipes, mriedem: I'd love some feedback on this ^
14:54:14 <mriedem> so they can get a multinode job going for resize with sriov/pci
14:54:24 <bauzas> mriedem: that's certainly a good idea :)
14:54:44 <mriedem> just a reminder though, i haven't dug into it - i reviewed one of the patches awhile back
14:54:51 <bauzas> the "if pci:" idea wasn't probably the best idea we had
14:54:53 <mriedem> also reminder that non-priority FFE is wednesday
14:55:07 <mriedem> for the things that got FFEs
14:55:13 <mriedem> that's a reminder to the cores here
14:55:37 <bauzas> :)
14:55:38 <edleafe> 5 minutes
14:55:45 <edleafe> Anythign else?
14:56:11 <diga_> edleafe: I have setup ready, anything I can test
14:56:22 <diga_> Yingxin: https://github.com/cyx1231st/nova-scheduler-bench used for setup
14:56:38 <diga_> Yingxin: thanks for your help
14:56:58 <Yingxin> diga_: np! does it work?
14:57:05 <jaypipes> bauzas: ++ will do this mronig.
14:57:09 <jaypipes> guh, morning.
14:57:13 <diga_> 4th script is not working for me
14:57:29 <diga_> need some changes in that
14:57:42 <diga_> will ping error after this meeting
14:57:50 <Yingxin> diga_: we can discuss it in openstack-nova later
14:58:00 <diga_> sure
14:58:05 <edleafe> OK, looking forward to seeing most of you in Hillsboro next week!
14:58:09 <edleafe> #endmeeting