Open Stack

On Mon, Apr 14, 2014 at 09:08:20AM -0400, Rabi Mishra wrote:
> Hi Steve,
> 
> Thanks a lot for your prompt response. I can't agree more that the CFN custom resource implementation is complex with it's dependency on SNS and SQS. However, it  decouples the implementation of the resource life-cycle from the resource itself. IMO, this has some advantages from the template complexity and flexibility point of view. 
> 
> On choices you mentioned:
> 
> 1. Custom Python Plugins - I do think this is the best approach for my use-cases. However, asking a customer to develop custom plugins and maintaining them can be too much ask(asking their 3rd party tool vendors to do it is even more difficult), than plugging in some of their existing infra script snippets.

Well, yeah I guess, but if you require this level of flexibility then there
is a maintenance cost associated with it, which is the reason for provider
resources, it's a much simpler interface and requires no knowledge of heat
internals to create (it's just a nested stack template).

> 2. Provider Resource - Use of environment files for mapping nested template and exchange of parameters/attributes looks sleek. However, I am yet to understand how to wrap code snippets (many of them existing scripts) for the resource life-cycle in the nested template to achieve these use-cases. 
> 
> With the CFN Custom resource, addition of some bits of code to the existing scripts to parse the JSON snippets based on the stack life-cycle method is what's required. 
> 
> However, my understanding of what's possible with the Provider Resource is limited at the moment. I'll spend more time and go through it before coming back with an answer to the use-case feasibility and constraints.

If the requirement is to run some existing code/scripts, then you may also
want to look at the SoftwareConfig/SoftwareDeployment work, this provides
quite a nice interface to enable not only software configuration but also
running arbitrary "hook scripts" which can invoke whatever code you like
inside an instance, and provide the output for reuse (e.g as input
properties to some other resource)

As an example, here's a template which runs a random shell script and
collects the result:

https://review.openstack.org/#/c/70297/15/hot/software-config/example-templates/example-script-template.yaml

Related to this is a recently discussed idea of a "disposable" instance,
which could be built, do some work, provide an output and then be deleted,
this doesn't currently exist (the instance would remain consuming resources
after your script has run), but could be a future optimisation related to
your use-case, if what you want is some sandboxed way to run some arbitrary
code and collect the output.

Steve