Open Stack

On Fri, Jun 7, 2019 at 1:31 AM, Sean Mooney <smooney at redhat.com> wrote:
> 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.

Besides possible performance impacts, I think this would be the logical 
behavior from nova to do.

cheers,
gibi