14:00:05 <cdent> #startmeeting nova_scheduler
14:00:06 <openstack> Meeting started Mon Nov 20 14:00:05 2017 UTC and is due to finish in 60 minutes.  The chair is cdent. 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:12 <cdent> #chair efried
14:00:13 <openstack> Current chairs: cdent efried
14:00:17 <efried> \o
14:00:22 <cdent> #link agenda https://wiki.openstack.org/wiki/Meetings/NovaScheduler
14:00:40 <takashin> o/
14:00:46 <cdent> it looks like the agenda hasn’t been recently updated so I think we can probably have a relatively free form catch-up-on-what-matters meeting
14:01:17 <efried> I had been in the process of updating the agenda, but didn't finish in time, sorry.
14:01:38 <cdent> if it had something interesting would you like a moment?
14:01:47 <efried> nope
14:01:47 <cdent> or are you happy to continue free form?
14:01:53 <cdent> Okay in the case:
14:01:55 <cdent> #topic specs
14:02:03 <efried> But I can comment on them as we go.
14:02:05 <cdent> Are there any pending specs
14:02:19 <efried> #link symmetric GET and PUT of allocations https://review.openstack.org/#/c/508164/ is merged
14:02:57 <cdent> yeah, and looks like nothing else is pending scheduler/placement-wise
14:03:02 <cdent> anyone disagree?
14:03:23 <cdent> #topic pending reviews that need attention
14:03:50 <cdent> There are lots of things currently under review, efried did a fine job of doing the placement update while I was away, I’ll pick it up again on friday
14:04:07 <cdent> Are there any reviews that are stuck, or have big questions?
14:04:23 <stephenfin> efried: oh hai
14:04:53 <efried> cdent - stephenfin just said in -nova that he'd get on the nrp series this week.
14:05:18 <cdent> well now that it is logged here, he’s forced to do it
14:05:20 <cdent> no backing out
14:05:20 <efried> Which is great - that's the #1 needs-core-eyeballs series IMO.
14:05:35 <stephenfin> Hurrah!
14:05:54 <cdent> #action stephenfin going to review the nested resource providers and we are all very grateful
14:06:30 <efried> Closely followed by https://review.openstack.org/#/c/516782/ which is now the first in the series (the first four already merged - yay!)
14:07:07 <efried> It's actually the last in the refactor series, but has a couple of additional subseries piled on top of it.
14:07:12 <cdent> #link lots of allocation candidate clean ups, tests, fixes starting near: https://review.openstack.org/#/c/516782/
14:07:30 <efried> And traits affordance ^
14:08:13 <efried> Basically, both of the above series (serieses??) are prerequisite to getting placement handling traits and granular.
14:08:29 <stephenfin> Sure thing. I'll start with nested RPs first since I know those
14:08:51 <efried> ++
14:09:32 <cdent> #link selection objects and alt destinations: https://review.openstack.org/#/c/499239/
14:09:39 <cdent> that’s the other main theme
14:09:42 * bauzas waves late
14:10:33 <cdent> anyone else need/want to point out reviews before we move on to bugs?
14:10:38 <efried> #link Include project_id and user_id in AllocationList.get_all_by_consumer_id https://review.openstack.org/#/c/512420/ <== this guy has *nine* +1s and a +2.  Should be a slam dunk +A for a willing core.
14:12:46 <stephenfin> I avoided +2ing that for reasons given in the review. bauzas? ^
14:13:05 <stephenfin> If not, I'll take the hit, heh
14:13:56 <cdent> it’s only in the followin changes that microversions get involved, so it’s not irrevocable
14:14:00 <cdent> #topic bugs
14:14:00 <bauzas> stephenfin: will look
14:14:11 <cdent> #link bugs: https://bugs.launchpad.net/nova/+bugs?field.tag=placement&orderby=-id&start=0
14:14:19 <cdent> looks like people have been finding plenty, which is great
14:16:03 <cdent> efried: on the stuff with non-connected RPs and get_by_filters/get_by_requests was there some kind of logic flaw or bogus SQL or ???
14:16:37 <efried> cdent As yet unknown.  That bug still exists, even at the top of the series.
14:17:01 <cdent> oh, bummer
14:18:02 <efried> I think Jay is on the hook to debug that one, or possibly alex_xu
14:18:32 <efried> I could try, but my sqla-fu may not be up to the task yet.
14:18:58 <cdent> but the failing test exists, right?
14:19:53 <efried> cdent Oh, several, yes.
14:20:08 <efried> Not merged, but in the aforementioned series.
14:20:29 <bauzas> cdent: note that we have a long list of new bugs
14:20:31 <efried> Worth mentioning, btw: GET /allocation_candidates bugs ought to be verified against the top of that series.
14:20:44 <efried> Because some of the "refactoring" also changed logic and fixed some bugs.
14:20:45 <bauzas> cdent: so we could possibly have more placement/scheduler bugs
14:22:19 <efried> Do we need to do a placement bug smash?
14:23:02 <cdent> probably more important is to do a general untriaged bug triaging
14:24:45 <efried> That's probably what I meant, just don't know the right words.
14:25:06 <cdent> I was effectively agreeing with bauzas’ warning
14:25:22 <bauzas> cdent: I'll look at the new bugs by the week
14:25:29 <bauzas> but if people would help me, <3
14:25:56 <bauzas> FWIW, I provided a Summit talk about that in SYD :p
14:26:06 <bauzas> I mean, me and stephenfin :)
14:26:28 <cdent> #topic open discussion
14:26:47 <cdent> anyone have anything else, or should efried just talk to me about what he’s trying to talk to me about in #openstack-nova?
14:27:42 <efried> (which is a loose debate on the relative merits of a placement client lib.)
14:28:21 <cdent> I guess you have the floor mr efried
14:28:41 <efried> ...which came from stephenfin posting a link to this review: https://review.openstack.org/#/c/511936/
14:29:15 <efried> Okay, so the "ideal world" view is that the placement API should be returning stuff in a form that's consumable as "just json" without having to do a bunch of extra processing.
14:30:10 <bauzas> efried: what's your concern ?
14:30:13 <cdent> rather that any complexity is domain specific and should not be built into the client
14:30:18 <bauzas> I wasn't looking at -nova
14:30:29 <efried> It seems to me as though the current form of the placement API, with respect to querying RPs at least, is much closer to reflecting the database than to being able to get a useful set of information.
14:31:00 <efried> For example, you have to do three or four separate queries to figure out a RP's aggregates, traits, and inventories.
14:31:28 <efried> I see clients finding it useful to be able to do one call and get a single blob with all that information collated.
14:31:38 <cdent> yes, there was an mid stage design that had a more full resource provider representation
14:31:45 <efried> Which may be an argument to add an API for that.
14:32:13 <efried> particularly to reduce the number of calls, for the sake of efficiency.
14:32:35 <bauzas> well
14:32:46 <bauzas> that's a reasonable point
14:32:47 <bauzas> but
14:33:10 <bauzas> the problem is, should we orchestrate more than just providing allocations and inventories ?
14:33:29 <bauzas> FWIW, we said that placement is just here for providing the above
14:33:31 <efried> bauzas Not necessarily, but even within that scope the point remains.
14:33:54 <efried> But I think perhaps the "ideal world" view holds here: if we find ourselves needing a client lib call (i.e. more than one consumer cares about it) to get a certain collected set of information, that's a case for adding an actual API call to do the same.
14:34:06 <efried> I cited this as an example: https://review.openstack.org/#/c/521098/4/nova/scheduler/client/report.py
14:34:06 <bauzas> I think that's probably something that should live on the client side
14:34:26 <bauzas> for aggregating all the resources
14:34:59 <efried> bauzas So yeah, right now the above is living on the client side.
14:35:02 <bauzas> I know
14:35:04 <cdent> yeah, my bone of contention here is resting on the hope that more than one consumer _won’t_ need the call linked in the patchset
14:35:39 <bauzas> efried: and I think it should stay at least until more than just nova uses placement
14:36:09 <bauzas> the API should stay minimalistic and RESTful at least until the above
14:36:20 <bauzas> then, we could discuss on how to modify that
14:36:40 <efried> I haven't yet looked at the patch stephenfin posted.  I guess I'll reserve judgment until I see how much overlap, if any, that patch presents with what we've built and are building in SchedulerReportClient.
14:38:33 <efried> Anyway, it's something we ought to keep an eye on.  In summary: watch for placement consumers doing similar client-side things, and consider whether those things are appropriate for one or both of a) a client lib; b) API adds.
14:39:33 <efried> Unless anyone has anything further, we can call it early.
14:39:43 <bauzas> sure
14:39:47 <cdent> I agree with that summary
14:39:47 <bauzas> looks reasonable
14:40:03 <cdent> always be watching
14:40:08 <cdent> anyone have any last words?
14:40:10 <bauzas> albeit.
14:40:20 <cdent> thanks for coming
14:40:22 <cdent> #endmeeting