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:
CUSTOM_AGGREGATE_ISOLATION_WINDOWS_LICENSE
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 yatta).
IMO (a) and (c) both suck, but (c) is a slightly better experience for the user.
efried
[1] http://specs.openstack.org/openstack/nova-specs/specs/train/approved/placeme...
P.S.
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?