[nova] Strict isolation of group of hosts for image and flavor, modifying command 'nova-manage placement sync_aggregates'
On Mon, 2019-06-10 at 17:38 -0500, Eric Fried wrote:
> > > > (e) Fully manual. Aggregate operations never touch (add or remove)
> > > > traits on host RPs. You always have to do that manually.
> I'm going to come down in favor of this option. It's the shortest path
> to getting something viable working, in a way that is simple to
> understand, despite lacking magical DWIM-ness.
> > > > As noted above,
> > > > it's easy to do - and we could make it easier with a tiny wrapper that
> > > > takes an aggregate, a list of traits, and an --add/--remove command. So
> > > > initially, setting up aggregate isolation is a two-step process, and in
> > > > the future we can consider making new API/CLI affordance that combines
> > > > the steps.
> > ya e could work too.
> > melanie added a similar functionality to osc placment for managing the alloction ratios
> > of specific resource classes per aggregate a few months ago
> > https://review.opendev.org/#/c/640898/
> > we could proably provide somthing similar for managing traits but determining what RP to
> > add the trait too would be a littel tricker. we would have to be able to filter to RP with either a
> > specific inventory or with a specific trait or in a speicic subtree.
> We (Placement team) are still trying to figure out how to manage
> concepts like "resourceless request groups" and "traits/aggregates flow
> down". But for now, Nova is still always modeling VCPU/MEMORY_MB and
> traits on the root provider, so let's simply hit the providers in the
> aggregate (i.e. the root compute host RPs).
> I'm putting this on the agenda for Thursday's nova meeting  to
> hopefully get some more Nova opinions on it.
for what its worth for the host-aggate case teh aplity to add or remvoe a trait form all root providers
is likely enough, so that would make a cli much simpeler to create.
for the generic case of being able to add/remove a trait on an rp that could be anyhere in a nested tree
for all trees in an aggaget, that is a much harder problem but we also do not need it to solve the usecase we
have today so we can defer that until we actully need it and if we never need it we can defer it forever.
so +1 for keeping it simple and just updating the root RPs.
>  https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting