[openstack-dev] [heat] Custom Resource
Steven Hardy
shardy at redhat.com
Mon Apr 14 11:01:36 UTC 2014
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
More information about the OpenStack-dev
mailing list