Re: [openstack-dev] [ironic] [nova] [tripleo] Deprecation of Nova's integration with Ironic Capabilities and ComputeCapabilitiesFilter
On 9/25/2018 8:36 AM, John Garbutt wrote: 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. Forgive my ignorance, but if traits are not on par with capabilities, why are we deprecating the capabilities filter? -- 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
Re: [openstack-dev] [ironic] [nova] [tripleo] Deprecation of Nova's integration with Ironic Capabilities and ComputeCapabilitiesFilter
On Tue, 25 Sep 2018 at 14:37, John Garbutt wrote: > On Thu, 20 Sep 2018 at 16:02, Matt Riedemann 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
Re: [openstack-dev] [ironic] [nova] [tripleo] Deprecation of Nova's integration with Ironic Capabilities and ComputeCapabilitiesFilter
On Thu, 20 Sep 2018 at 16:02, Matt Riedemann 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 __ 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
Re: [openstack-dev] [ironic] [nova] [tripleo] Deprecation of Nova's integration with Ironic Capabilities and ComputeCapabilitiesFilter
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
[openstack-dev] [ironic] [nova] [tripleo] Deprecation of Nova's integration with Ironic Capabilities and ComputeCapabilitiesFilter
Hi, 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. Many thanks, John Garbutt IRC: johnthetubaguy __ 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
