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

Wan-yen Hsu wanyenhsu at gmail.com
Thu Oct 26 23:57:26 UTC 2017


In Nisha's message, "capabilities" refers to "ComputeCapabilitiesFilter".
 "capabilities" provides a lot of flexibility for scheduling.  It supports
qualitative as well as quantitative attributes.  It supports a variety of
operators such as ">=", "<", "=", etc.   For instance, with "capabilities",
one can create a flavor for "GPU_Count >=2".  Quantity matters for
workloads.  A workload may require at least 2GPUs or at least certain
amount of SSD capacity to meet the performance requirements.   Trait will
help but it only supports qualitative attributes.  Therefore, we still need
"capabilities".

Standard Resource Class represents quantitative things but it 's not
available for Ironic.   Ironic currently can only use one single
CUSTOM_Resource_class with exact match.  Prior to Pike, Ironic customers
can use  non-exact match filter to support the use case of "at least this
amount of quantitative things on a bare metal node" but it's not supported
by Ironic Custom_resource_class.  Therefore it is a regression and will
cause issues for those who are depending on it.

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?

On Thu, Oct 19, 2017 at 8:37 AM, John Garbutt <john at johngarbutt.com> wrote:

> 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171026/ff41a113/attachment.html>


More information about the OpenStack-dev mailing list