Chris-
Going to accumulate a couple of your emails and answer them. I could
have answered them separately (anti-affinity). But in this case I felt
it appropriate to provide responses in a single note (best fit).
> I'm a bit conflicted. On the one hand...
<snip>
> On the other hand,
Right; we're in agreement that we need to handle both.
> I'm half tempted to side with mriedem and say that there is no default
> and it must be explicit, but I'm concerned that this would make the
> requests a lot larger if you have to specify it for every resource.
and
> The request might get unwieldy if we have to specify affinity/anti-
> affinity for each resource. Maybe you could specify the default for
> the request and then optionally override it for each resource?
Yes, good call. I'm favoring this as a first pass. See my other response.
> In either viewpoint, is there a way to represent "I want two resource
> groups, with resource X in each group coming from different resource
> providers (anti-affinity) and resource Y from the same resource provider
> (affinity)?
As proposed, yes. Though if we go with the above (one flag to specify
request-wide behavior) then there wouldn't be that ability beyond
putting things in the un-numbered vs. numbered groups. So I guess my
question is: do we have a use case *right now* that requires supporting
"isolate for some, unrestricted for others"?
> I'm not current on the placement implementation details, but would
> this level of flexibility cause complexity problems in the code?
Oh, implementing this is complex af. Here's what it takes *just* to
satisfy the "any fit" version:
https://review.openstack.org/#/c/517757/10/nova/api/openstack/placement/objects/resource_provider.py@3599
I've made some progress implementing "proximity=isolate:X,Y,..." in my
sandbox, and that's even hairier. Doing "proximity=isolate"
(request-wide policy) would be a little easier.
-efried
__________________________________________________________________________
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
