Open Stack

On Thu, 7 Sep 2017 14:57:24 -0500, Matt Riedemann wrote:
> Some more background information is in the ironic spec here:
> 
> https://review.openstack.org/#/c/500429/
> 
> Also, be aware of these release notes for Pike related to baremetal 
> scheduling:
> 
> http://docs-draft.openstack.org/77/501477/1/check/gate-nova-releasenotes/1dc7513//releasenotes/build/html/unreleased.html#id2 
> 
> 
> In Pike, nova is using a combination of VCPU/MEMORY_MB/DISK_GB resource 
> class amounts from the flavor during scheduling as it always has, but it 
> will also check for the custom resource_class which comes from the 
> ironic node. The custom resource class is optional in Pike but will be a 
> hard requirement in Queens, or at least that was the plan. The idea 
> being that long-term we'd stop consulting VCPU/MEMORY_MB/DISK_GB from 
> the flavor during scheduling and just use the atomic node.resource_class 
> since we want to allocate a nova instance to an entire ironic node, and 
> this is also why the Exact* filters were used too.
> 
> There are more details on using custom resource classes for scheduling 
> here:
> 
> https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/custom-resource-classes-in-flavors.html 
> 
> 
> Nisha is raising the question about whether or not we're making 
> incorrect assumptions about how people are using nova/ironic and they 
> want to use the non-Exact filters for VCPU/MEMORY_MB/DISK_GB, which as 
> far as I have ever heard is not recommended/supported upstream as it can 
> lead to resource tracking issues in Nova that eventually lead to 
> scheduling failures later because of the scheduler thinking a node is 
> available for more than one instance when it's really not.

This came up in the Nova PTG room yesterday and I wanted to reply on the 
thread with what I understood about it, for those who weren't in the 
session. In general, it's recommended to use the exact filters (1 flavor 
per Ironic node hardware config) as there's no concept of partially 
claiming a baremetal node.

But, with the old non-exact filters, you _could_ get away with creating 
fewer flavors than you have hardware configs and get "fuzzy matching" on 
Ironic nodes, to get nodes whose configs are "close enough" but not 
exact. This might be helpful in situations where you have some oddball 
configs you don't want to have separate flavors for.
I was thinking, if it's possible to assign more than one resource class 
to an Ironic node, maybe you could get similar behavior to the old 
non-exact filters. So if you have an oddball config, you could tag it as 
multiple resource classes that it's "close enough" to for a match. But 
I'm not sure whether it's possible for an Ironic node to be tagged with 
more than one resource class.

-melanie