Open Stack

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