[openstack-dev] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

John Garbutt john at johngarbutt.com
Thu Oct 19 15:37:34 UTC 2017


On 19 October 2017 at 15:38, Jay Pipes <jaypipes at gmail.com> wrote:

> On 10/16/2017 05:31 AM, Nisha Agarwal wrote:
>
>> Hi Matt,
>>
>> As i understand John's spec https://review.openstack.org/#/c/507052/ <
>> https://review.openstack.org/#/c/507052/>, it is actually a replacement
>> for capabilities(qualitative only) for ironic. It doesnt cover the
>> quantitative capabilities as 'traits' are meant only for qualitative
>> capabilities. Quantitative capabilities are covered by resource classes in
>> Nova. We have few (one or two) quantitative capabilities already supported
>> in ironic.
>>
>
> Hi Nisha,
>
> This may be a case of mixed terminology. We do not refer to anything
> quantitative as a "capability". Rather, we use the term "resource class"
> (or sometimes just "resource") to represent quantitative things that may be
> consumed by the instance.
>
> Traits, on the other hand, are qualitative. They represent a binary on/off
> capability that the compute host (or baremetal node in the case of Ironic)
> exposes.
>
> There's no limit on the number of traits that may be associated with a
> particular Ironic baremetal node. However, for Ironic baremetal nodes, if
> the node.resource_class attribute is set, the Nova Ironic virt driver will
> create a single inventory record for the node containing a quantity of 1
> and a resource class equal to whatever is in the node.resource_class
> attribute. This resource class is auto-created by Nova as a custom resource
> class.
>

Just to follow up on this one...

I hope my traits spec will replace the need for the non-exact filters.

Consider two flavors Gold and Gold_Plus. Lets say Gold_plus gives you a
slightly newer CPU, or something.

Consider this setup:

* both GOLD and GOLD_PLUS ironic nodes have Resource Class: CUSTOM_GOLD
* but you can have some have trait: GOLD_REGULAR and some with GOLD_PLUS

Now you can have the flavors:

* GOLD flavor requests resources:CUSTOM_GOLD=1
* GOLD_PLUS flavor also has resources:CUSTOM_GOLD=1 but also
trait:GOLD_PLUS:requires

Now eventually we could modify the GOLD flavor to say:

* resources:CUSTOM_GOLD=1 and trait:GOLD_REGULAR:prefer

@Nisha I think that should largely allow you to construct the same behavior
you have today, or am I totally missing what you are wanting to do?

Thanks,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171019/0ce70c3d/attachment.html>


More information about the OpenStack-dev mailing list