Open Stack

Hi

So I just want to make sure we are solving this problem in the best
way. I don't claim to know the ulitimate solution...

Problem (as I understand it)

Provider templates are templates that are used to implement a resource type.
A current example is our DBInstance or LoadBalancer (although
the templates are inline with the python).

Because the template is created as a stack, it obviously has
a Stack() API, but it is implementing a Resource. So this is
a problem of mismatching API's.

Stack:
  - parameters
  - template
  - some other args (timeouts etc)

Resource:
  - Metadata
  - Properties
  - DeletionPolicy
  - UpdatePolicy
  - DependsOn

Currently we pass the Properties into the parameters (which matches
nicely) DependsOn should not be needed as that is for the creation
ordering. If needed we can pass in the Deletion/Update Policy as
a special parameter (I have no problem with that).

It has been suggested to pass the metadata in as a parameter too.
This doesn't seem like a great fit to me, if there is no other
solution then fine, but first some other options.

1) metadata is not used by heat (or shouldn't be), it is stored and is
    made available to the stack's instances. So surely we don't really need to
    pass in the data just the url to it?
(http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-metadata.html)

2) if (for some reason) the template writer needs actual access to the
    data within the metadata we could have a template function to get at a
    snippet of a resource. So if we pass in the parent arn (as a
    parameter) we could do something like:

{'Fn:select': ['Metadata',
                {'Fn::template': {'Ref': 'parent_resource'}}}


3) Metadata is _mostly_ used by Servers/Instances
    Allow one of the above solutions in the general case but rather encourage the use
    of external (to the resource) files.

    - I think in the case of Instaces this encourages composition as
      most of the real configuration is within the current Metadata (or
      should be). If we had a library/catalog of metadata files then
      you could just include/reference them from within your template.
      Largely reducing the need for metadata in the first place. 

   I'd almost suggest our new native Server resource should not support
   the anything like "AWS::CloudFormation::Init" within the metadata
   but rather a way of getting this from a catalog. 


-Angus