>> 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 [1] 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. [1] 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 [2] that's still "dangling". We discussed it in the sched meeting this week [3] and concluded [4] that we shouldn't do it in Rocky. BUT tetsuro later pointed out that part of the series in question [5] 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 [6] to parse and respond to the ML thread. After he clones himself. [2] http://lists.openstack.org/pipermail/openstack-dev/2018-March/128944.html [3] http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-04-02-14.00.log.html#l-91 [4] http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-04-02-14.00.log.html#l-137 [5] https://review.openstack.org/#/c/558045/ [6] 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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
