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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
