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. 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. Regards, Rabi Mishra ----- Original Message ----- > Hi Rabi, > > On Mon, Apr 14, 2014 at 06:44:44AM -0400, Rabi Mishra wrote: > > Hi All, > > > > Recently, I've come across some requirements for external > > integrations/resources that can be managed like stack resources > > (create,update,delete) from the stack. > > > > 1. Adding/Removing DNS records for instances created as part of a stack. > > 2. Integration with IPAM solutions for allocate/release of IPs (IP > > allocation pool for provider network) > > 3. Other custom integration for dynamic parameters to stacks. > > > > IMHO, it would probably make sense to create a custom resource like 'AWS > > CFN Custom Resource'[1] that can be used for these kind of use cases. I > > have created a blueprint[2] for this. > > Heat already has a couple of ways for custom resources to be defined. > > The one which probably matches your requirements best is the "provider > resource" interface, which allows template defined resources to be mapped > to user-definable resource types, via an environment file: > > http://hardysteven.blogspot.co.uk/2013/10/heat-providersenvironments-101-ive.html > http://docs.openstack.org/developer/heat/template_guide/environment.html > > Provider resources can be defined by both users, and deployers (who can use > templates to e.g wrap an existing resource with something like DNS > registration logic, and expose the type transparently to the end-user) > > For deployer requirements not satisfied by provider resources (for example > integration with third-party services), Heat also provides a python plugin > API, which enables deployers to create their own resource plugins as > needed: > > http://docs.openstack.org/developer/heat/pluginguide.html > > Personally, I think these two models provide sufficient flexibility that we > should be able to avoid the burden of maintaining a CFN compatible custom > resource plugin API. I've not looked at it in detail, but the CFN model > you refer to has always seemed pretty complex to me, and seems like > something we don't necessarily want to replicate. > > If there are gaps where things are not yet possible via the provider > resource interface, I'd rather discuss incremental improvements to that > instead of wholesale reimplementation of something compatible with AWS. > > Can you provide any more feedback on your use-cases, and whether the > interfaces I linked can be used to satisfy them? > > Steve > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
