Open Stack

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.
Mark


> 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>