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
__________________________________________________________________________
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
