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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev