[openstack-dev] [Openstack-operators] [ironic] [nova] [tripleo] Deprecation of Nova's integration with Ironic Capabilities and ComputeCapabilitiesFilter

Jay Pipes jaypipes at gmail.com
Mon Oct 1 12:02:30 UTC 2018

On 10/01/2018 04:36 AM, John Garbutt wrote:
> On Fri, 28 Sep 2018 at 00:46, Jay Pipes <jaypipes at gmail.com 
> <mailto:jaypipes at gmail.com>> wrote:
>     On 09/27/2018 06:23 PM, Matt Riedemann wrote:
>      > On 9/27/2018 3:02 PM, Jay Pipes wrote:
>      >> 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. :(
>      >
>      > We talked about this in Dublin through right? We said a good
>     thing to do
>      > would be to have some kind of template/profile/config/whatever
>     stored
>      > off in glare where schema could be registered on that thing, and
>     then
>      > you pass a handle (ID reference) to that to nova when creating the
>      > (baremetal) server, nova pulls it down from glare and hands it
>     off to
>      > the virt driver. It's just that no one is doing that work.
>     No, nobody is doing that work.
>     I will if need be if it means not hacking the placement API to serve
>     this purpose (for which it wasn't intended).
> Going back to the point Mark Goddard made, there are two things here:
> 1) Picking the correct resource provider
> 2) Telling Ironic to transform the picked node in some way
> Today we allow the use Capabilities for both.
> I am suggesting we move to using Traits only for (1), leaving (2) in 
> place for now, while we decide what to do (i.e. future of "deploy 
> template" concept).
> It feels like Ironic's plan to define the "deploy templates" in Ironic 
> should replace the dependency on Glare for this use case, largely 
> because the definition of the deploy template (in my mind) is very 
> heavily related to inspector and driver properties, etc. Mark is looking 
> at moving that forward at the moment.

That won't do anything about the flavor explosion problem, though, right 


More information about the OpenStack-dev mailing list