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
