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. > "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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev