On Thu, 2019-06-06 at 16:52 -0500, Eric Fried wrote:
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 i personaly dislike c as it means we cannot use any standard traits in host aggrates.
there is also an option d. when you remove a trait form a host aggregate for each host in the aggregate check if that traits exists on another aggregate the host is a member of and remove it if not found on another aggregate.
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.
c is only a good option if we are talking about a specific set of new traits for this usecase e.g. CUSTOM_AGGREGATE_ISOLATION_WINDOWS_LICENSE but if we want to allow setting tratis genericaly on hosts via host-aggrages its not really that usefull. for example we talked about useing a hyperthreading trait in the cpu pinning spec which will not be managed by the compute driver. host aggages would be a convient way to be able to manage that trait if this was a generic feature. for c you still have to deal with the fact a host can be in multiple host aggrates too by the way so jsut because a thread is namespace d and it is removed from an aggrate does not mean its correcct to remove it from a host.