[Openstack-operators] [nova] isolate hypervisor to project

Tobias Urdin tobias.urdin at crystone.com
Mon Jun 4 13:36:54 UTC 2018


Saw now in the docs that multiple aggregate_instance_extra_specs keys
should be a comma-separated list.
But other than that, would the below do what I'm looking for?

Has a very high maintenance level when having a lot of hypervisors and
steadily adding new ones, but I can't see any other way to fully isolate it.
Would've been cool if the RFE you mentioned [1] could be researched and
if it qualifies implemented.

Best regards

[1] https://bugs.launchpad.net/openstack-publiccloud-wg/+bug/1771523

On 06/04/2018 03:32 PM, Tobias Urdin wrote:
> Hello,
> Thanks for the reply Matt.
>
> The hard thing here is that I have to ensure it the other way around as
> well i.e other instances cannot be allowed landing on those "reserved"
> hypervisors.
> I assume I could do something like in [1] and also set key-value
> metadata on all flavors to select a host aggregate that is not the
> "reserved" hypervisors.
>
> openstack aggregate create fast-cpu --property fast-cpu=true --property
> other=true
> openstack aggregate create normal-cpu --property normal-cpu=true
> --property other=true
> openstack aggregate create dedicated --property dedicated=true
> openstack aggregate add host fast-cpu compute1
> openstack aggregate add host normal-cpu compute2
> openstack aggregate add host dedicated compute3
> openstack flavor create --vcpus 4 --ram 4096 --disk 50 --property
> aggregate_instance_extra_specs:fast-cpu=true --property
> aggregate_instance_extra_specs:other=true fast-cpu.medium
> openstack flavor create --vcpus 4 --ram 4096 --disk 50 --property
> aggregate_instance_extra_specs:normal-cpu=true --property
> aggregate_instance_extra_specs:other=true normal-cpu.medium
> openstack flavor create --vcpus 4 --ram 4096 --disk 50 --private
> --project <project id> --property
> aggregate_instance_extra_specs:dedicated=true dedicated.medium
>
> It's seems very messy, would that be an supported approach?
> We are on Queens, doing it in a way that is not removed in the future
> would be optimal.
>
> Best regards
>
> [1] https://www.brad-x.com/2016/01/01/dedicate-compute-hosts-to-projects/
>
>
> On 06/04/2018 02:50 PM, Matt Riedemann wrote:
>> On 6/4/2018 6:43 AM, Tobias Urdin wrote:
>>> I have received a question about a more specialized use case where we
>>> need to isolate several hypervisors
>>>
>>> to a specific project. My first thinking was using nova flavors for only
>>> that project and add extra specs properties to use a specific host
>>> aggregate but this
>>>
>>> means I need to assign values to all other flavors to not use those
>>> which seems weird.
>>>
>>>
>>> How could I go about solving this the easies/best way or from the
>>> history of the mailing lists, the most supported way since there is a
>>> lot of changes
>>>
>>> to scheduler/placement part right now?
>> Depending on which release you're on, it sounds like you want to use this:
>>
>> https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#aggregatemultitenancyisolation
>>
>> In Rocky we have a replacement for that filter which does pre-filtering 
>> in Placement which should give you a performance gain when it comes time 
>> to do the host filtering:
>>
>> https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#tenant-isolation-with-placement
>>
>> Note that even if you use AggregateMultiTenancyIsolation for the one 
>> project, other projects can still randomly land on the hosts in that 
>> aggregate unless you also assign those to their own aggregates.
>>
>> It sounds like you're might be looking for a dedicated hosts feature? 
>> There is an RFE from the public cloud work group for that:
>>
>> https://bugs.launchpad.net/openstack-publiccloud-wg/+bug/1771523
>>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>




More information about the OpenStack-operators mailing list