Multi-tenancy isolation only schedule instances in selected aggregates

Registered by Belmiro Moreira

The implementation of the blueprint “Multi-tenancy isolation with aggregates” defines that:
“If a host doesn't belongs to any aggregate it can create instances from all tenants.
Also, if a host belongs to aggregates that don't define the metadata filter_tenant_id
it can create instances from all tenants.”

This use case only excludes instances from non-defined tenant(s) to start in
the aggregate(s).

The goal for this blueprint is to extend the "AggregateMultiTenancyIsolation" scheduler filter in order to optionally exclude instances from being schedule for deployment in hosts that don't belong to the defined aggregate(s).

This will allow the exclusive dedication of an aggregate to a set of tenants.

Blueprint information

Needs approval
Belmiro Moreira
Series goal:
Milestone target:
Started by
Belmiro Moreira

Related branches



Gerrit topic:,topic:bp/multi-tenancy-isolation-only-aggregates,n,z

Addressed by:
    Implements complete tenant isolation filter

There's some similarities here with We should look at an implementation of reserving hosts for tenants that supports all of the uses cases being put forward. --russellb

I'm back to this blueprint and proposed implementation because I believe it addresses a completely different use case. This is to dedicate a set of very specific compute nodes to a tenant. The admin defines the aggregate(s) and instances from the specified tenant(s) will be started only in the aggregate.
This use case is common in institutes and laboratories where specific hardware (aggregate) is bought for a team (tenant) and can’t be in a pool or shared with others. --belmiro

[jesse-pretorius 5 Feb 2014]
The AggregateMultiTenancyIsolation filter ( almost does what I expect - it pushes all new instances created by a specified tenant to the designated aggregate. However, it also seems to still see that aggregate as available for other tenants, which is unexpected.
Perhaps this filter can be adjusted (instead of creating a new one) to have a metadata tag which tells it that the host is exclusively for the tenant(s) specified in the metadata.
@russelb - I think that the whole host allocation blueprint focuses on a much wider frameork for allowing host reservation by an end-user, whereas this blueprint is more focused on a simpler use-case where the admin exclusively controls the allocation.

[jesse-pretorius 6 Mar 2014]
@belmoreira I see that you've committed to doing some changes in the review, and that there are some suggestions for improvement in the review. Phil Day's caching patch has merged, so perhaps you could update your code?
An alternative option would be to take the 'AggregateMultiTenancyIsolation' filter and merge your code into it - allowing this filter to operate in either an 'exclusive' or 'inclusive' mode. Exclusive would only allow the list of projects to be deployed into the aggregate. Inclusive would allow any project to deploy onto the aggregate, but the list of projects in the aggregate metadata would be isolated to the aggregate.

Marking this blueprint as definition: Drafting. If you are still working on this, please re-submit via nova-specs. If not, please mark as obsolete, and add a quick comment to describe why. --johnthetubaguy (20th April 2014)

[belmiro 25 Apr 2014]
@jesse-pretorius I'm creating a new blueprint in nova-specs for it --belmiro

[jesse-pretorius 10 June 2014]
Mailing list discussion:

[jesse-pretorius 12 June 2014]
Draft spec for review prepared by belmiro:

[belmiro 16 June 2014]
There are very interesting work being proposed to isolate scheduler DB. See:
If implemented the "AggregateMultiTenancyIsolation" extension could benefit from it.

Addressed by:
    Dedicate aggregates for specific tenants

Addressed by:
    [WIP] Dedicate aggregates for specific tenants


Work Items