[openstack-dev] [ironic] [nova] [tripleo] Deprecation of Nova's integration with Ironic Capabilities and ComputeCapabilitiesFilter

John Garbutt john at johngarbutt.com
Thu Sep 20 09:16:34 UTC 2018


Hi,

Following on from the PTG discussions, I wanted to bring everyone's
attention to Nova's plans to deprecate ComputeCapabilitiesFilter, including
most of the the integration with Ironic Capabilities.

To be specific, this is my proposal in code form:
https://review.openstack.org/#/c/603102/

Once the code we propose to deprecate is removed we will stop using
capabilities pushed up from Ironic for 'scheduling', but we would still
pass capabilities request in the flavor down to Ironic (until we get some
standard traits and/or deploy templates sorted for things like UEFI).

Functionally, we believe all use cases can be replaced by using the simpler
placement traits (this is more efficient than post placement filtering done
using capabilities):
https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/ironic-driver-traits.html

Please note the recent addition of forbidden traits that helps improve the
usefulness of the above approach:
https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/placement-forbidden-traits.html

For example, a flavor request for GPUs >= 2 could be replaced by a custom
trait trait that reports if a given Ironic node has
CUSTOM_MORE_THAN_2_GPUS. That is a bad example (longer term we don't want
to use traits for this, but that is a discussion for another day) but it is
the example that keeps being raised in discussions on this topic.

The main reason for reaching out in this email is to ask if anyone has
needs that the ResourceClass and Traits scheme does not currently address,
or can think of a problem with a transition to the newer approach.

Many thanks,
John Garbutt

IRC: johnthetubaguy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180920/127cc0bd/attachment.html>


More information about the OpenStack-dev mailing list