Open Stack

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.