Open Stack

On Fri, 2019-06-07 at 07:38 +0000, Balázs Gibizer wrote:
> 
> 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.
option d is worstcase aproxmatly O(NlogN) but is technicall between O(n) and  O(NM)
where N is the number of instance and M is the maxium number of aggrates a host is a memeber of.

so it grows non linearly but the plroblem is not quadratic and is much closer to O(N) or O(NlogN) then it is
to O(N^2) so long if we are smart about how we look up the data form the db its probably ok.

we are basically asking for all the host in this aggrate, give me the hosts that dont have another aggrate with the
trait i am about to remove form this aggragte. those host are the set of host we need to update in placemnt and
sql is good at anserwing that type of question. if we do this in python it will make me sad.
 

> 
> cheers,
> gibi
>