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
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
