>> it's really on nested allocation candidates. > > Yup. And that series is deadlocked on a disagreement about whether > granular request groups should be "separate by default" (meaning: if you > request multiple groups of resources, the expectation is that they will > be served by distinct resource providers) or "unrestricted by default" > (meaning: if you request multiple groups of resources, those resources > may or may not be serviced by distinct resource providers).
This is really a granular thing, not a nested thing. I was holding up the nrp-in-alloc-cands spec  for other reasons, but I've stopped doing that now. We should be able to proceed with the nrp work. I'm working on the granular code, wherein I can hopefully isolate the separate-vs-unrestricted decision such that we can go either way once that issue is resolved.  https://review.openstack.org/#/c/556873/ >> Some negotiation happened with regard to when/if the fixes for >> shared providers is going to happen. I'm not sure how that resolved, >> if someone can follow up with that, that would be most excellent. This is the subject of another thread  that's still "dangling". We discussed it in the sched meeting this week  and concluded  that we shouldn't do it in Rocky. BUT tetsuro later pointed out that part of the series in question  is still needed to satisfy NRP-in-alloc-cands (return the whole tree's providers in provider_summaries - even the ones that aren't providing resource to the request). That patch changes behavior, so needs a microversion (mostly done already in that patch), so needs a spec. We haven't yet resolved whether this is truly needed, so haven't assigned a body to the spec work. I believe Jay is still planning  to parse and respond to the ML thread. After he clones himself.  http://lists.openstack.org/pipermail/openstack-dev/2018-March/128944.html  http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-04-02-14.00.log.html#l-91  http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-04-02-14.00.log.html#l-137  https://review.openstack.org/#/c/558045/  http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-04-02-14.00.log.html#l-104 >> * Shared providers status? >> (I really think we need to make this go. It was one of the >> original value propositions of placement: being able to accurate >> manage shared disk.) > > Agreed, but you know.... NUMA. And CPU pinning. And vGPUs. And FPGAs. > And physnet network bandwidth scheduling. And... well, you get the idea. Right. I will say that Tetsuro has been doing an excellent job slinging code for this, though. So the bottleneck is really reviewer bandwidth (already an issue for the work we *are* trying to fit in Rocky). If it's still on the table by Stein, we ought to consider making it a high priority. (Our Rocky punchlist seems to be favoring "urgent" over "important" to some extent.) -efried __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev