Open Stack

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.

Thanks,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20180925/719d4155/attachment.html>