[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
John?
-jay
More information about the OpenStack-dev
mailing list