> -----Original Message----- > From: Jay Pipes [mailto:[email protected]] > Sent: Wednesday, April 18, 2018 3:39 PM > To: [email protected] > Subject: Re: [openstack-dev] [placement][nova] Decision time on > granular request groups for like resources > > On 04/18/2018 10:30 AM, Eric Fried wrote: > > Thanks for describing the proposals clearly and concisely, Jay. > > > > My preamble would have been that we need to support two use cases: > > > > - "explicit anti-affinity": make sure certain parts of my request > land > > on *different* providers; > > - "any fit": make sure my instance lands *somewhere*. > > [Mooney, Sean K] for completeness we must also support explicit affinity also So the tree cases are "explicit anti-affinity": make sure certain parts of my request land on *different* providers in the same tree think VFs for bonded ports. "explicit affinity": make sure certain parts of my request land on the same providers in the same tree. This is the numa affinity case for ram and cpus. "any fit": make sure my instance lands *somewhere* with in the same tree.
We have to also be aware of the implication for sharing resource providers here Too as with jays approach you cannot mix shared and non-shared in a request Numbered request group. With eric's proposal I believe you can have allocation within A numbered request group come from sharing providers and local providers assuming you Do not use traits to confine that behavior. > > Both proposals address both use cases, but in different ways. > > Right. > > It's important to point out when we say "different providers" in this > ML post, we are specifically referring to different providers *within a > tree of providers*. We are not referring to completely separate compute > hosts. We are referring to things like multiple NUMA cells that expose > CPU resources on a single compute host or multiple SR-IOV-enabled > physical functions that expose SR-IOV VFs for use by guests. > > Best. > -jay > > >> "By default, should resources/traits submitted in different numbered > >> request groups be supplied by separate resource providers?" > > > > I agree this question needs to be answered, but that won't > necessarily > > inform which path we choose. Viewpoint B [3] is set up to go either > > way: either we're unrestricted by default and use a queryparam to > > force separation; or we're split by default and use a queryparam to > > allow the unrestricted behavior. > > > > Otherwise I agree with everything Jay said. > > > > -efried > > > > On 04/18/2018 09:06 AM, Jay Pipes wrote: > >> Stackers, > >> > >> Eric Fried and I are currently at an impasse regarding a decision > >> that will have far-reaching (and end-user facing) impacts to the > >> placement API and how nova interacts with the placement service from > >> the nova scheduler. > >> > >> We need to make a decision regarding the following question: > >> > >> > >> There are two competing proposals right now (both being amendments > to > >> the original granular request groups spec [1]) which outline two > >> different viewpoints. > >> > >> Viewpoint A [2], from me, is that like resources listed in different > >> granular request groups should mean that those resources will be > >> sourced from *different* resource providers. > >> > >> In other words, if I issue the following request: > >> > >> GET /allocation_candidates?resources1=VCPU:1&resources2=VCPU:1 > >> > >> Then I am assured of getting allocation candidates that contain 2 > >> distinct resource providers consuming 1 VCPU from each provider. > >> > >> Viewpoint B [3], from Eric, is that like resources listed in > >> different granular request groups should not necessarily mean that > >> those resources will be sourced from different resource providers. > >> They *could* be sourced from different providers, or they could be > >> sourced from the same provider. > >> > >> Both proposals include ways to specify whether certain resources or > >> whole request groups can be forced to be sources from either a > single > >> provider or from different providers. > >> > >> In Viewpoint A, the proposal is to have a > >> can_split=RESOURCE1,RESOURCE2 query parameter that would indicate > >> which resource classes in the unnumbered request group that may be > >> split across multiple providers (remember that viewpoint A considers > >> different request groups to explicitly mean different providers, so > >> it doesn't make sense to have a can_split query parameter for > numbered request groups). > >> > >> In Viewpoint B, the proposal is to have a separate_providers=1,2 > >> query parameter that would indicate that the identified request > >> groups should be sourced from separate providers. Request groups > that > >> are not listed in the separate_providers query parameter are not > >> guaranteed to be sourced from different providers. > >> > >> I know this is a complex subject, but I thought it was worthwhile > >> trying to explain the two proposals in as clear terms as I could > muster. > >> > >> I'm, quite frankly, a bit on the fence about the whole thing and > >> would just like to have a clear path forward so that we can start > >> landing the > >> 12+ patches that are queued up waiting for a decision on this. > >> > >> Thoughts and opinions welcome. > >> > >> Thanks, > >> -jay > >> > >> > >> [1] > >> http://specs.openstack.org/openstack/nova- > specs/specs/rocky/approved/ > >> granular-resource-requests.html > >> > >> > >> [2] https://review.openstack.org/#/c/560974/ > >> > >> [3] https://review.openstack.org/#/c/561717/ > >> > >> > _____________________________________________________________________ > >> _____ OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > >> [email protected]?subject:unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > ______________________________________________________________________ > > ____ OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > > [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________________________________ > ___ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev- > [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
