Open Stack

On Mon, Apr 14, 2014 at 11:55:11AM -0400, Zane Bitter wrote:
> On 14/04/14 07:01, Steven Hardy wrote:
> >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)
> 
> That's great for composing existing Things, but when you want to
> either deal with a Thing that isn't yet represented by a resource
> (lack of DNSaaS in OpenStack is really hurting us IMO) or to insert
> Actions into the workflow, that doesn't really help.

Sure, I was just trying to provide context to the discussion by starting
with the "Custom Resource" interfaces that we do have, so we can discuss the
use-cases and identify those we don't, rather than starting from the
position that we should just copy what AWS do.

> >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.
> 
> It really doesn't seem complicated at all to me. On every action
> (create/delete/update) you post a message to a Marconi queue with
> some data and a URL, then wait for a response to that URL (i.e. same
> as a WaitCondition, effectively). It sounds like about 50 lines of
> code, and would be completely self-contained except for the part
> that allows resource types starting with "Custom::".
> 
> It's actually my stated opinion that rather than just reimplementing
> the AWS CustomResource, we should add these kinds of hooks to
> _every_ resource type (i.e. the functionality would be built in to
> Heat). That would be useful for a wide variety of other purposes,
> such as "breakpoints" for debugging a template, hooks for Murano to
> customise the workflow, confirming resizes/rebuilds of servers, and
> a number of others.
> 
> The main obstacle to that is that Marconi will not be part of the
> integrated release for Juno, and is targeting graduation in time to
> be fully integrated in the K release. However, implementing the
> CustomResource would require some of the same code (so it could give
> us a head-start), would be helpful anyway for compatibility with
> existing CloudFormation templates, and seems entirely reasonable
> given that Marconi is an incubated project.

+1 on doing this in a general way, I'm just saying that if what you care
about is primarily creating a custom resource, you don't necessarily care
about the details of some message protocol, or the fact that responses are
somehow sent via S3, there's a lot of detail in the AWS docs which may not
be relevant to all "Custom Resource" use-cases, so at first glance it
*does* look relatively complex IMO.

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/crpg-walkthrough.html

It's not clear to me why you'd even expect that $third_party_system knows
how to receive SNS notifications, so you might instead want to fire up a VM
with some client on it which knows how to talk to the service directly and
act as a proxy, with lifecycle events causing proxied actions to happen in
response to either some hooks, or template definitions like the actions
list to the SoftwareDeployment resources.

All of which is a way of saying, again, let's get more feedback on the
use-cases, then look at possible solutions rather than by default accepting
the way AWS does it as the optimal solution for Heat.

> >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.
> 
> We should do that as well obviously, but we can't hope to anticipate
> every possible need and provide a resource for it, since resources
> are pretty much reserved for things that the OpenStack API provides.
> Operators can, of course, create plugins for their own non-OpenStack
> services, but custom resources open things up to third-party
> services.

Agreed, I'm just saying lets continue the discussion we're now having and
work out what makes sense natively, given that the requirement
appears to be to enable certain integration with external systems, not
necessarily to provide poratability with AWS's CustomResource.

Cheers,

Steve