14:00:10 <edleafe> #startmeeting nova_scheduler
14:00:11 <openstack> Meeting started Mon Mar 19 14:00:10 2018 UTC and is due to finish in 60 minutes.  The chair is edleafe. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:15 <openstack> The meeting name has been set to 'nova_scheduler'
14:00:23 <edleafe> Who's here this lovely UGT morning?
14:00:25 <efried> @/
14:00:33 <cdent> o/
14:00:38 <alex_xu_> o/
14:00:45 <edleafe> efried: comb your hair!
14:00:47 <tssurya> o/
14:01:01 <ttsiouts> o/
14:01:11 <mriedem> o/
14:01:23 <jaypipes> o/
14:02:03 <edleafe> Let's get to it
14:02:05 <edleafe> #topic Specs
14:02:13 <edleafe> Several merged this past week
14:02:25 <edleafe> Here are the ones still awaiting reviews
14:02:37 <edleafe> #link VMware: place instances on resource pool (using update_provider_tree) https://review.openstack.org/#/c/549067/
14:02:40 <edleafe> #link Spec: report client placement version discovery https://review.openstack.org/#/c/549184/
14:02:43 <edleafe> #link Update placement aggregates spec to clarify generation handling https://review.openstack.org/#/c/548237/
14:02:46 <edleafe> #link Provide error codes for placement API https://review.openstack.org/#/c/418393/
14:02:49 <edleafe> #link mirror nova host aggregates to placement API https://review.openstack.org/#/c/545057/
14:02:52 <edleafe> #link Support traits in Glance https://review.openstack.org/#/c/541507/
14:02:55 <edleafe> #link Network bandwidth resource provider https://review.openstack.org/#/c/502306/
14:03:03 <edleafe> Are there any that anyone wants to discuss?
14:03:21 <jaypipes> default allocation ratios is missing...
14:03:30 <edleafe> is that new?
14:03:32 <jaypipes> #link https://review.openstack.org/#/q/status:open+project:openstack/nova-specs+branch:master+topic:bp/default-allocation-ratios
14:03:40 <edleafe> wasn't on the agenda
14:03:52 <jaypipes> yeah, sorry, forgot to put it on there.
14:04:04 <edleafe> no worries; I'll add it
14:04:08 <jaypipes> cheers
14:04:15 <mriedem> "Support traits in Glance https://review.openstack.org/#/c/541507/" is merged
14:04:39 <mriedem> one question for the group,
14:04:44 <mriedem> on "mirror nova host aggregates to placement API https://review.openstack.org/#/c/545057/"
14:04:59 <jaypipes> alex_xu_ hates that spec :)
14:05:00 <mriedem> you know how we did a whole proxy API witch hunt in newton?
14:05:17 <mriedem> is it just me or does that feel proxy API-ish?
14:05:33 <alex_xu_> heh:)
14:05:49 <edleafe> it's just you
14:05:57 <edleafe> :)
14:06:02 <jaypipes> mriedem: it's the same as inventory and allocation information, no?
14:06:15 <jaypipes> mriedem: I mean, we mirror that information now and use it in the scheduler calls
14:06:20 <mriedem> not really,
14:06:25 <alex_xu_> edleafe: yea, just follow my heart to say something :)
14:06:37 <mriedem> admin sets host aggregates via the compute API, and we're going to mirror / proxy those to placement
14:06:37 <jaypipes> mriedem: ? we still have allocation and inventory information in all the cell DBs. and we mirror it all over to placement.
14:06:57 <mriedem> if a user came to nova to create a volume, we use to proxy that through to cinder,
14:06:59 <mriedem> or a floating IP
14:07:08 <mriedem> we stopped doing that in newton because we said proxies from the compute API were bad
14:07:33 <mriedem> i'm just trying to feel out if this is the same kind of thing, but we are more comfortable with it because placement is so "owned by nova" right now
14:08:25 <mriedem> anyway, just wanted to mention it
14:08:53 <alex_xu_> nova aggregate API proxy to the placement aggregate API :)
14:08:57 <cdent> I feel you mriedem and alex_xu_
14:09:31 <jaypipes> mriedem: the placement API doesn't yet have the kind of policy controls as the compute API... so if we were to stop storing nova host aggregate information in the Nova database and instead deprecated that API endpoint and forced people to use the placement API directly, that would be a functional gap in the RBAC. in addition, nova host aggregates have metadata associated with them, and placement aggregates do not.
14:09:43 <edleafe> the difference, of course, is that the concept of aggs exists and is used in both nova and placement
14:09:57 <edleafe> "proxy" implies simple passthrough
14:10:06 <mriedem> i'm not suggesting that we long-term replace nova host aggregates with placement aggregates
14:10:12 <mriedem> or that this is trying to do that
14:10:38 <mriedem> i understand the usefulness of this
14:10:56 <mriedem> just wondering if 2 years down the road it's going to be a pain in the ass for some reason because we are doing that automatic mirroring
14:11:37 <jaypipes> mriedem: I'm not going to say that in 2 years, all of this won't be annoying as hell.
14:11:48 * jaypipes fills quota on double negative talk
14:11:56 <edleafe> jaypipes: it *is* nova, after all. :)
14:12:06 <mriedem> we can move on
14:12:20 <edleafe> ok, further comments go on the spec
14:12:27 <edleafe> Any other specs to discuss?
14:12:34 <diga> \o
14:12:41 <mriedem> sylvain had some numa thing
14:12:56 <mriedem> https://review.openstack.org/#/c/552924/ but he's not here
14:13:16 <edleafe> mriedem: thanks - I'll add that to the agenda
14:14:00 <jaypipes> is bauzas out this week?
14:14:06 <mriedem> for a couple of days
14:14:09 <jaypipes> k
14:14:10 <mriedem> today and tomorrow?
14:14:22 <mriedem> plus mandatory french post-vacation vacation
14:15:06 <edleafe> With that, let's move on to...
14:15:08 <edleafe> #topic Reviews
14:15:30 <edleafe> #link Update Provider Tree https://review.openstack.org/#/q/topic:bp/update-provider-tree
14:15:33 <edleafe> #link Request Filters https://review.openstack.org/#/q/topic:bp/placement-req-filter
14:15:36 <edleafe> #link Mirror nova host aggregates to placement https://review.openstack.org/#/q/topic:bp/placement-mirror-host-aggregates
14:15:39 <edleafe> Forbidden Traits Not yet started.
14:15:42 <edleafe> Consumer Generations Not yet started.
14:15:44 <edleafe> #link Extraction http://lists.openstack.org/pipermail/openstack-dev/2018-March/128004.html
14:16:13 <edleafe> Anything on these patches to discuss?
14:16:14 <efried> We have a bp for extraction now (but no spec yet, right cdent?)
14:16:34 <cdent> there is a spec, it is linked from last week's placement update
14:16:44 <cdent> does that actually get read before this meeting?
14:17:08 <cdent> https://review.openstack.org/#/c/552927/
14:17:10 <edleafe> cdent: most of the time, but I started slow this morning
14:17:21 <efried> Can you set the spec URL in the bp please?
14:17:34 <cdent> efried: I always that that link was for the spec once published?
14:17:47 <efried> Not sure how anyone else finds these things, but that's how I do it.
14:17:51 <cdent> the proposed spec gets linked automatically on the white board
14:18:03 <efried> cdent: You can edit it after the fact to point to the approved spec (if you want).
14:18:05 <cdent> s/that that/thought that/
14:19:01 <edleafe> efried: the spec *is* linked in the BP
14:19:45 <mriedem> i'll do it
14:19:58 <efried> Personally, I prefer to see it where it says "Set the URL for this specification"
14:20:11 <mriedem> done
14:20:36 <efried> In the general case, where the whiteboard may be long, and the headline of the spec may not actually say "spec", it's just easier if that link is set.
14:20:41 <efried> Thanks mriedem :)
14:21:17 <efried> So cdent, we have multiple specs/bps for placement extraction?
14:21:36 <cdent> efried: mriedem wanted a specific spec for optional db handling
14:21:52 <cdent> prior to you then asking for there to be one for general extraction
14:22:04 * efried is such a PITA
14:22:10 <efried> https://blueprints.launchpad.net/nova/+spec/placement-extract is the one I was thinking of.
14:22:17 <efried> does *that* one have a spec?
14:22:49 <efried> ...don't see one.
14:22:54 <efried> Which is cool, just making sure.
14:23:08 * cdent is confused, one moment
14:23:59 <cdent> efried: there is a spec for optional db ness https://review.openstack.org/#/c/552927/ but thus far there is only a blueprint for placement extract
14:24:13 <efried> ack, that gels with my observations, thanks.
14:24:35 <cdent> as it says in the description the tasks associated with extraction are too diverse to easily spec in one spec
14:25:09 <jaypipes> cdent: don't hate me for this, but if I may be so bold, I would say that we merged a number of great patches around placement extraction already in Rocky (the moves of stuff in nova/api/openstack/placement and cleanup of the WSGI service stuff to remove dependencies. I'd rather table any further extraction work for this cycle and have you focus on the forbidden traits and/or consumer generation work.
14:25:32 <jaypipes> please don't hate me.
14:25:37 <edleafe> too late
14:25:39 <edleafe> :)
14:25:41 <jaypipes> :)
14:25:47 <cdent> jaypipes: I am going to focus on the forbidden traits soon, but I'm not going to otherwise stop
14:26:22 <cdent> I can't do the work that I need to do within anything like a reasonable (less than years) timetable if I don't keep going
14:26:49 <cdent> I can work on both and I hope that other people will be happy to review it
14:26:49 <jaypipes> cdent: ok. what is your goal for Rocky? the sep db one? or more than that?
14:27:04 <cdent> (and I don't hate you)
14:27:39 <cdent> sep db, moved tests, moved exceptions, moved db setup, os-resource-classes
14:27:42 <cdent> (at least)
14:28:27 <jaypipes> cdent: os-resource-classes is something I think would be useful separate from extraction (pun intended)
14:28:35 <cdent> sure
14:28:43 <efried> ++
14:29:14 <edleafe> jaypipes moves from double negatives to double extractions
14:30:11 * efried scrambles to come up with military and/or dental puns that aren't too obscure...
14:30:24 * efried fails
14:30:55 <edleafe> getting everyone aligned is like pulling teeth
14:31:57 <edleafe> ok, enough with the punning
14:32:04 <edleafe> Anything else for reviews?
14:32:07 <cdent> anyway, jaypipes forbidden is on my list for this week, once I wrote up all the k8s hoopa joop I did over the  weekend
14:32:39 <edleafe> And I plan on starting to work on the consumer generation stuff in the next couple of days
14:32:46 * edleafe shakes his fist at meetings
14:33:10 <jaypipes> edleafe: one more.
14:33:17 <edleafe> go for it
14:33:22 <jaypipes> #link https://review.openstack.org/#/c/534968/
14:33:39 <jaypipes> it's the HEAD of the patch series for supporting nested providers in allocation candidates.
14:34:00 <jaypipes> could use a look from folks. alex_xu_, efried and gibi have already added some comments
14:34:25 <jaypipes> obviously, it's a big one to get done in order for scheduler integration with nested providers...
14:34:53 * edleafe adds it to his TODO list
14:34:56 <efried> IMO, this series needs to be top priority for reviews.  Yeah, that ^  And other things, like granular, are also queued up behind it.
14:35:00 <cdent> ah, cool, I've been going back to that every other day or so, just to check
14:35:15 <jaypipes> cdent: yeah, just rebased it this morning.
14:35:22 <jaypipes> was in merge conflict for a while
14:35:52 <edleafe> jaypipes: the BP link on that comes up empty
14:36:28 <jaypipes> mriedem: do we need (yet another) nested-resource-providers-rocky spec?
14:37:12 <mriedem> don't ask me
14:37:15 <mriedem> melwitt: ^
14:38:03 <efried> jaypipes: Sorry to say this, but I think there's enough uncertainty/ambiguity in the exact semantics of the behavior that it would be worth having a spec.
14:38:10 <efried> The previous specs don't have the level of detail.
14:38:40 <mriedem> from what i remember,
14:38:50 <mriedem> the old NRP spec was mostly about the API interaction in placement, which was completed in queens,
14:39:11 <mriedem> so i'm not sure what a new spec would cover, i guess the changes to allocation_candidates and how the nova scheduler would interface?
14:39:16 <efried> The old one talked about the parent/root UUIDs and the ?in_tree business.
14:39:30 <jaypipes> the alloc candidates with nested stuff was primarily the result of multiple bugs filed by efried and gibi
14:39:31 <jaypipes> IIRC
14:39:32 <efried> Yes, the new one would talk about allocation_candidates, which (IIRC) wasn't discussed.
14:39:50 <mriedem> is there an API change?
14:39:54 <efried> Yes
14:39:54 <mriedem> if so, then spec
14:39:57 <jaypipes> I'll type up a spec with the primary use cases / scenarios
14:40:02 <jaypipes> mriedem: no API change, no
14:40:10 <jaypipes> mriedem: well, actually, yeah, there is.
14:40:19 <jaypipes> mriedem: in the response from alloc candidates.
14:40:23 <jaypipes> mriedem: I'll spec it up.
14:40:41 <jaypipes> in the meantime, reviews on that series would be welcome, just for ideas.
14:40:42 <efried> In the sense that, if you try to GET /allocation_candidates today with a tree, you get nothing in the response unless the resources happen to be in the same RP.
14:41:01 <efried> (or possibly also shared)
14:41:52 <efried> There's no change in the request or response syntax, afaik
14:42:00 <efried> just a matter of making a thing work that doesn't yet.
14:42:17 <mriedem> so it would be a behavior change
14:42:29 <efried> Yes.  Do The Rules require a microversion for that?
14:42:56 <cdent> if the result of request A used to get B and now gets C then that's a microversion
14:42:59 <mriedem> if it's a bug fix and since this is an admin api that only nova is using right now, honestly i don't care about a spec as long as the api usage/behavior is documented eventually
14:43:14 <jaypipes> efried: the response to allocation candidates provider_summaries will now include parent provider linkage, right?
14:43:20 <jaypipes> in any case, I'll spec it up
14:43:26 <efried> cool
14:43:48 <jaypipes> #action jaypipes to write spec for allocation candidates using nested providers
14:43:51 <efried> Yeah, microversion or not, the corner cases are what I think is important to document.  Somewhere.
14:44:05 <edleafe> cdent: but if B was the wrong result...
14:45:32 <edleafe> 15 minutes left, so lets move on
14:45:33 <edleafe> #topic Bugs
14:45:33 <edleafe> #link Placement bugs https://bugs.launchpad.net/nova/+bugs?field.tag=placement&orderby=-id
14:45:38 <edleafe> 2 new bugs this week
14:45:51 <edleafe> cdent seems to be on one of them
14:46:06 <cdent> i'm a bug?
14:46:33 <cdent> oh that one, yeah, I've fixed that, but it's down within some extraction related stuff because it is tidier that way
14:46:34 <edleafe> cdent: read again, more carefully
14:46:37 <efried> Heh, that's how I read it the first time too.
14:47:04 <edleafe> The other is "deleting a nova-compute service leaves orphaned records in placement and host mapping"
14:47:26 <mriedem> tssurya is goign to patch ^
14:47:38 <mriedem> or so she promised
14:47:43 <tssurya> yes
14:47:44 <edleafe> mriedem: heh, was just typing that...
14:48:13 <tssurya> I will put a WIP asap
14:48:42 <edleafe> ok, great
14:48:51 <edleafe> that brings us to...
14:48:56 <edleafe> #topic Open Discussion
14:49:10 <edleafe> What haven't we covered?
14:49:23 <jaypipes> functional tests?
14:49:48 <jaypipes> sorry, wrong window...
14:50:08 <cdent> worthwhile anyway could always use more functional tests
14:50:13 <jaypipes> heh
14:50:42 <efried> Wouldn't mind opinions on "placement version discovery" issue.
14:50:50 <efried> jaypipes is against it.
14:51:04 <efried> https://review.openstack.org/#/c/549184/
14:51:07 <mriedem> why? code churn?
14:51:29 <efried> There's been a comment in the code for a while to do some version discovery.
14:51:33 <mriedem> i think it's low priority but ultimately good for upgrades,
14:51:36 <efried> It would save us doing try-and-handle-406
14:51:40 <mriedem> if you look at what ironic is trying to do now
14:52:07 <mriedem> we've always had the same issue with ironic, it must be upgraded before nova
14:52:18 <jaypipes> mriedem: that's not the same thing as this.
14:52:46 <jaypipes> mriedem: what cdent and I are opposed to is the caching behaviour described in efried's spec.
14:53:03 <jaypipes> mriedem: and the inherent synchronization problems that will come with that.
14:53:18 <jaypipes> mriedem: versus just using the negotiation behaviour inherent in the 406 handling
14:53:26 <jaypipes> mriedem: in any case, it's low priority IMHO
14:53:38 <mriedem> oh yeah i never assumed there would be any client side cache
14:53:46 <mriedem> just 'try this, fail, do old thing'
14:53:47 <efried> mriedem: So what would the version discovery be used for?
14:53:48 <cdent> I was agnostic. My comment was "don't diss HTTP" and "okay, if you wanna"
14:53:57 <jaypipes> I was less agnostic.
14:54:20 <cdent> but I tend to be anti-cache for any first round of anything
14:54:21 <mriedem> efried: for example there was the allocations GET/PUT format change in queens,
14:54:30 <mriedem> if we can't use the new format, we knew we could use the old format in that case,
14:54:44 <mriedem> if the client *needs* some specific minimum microversoin and it's not there, the client has to fail
14:54:51 <efried> mriedem: Isn't that also doable via 406-and-retry?
14:55:14 <efried> okay; I thought we were handling minimum microversion somewhere else (though tbh I never know where)
14:55:21 <mriedem> yeah, i wouldn't read too literally into the version discovery comment
14:55:34 <mriedem> i.e. version negoation
14:55:37 <mriedem> *negotiation
14:55:46 <mriedem> 406 and retry is fine
14:55:50 <efried> So basically, if we don't need the discovered version for anything, let's just delete that comment, yah?
14:56:15 <efried> I'm happy with that answer.  Will propose -1LOC change and abandon spec/patch for discovery.  Thanks y'all.
14:56:19 <cdent> for the foreseeable it is unlikely that placement will ever bump its own minimum version, yeah?
14:56:32 <mriedem> yes
14:56:41 <edleafe> cdent: yeah, I can't see a need for a bump
14:56:59 <mriedem> cruft cleanup would be the justification
14:57:17 <mriedem> fwiw, that's less of a problem imo for placement than the compute api
14:57:21 <mriedem> which is an end user facing api
14:57:29 <mriedem> and nova already requires a minimum version of placement
14:57:53 <mriedem> but we don't really need to rathole on that right now
14:58:03 <edleafe> 2 minutes left. Anything else to discuss?
14:58:29 * cdent wants those two minutes
14:58:31 <cdent> let's end it
14:58:58 <edleafe> Thanks everyone!
14:59:00 <edleafe> #endmeeting