[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