[nova] Strict isolation of group of hosts for image and flavor, modifying command 'nova-manage placement sync_aggregates'

Eric Fried openstack at fried.cc
Thu Jun 6 21:52:54 UTC 2019

Let me TL;DR this:

The forbidden aggregates filter spec [1] says when we put trait metadata
onto a host aggregate, we should add the same trait to the compute node
RPs for all the hosts in that aggregate, so that the feature actually
works when we use it.

But we never talked about what to do when we *remove* a trait from such
an aggregate, or trash an aggregate with traits, or remove a host from
such an aggregate.

Here are the alternatives, as Vrushali laid them out (letters added by me):

> (a) Leave all traits alone. If they need to be removed, it would have to
> be manually via a separate step.
> (b) Support a new option so the caller can dictate whether the operation
> should remove the traits. (This is all-or-none.)
> (c) Define a "namespace" - a trait substring - and remove only traits in
> that namespace.

I'm going to -1 (b). It's too big a hammer, at too big a cost (including
API changes).

> If I’m not wrong, for last two approaches, we would need to change
> RestFul APIs.

No, (c) does not. By "define a namespace" I mean we would establish a
naming convention for traits to be used with this feature. For example:


And when we do any of the removal things, we always and only remove any
trait containing the substring _AGGREGATE_ISOLATION_ (assuming it's not
asserted by other aggregates in which the host is also a member, yatta

IMO (a) and (c) both suck, but (c) is a slightly better experience for
the user.




> Disclaimer: This email and any attachments are sent in strictest
> confidence for the sole use of the addressee and may contain legally
> privileged, confidential, and proprietary data. If you are not the
> intended recipient, please advise the sender by replying promptly to
> this email and then delete and destroy this email and any attachments
> without any further use, copying or forwarding.

Hear that, pipermail?

More information about the openstack-discuss mailing list