Multi-tenancy isolation only schedule instances in selected aggregates
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 "AggregateMulti
This will allow the exclusive dedication of an aggregate to a set of tenants.
Blueprint information
- Status:
- Started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- Belmiro Moreira
- Definition:
- Drafting
- Series goal:
- None
- Implementation:
- Started
- Milestone target:
- None
- Started by
- Belmiro Moreira
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
Gerrit topic: https:/
Addressed by: https:/
Implements complete tenant isolation filter
There's some similarities here with https:/
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 AggregateMultiT
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 'AggregateMulti
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: http://
[jesse-pretorius 12 June 2014]
Draft spec for review prepared by belmiro: https:/
[belmiro 16 June 2014]
There are very interesting work being proposed to isolate scheduler DB. See: https:/
If implemented the "AggregateMulti
Addressed by: https:/
Dedicate aggregates for specific tenants
Addressed by: https:/
[WIP] Dedicate aggregates for specific tenants