Open Stack

On 18/07/14 06:02, Dimitri Mazmanov wrote:
>
> On 18/07/14 11:20, "Steven Hardy" <shardy at redhat.com> wrote:
>
>> On Fri, Jul 18, 2014 at 09:02:33AM +0000, Dimitri Mazmanov wrote:
>>> Hi,
>>> I¹m working on the following use-case:
>>> I have a stack template containing a custom resource - my_res - that
>>> upon
>>> handle_create invokes creation of another set of resources [r1, r2, r3,
>>> ...] (not expressed in the template). These newly created resources are
>>> not associated with the stack. The goal is to include them into the
>>> existing stack.
>>>
>>> My idea was to perform stack adopt on r1, r2, r3, etc inside
>>> handle_create
>>> of my_res.
>>>
>>> handle_create
>>>    create my_res
>>>    find r1, r2, ...
>>>    for each r in [r1, r2, Š]
>>>       my_res.stack.adopt r
>>>
>>> Is this ok or a terrible, terrible idea?
>>
>> Pretty much sounds like a terrible idea to me ;)

I'm with Steve, but you probably knew I would say that ;)

> Doh :)
>
>>
>> More information is needed to fully understand what you're trying to do,
>> but IMO having a hidden nested stack created like this is highly likely to
>> end up in a buggy mess, and having heat create resources not defined in
>> any
>> template is basically always the wrong thing to do.
>
> I should have clarified this part. Heat creates only the custom resource
> (my_res). The r1/r2/r3 set is created as a consequence, not by Heat. So
> Heat has no idea what’s happening in the background.
> Why would it end up in a buggy mess? Heat creates a stack and then calls
> stack adopt on a few resources. If not this, what is the proper usage of
> stack adopt operation then?

"Proper" usage is to adopt a whole stack at once. So if you created a 
separate nested stack with a fixed template and adopted the resources 
into that, it would be less susceptible to the kind of chaos that Steve, 
I think correctly, predicts.

>> If you want to create a stack which contains some existing resources, I'd
>> do something like create a stack containing everything except r1/r2/r3,
>> then abandon it, modify the abandon data to add the existing resources you
>> want to adopt, then adopt the stack using the modified data.
>
> The goal is to keep the create and adopt operations in a single call to
> make the flow look like normal stack deployment (the user clicks Deploy)
> without having to perform heat calls manually.

You don't mention what you're wanting to do with these resources later, 
once you have adopted them? On the face of it, it sounds weird because 
the dependencies will be backwards. If you're not using them for 
anything else and just want to keep track of them to delete then that 
doesn't matter (and a nested stack will probably work for you)... but it 
also makes no sense to adopt them into a stack in that case. Just delete 
them when you delete the resource that created them.

>> Of course it's much better to just create everything via a heat template,
>> but if you have to adopt these existing resources, that may be one way to
>> do it.  More information on the specifics of what you're trying to achieve
>> would help us advise more :)
>
> I have a custom neutron port. When neutron creates this port it also
> creates several networks associated with this port. As the result the
> created networks theoretically belong to the created stack, but in reality
> are not related to it until the stack adopts them.

I suspect that Neutron may have followed a sort of tradition in the 
networking industry of creating resources at the point of need like 
this. (Speculation: this may have roots in IOS, where the user cannot 
control the order that configuration will be loaded on boot.) 
Unfortunately that does not play nicely at all with a service like Heat, 
where it figures out the order for you, but only if you explicitly 
specify all of the resources and their relationships in the template. 
The Neutron API makes this impossible in many cases.[1]

It seems to me that the issues is Neutron's to fix. If it implicitly 
creates a resource then it should implicitly remove it again when 
nothing requires it any longer. If it doesn't, you can maybe cover up 
the problem using Heat, but you're not actually solving it. Recently 
we've starting adding richer attributes to Neutron resources to allow us 
to get at the data from the implicitly created stuff that we'd like to 
reference explicitly but can't. I'd be open to more of that, since 
everyone benefits (not just those willing/able to hack together custom 
resources).

And of course I'd be even more open to a new Neutron API that actually 
works with orchestration :)

cheers,
Zane.


[1] See also 
http://lists.openstack.org/pipermail/openstack-dev/2014-April/032098.html