On 10/01/2018 04:36 AM, John Garbutt wrote:
On Fri, 28 Sep 2018 at 00:46, Jay Pipes <jaypi...@gmail.com
<mailto:jaypi...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
