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: [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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
