Hi all!
There have been some talks about $subj recently, but I've just realized that not
everyone is still aware of it. So, this is a heads up about recent changes in
nova scheduling of bare metal instances. If you only use standalone deployments,
you can ignore it. If you run a 3rd party CI, please read carefully though.
In the Pike release, that will happen really soon, nova will feature a new way
of scheduling bare metals. It will be based on custom resource classes [1]
instead of CPU count, memory and disk size. The old way is thus deprecated [2]
and will be unavailable in Queens. For those chasing master Queens is *already
happening*.
The reason behind the change is that properties-based scheduling for bare metals
does not really match properties-based scheduling for VMs. If I have a VM with
16 GiB of RAM, I can put there 3-4 instances that require 4 GiB of RAM. If I
have a BM with 16 GiB of RAM, I can only put one instance there, no matter how
much RAM it needs. This situation required ugly hacks in the ironic virt driver
to avoid excessive scheduling retries.
The new approach is to make bare metal nodes expose exactly one unit of some
custom resource class. Such class is set on the node.resource_class field, and
is requested by a flavor as described in our docs [3]. The standard properties
will stop being exposed from ironic nodes to nova in Queens. We have already
removed some hacks from the ironic virt driver, which may make a deployment
without resource classes less stable [4].
We have switched [5] the ironic CI to using resource classes by default. This is
something the 3rd party CI will have to follow for Pike and Queens as soon as
possible, otherwise they may get broken. Make sure you do *not* set
IRONIC_USE_RESOURCE_CLASSES to False in your configuration, then our devstack
plugin will handle setting resource classes and configuring flavors for you.
All operators running ironic will have to set the resource class field before
upgrading to Pike and change their flavors before upgrading to Queens. See our
upgrade notes [6] for details.
As an example, I have updated TripleO undercloud to always set the same constant
resource class [7] on nodes and request it in flavors [8]. This is, of course,
the simplest way to use custom resource classes. I went down this path, because
TripleO extensively uses capabilities for precise scheduling anyway. A more
sophisticated bare metal cloud may use many more custom resource classes.
Please let us know if you have any questions.
[1]
https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/custom-resource-classes-in-flavors.html
[2] https://docs.openstack.org/releasenotes/nova/pike.html#deprecation-notes
[3]
https://docs.openstack.org/ironic/latest/install/configure-nova-flavors.html#scheduling-based-on-resource-classes
[4] https://docs.openstack.org/releasenotes/nova/pike.html#known-issues
[5] https://review.openstack.org/#/c/494850/
[6] https://docs.openstack.org/releasenotes/ironic/pike.html#id7
[7] https://review.openstack.org/493943
[8] https://review.openstack.org/490851
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
