Host aggregates are used to logically partition hypervisors into groups or availability zones that can be leveraged for advanced scheduling capabilities. This feature was first introduced in OpenStack Grizzly and continues to be supported in the latest release Train[0].
Example use cases for grouping hypervisors into host aggregates:
- Different hardware platforms (e.g. CPU type, disk, etc)
- Dedicated project equipment/servers
- Restrict scheduling for specific admin workloads (e.g. maintenance, dev, stress testing)
To enable these examples key-pair metadata values are required on each host aggregate and matching flavor. The nova scheduler filter AggregateInstanceExtraSpecsFilter is responsible for matching flavor metadata in the aggregate_instance_extra_specs namespace to the correct host aggregate. This functionality is only visible to administrators. Other than additional flavor options, there are no changes to the end-users.
Today the Toolforge scheduling pool is controlled by a custom Nova scheduling filter[1]. This filter currently supports enabling or disabling a hypervisor from the default scheduling pool. It's a very simple scheduler that has been successful, but has some limitations.
Benefits of using host aggregates in place of the custom filter:
- Updating the scheduling pool is dynamic and does not require any configuration[2] changes or service restarts.
- Ability to depool hypervisors only from end-users, while not blocking admins ability to schedule VMs
[0] https://docs.openstack.org/nova/latest/user/aggregates.html
[1] https://gerrit.wikimedia.org/r/plugins/gitiles/operations/puppet/+/refs/heads/production/modules/openstack/files/mitaka/nova/scheduler/scheduler_pool_filter.py
[2] https://gerrit.wikimedia.org/r/plugins/gitiles/operations/puppet/+/refs/heads/production/hieradata/eqiad/profile/openstack/eqiad1/nova.yaml#63