[openstack-dev] [nova] AggregateMultiTenancyIsolation scheduler filter - bug, or new feature proposal?

John Garbutt john at johngarbutt.com
Tue Jun 10 10:11:49 UTC 2014

There was a spec I read that was related to this idea of excluding
things that don't match the filter. I can't seem to find that, but the
general idea makes total sense.

As a heads up, the scheduler split means we are wanting to change how
the aggregate filters are working, more towards this direction,
proposed by Jay:


On 10 June 2014 08:19, Jesse Pretorius <jesse.pretorius at gmail.com> wrote:
> On 9 June 2014 15:18, Belmiro Moreira
> <moreira.belmiro.email.lists at gmail.com> wrote:
>> I would say that is a documentation bug for the
>> “AggregateMultiTenancyIsolation” filter.
> Great, thanks. I've logged a bug for this:
> https://bugs.launchpad.net/openstack-manuals/+bug/1328400
>> When this was implemented the objective was to schedule only instances
>> from specific tenants for those aggregates but not make them exclusive.
>> That’s why the work on
>> https://blueprints.launchpad.net/nova/+spec/multi-tenancy-isolation-only-aggregates
>> started but was left on hold because it was believed
>> https://blueprints.launchpad.net/nova/+spec/whole-host-allocation had some
>> similarities and eventually could solve the problem in a more generic way.
>> However p-clouds implementation is marked as “slow progress” and I believe
>> there is no active work at the moment.
>> Probably is a good time to review the "ProjectsToAggregateFilter" filter
>> again. The implementation and reviews are available at
>> https://review.openstack.org/#/c/28635/
> Agreed. p-clouds is a much greater framework with much deeper and wider
> effects. The isolated aggregate which you submitted code for is exactly what
> we're looking for and actually what we're using in production today.
> I'm proposing that we put together the nova-spec for
> https://blueprints.launchpad.net/nova/+spec/multi-tenancy-isolation-only-aggregates,
> but as suggested in my earlier message I think a simpler approach would be
> to modify the existing filter to meet our needs by simply using an
> additional metadata tag to designate the aggregate as an exclusive one. In
> the blueprint you did indicate that you were going to put together a
> nova-spec for it, but I couldn't find one in the specs repository - either
> merged or WIP.
>> One of the problems raised was performance concerns considering the number
>> of DB queries required. However this can be documented if people intend to
>> enable the filter.
> As suggested by Phil Day in https://review.openstack.org/#/c/28635/ there is
> now a caching capability (landed in https://review.openstack.org/#/c/33720/)
> which reduces the number of DB calls.
> Can I suggest that we collaborate on the spec? Perhaps we can discuss this
> on IRC? My nick is odyssey4me and I'm in #openstack much of the typical
> working day and often in the evenings. My time zone is GMT+2.
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list