Open Stack

On 06/06/13 12:24 +1000, Angus Salkeld wrote:
>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'}}}
>

Instead of "Fn::template" this should be something like:
Fn::DescribeStackResource
to indicate that we are retrieving a parsed template not a raw one
as it is important in which stack (must be in the parent) the metadata is parsed
else we will not be able to resolve the references from the child
stack.

>
>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
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev