Open Stack

> -----Original Message-----
> From: Jay Pipes [mailto:jaypipes at gmail.com]
> Sent: Wednesday, April 18, 2018 3:39 PM
> To: openstack-dev at lists.openstack.org
> 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:
> >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> ______________________________________________________________________
> > ____ OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> _______________________________________________________________________
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev