[Openstack-operators] [openstack-dev] [ironic] [nova] [tripleo] Deprecation of Nova's integration with Ironic Capabilities and ComputeCapabilitiesFilter
Matt Riedemann
mriedemos at gmail.com
Thu Sep 20 15:00:54 UTC 2018
On 9/20/2018 4:16 AM, John Garbutt wrote:
> 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.
I left a few comments in the change, but I'm assuming as part of the
deprecation we'd remove the filter from the default enabled_filters list
so new installs don't automatically get warnings during scheduling?
Another thing is about existing flavors configured for these
capabilities-scoped specs. Are you saying during the deprecation we'd
continue to use those even if the filter is disabled? In the review I
had suggested that we add a pre-upgrade check which inspects the flavors
and if any of these are found, we report a warning meaning those flavors
need to be updated to use traits rather than capabilities. Would that be
reasonable?
--
Thanks,
Matt
More information about the OpenStack-operators
mailing list