On Apr 14, 2014, at 8:08 AM, Rabi Mishra <[email protected]> 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. IIRC implementing something like this had been discussed quite a while back. I think we discussed the possibility of using web hooks and a defined api/payload in place of the SNS/SQS type stuff. I don't think it ever made it to the backlog, but I'd be happy to discuss further design and maybe add a design session to the summit if you're unable to make it. > 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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
