<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi,<br><div><br></div><div>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.</div><div><br></div><div>To be specific, this is my proposal in code form:</div><div><a href="https://review.openstack.org/#/c/603102/">https://review.openstack.org/#/c/603102/</a><br></div><div><br></div><div>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).</div><div><br></div><div>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):</div><div><a href="https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/ironic-driver-traits.html">https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/ironic-driver-traits.html</a><br></div><div><br></div><div>Please note the recent addition of forbidden traits that helps improve the usefulness of the above approach:</div><div><a href="https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/placement-forbidden-traits.html">https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/placement-forbidden-traits.html</a><br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Many thanks,</div><div>John Garbutt</div><div><br></div><div>IRC: johnthetubaguy</div><div><br></div></div></div></div></div></div>