Open Stack

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 
>>> 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?
> 
> 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 
CUSTOM_BOOT_MODE_BIOS [1].

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 
[2]. 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. :(

-jay

[1] 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 
there.

[2] 
https://review.openstack.org/#/c/504952/16/specs/approved/deploy-templates.rst