On Tue, 25 Sep 2018 at 14:37, John Garbutt <j...@johngarbutt.com> wrote:
> On Thu, 20 Sep 2018 at 16:02, Matt Riedemann <mriede...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ 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
