Open Stack

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*.
> 
> 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
>