[Openstack-operators] [openstack-dev] [ironic] [nova] [tripleo] Deprecation of Nova's integration with Ironic Capabilities and ComputeCapabilitiesFilter
jaypipes at gmail.com
Thu Sep 27 20:02:58 UTC 2018
On 09/26/2018 05:48 PM, melanie witt wrote:
> On Tue, 25 Sep 2018 12:08:03 -0500, Matt Riedemann wrote:
>> 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
>>> 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
>>> and if any of these are found, we report a warning meaning those
>>> need to be updated to use traits rather than capabilities. Would
>>> that be
>>> I like the idea of a warning, but there are features that have not yet
>>> moved to traits:
>>> There is a more general plan that will help, but its not quite ready
>>> 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?
> I would like to know the answer to this as well.
In short, traits were never designed to be key/value pairs. They are
simple strings indicating boolean capabilities.
Ironic "capabilities" are key/value metadata pairs. *Some* of those
Ironic "capabilities" are possible to create as boolean traits.
For example, you can change the boot_mode=uefi and boot_mode=bios Ironic
capabilities to be a trait called CUSTOM_BOOT_MODE_UEFI or
Other Ironic "capabilities" are not, in fact, capabilities at all.
Instead, they are just random key/value pairs that are not boolean in
nature nor do they represent a capability of the baremetal hardware.
A great example of this would be the proposed "deploy template" from
. This is nothing more than abusing the placement traits API in order
to allow passthrough of instance configuration data from the nova flavor
extra spec directly into the nodes.instance_info field in the Ironic
database. It's a hack that is abusing the entire concept of the
placement traits concept, IMHO.
We should have a way *in Nova* of allowing instance configuration
key/value information to be passed through to the virt driver's spawn()
method, much the same way we provide for user_data that gets exposed
after boot to the guest instance via configdrive or the metadata service
API. What this deploy template thing is is just a hack to get around the
fact that nova doesn't have a basic way of passing through some collated
instance configuration key/value information, which is a darn shame and
I'm really kind of annoyed with myself for not noticing this sooner. :(
 As I've asked for in the past, it would be great to have Ironic
contributors push patches to the os-traits library for standardized
baremetal capabilities like boot modes. Please do consider contributing
More information about the OpenStack-operators