On 18/07/14 06:02, Dimitri Mazmanov wrote:
On 18/07/14 11:20, "Steven Hardy" <[email protected]> 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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
