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

Mark Goddard mark at stackhpc.com
Tue Sep 25 13:39:31 UTC 2018

On Tue, 25 Sep 2018 at 14:37, John Garbutt <john at johngarbutt.com> wrote:

> On Thu, 20 Sep 2018 at 16:02, Matt Riedemann <mriedemos at gmail.com> wrote:
>> 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?
> +1
> Good point, we totally need to do that.
>> 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?
> I like the idea of a warning, but there are features that have not yet
> moved to traits:
> https://specs.openstack.org/openstack/ironic-specs/specs/juno-implemented/uefi-boot-for-ironic.html
> There is a more general plan that will help, but its not quite ready yet:
> https://review.openstack.org/#/c/504952/
> As such, I think we can't get pull the plug on flavors including
> capabilities and passing them to Ironic, but (after a cycle of deprecation)
> I think we can now stop pushing capabilities from Ironic into Nova and
> using them for placement.

Aren't the two things interdependent? You need to be able to schedule to a
node with the requested capability in order to use that capability to
influence deployment.

> 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/20180925/cd07a8e7/attachment.html>

More information about the OpenStack-dev mailing list