Open Stack

On 26/04/13 03:35, Angus Salkeld wrote:
>
> So this does not need the provider except when you what if you want to
> control
> the implementation:
>
>    heat publish-template --private \
> https://github.com/zaneb/hot-templates/raw/master/db.templ --type
> "AWS::RDS::DBInstance"
>    heat template-list
>    AWS::RDS::DBInstance    builtin
>    AWS::RDS::DBInstance http://..../foo.template
>    AWS::RDS::DBInstance
> https://github.com/zaneb/hot-templates/raw/master/db.templ
> when I create a stack I do something like the following:
>
>    heat create teststack -f myapp.template -P
> "InstanceType=m1.large;KeyName=heat_key" --use
> "AWS::RDS::DBInstance=http://..../foo.template"
>
> That looks messy so it might make sense to use the environment idea to
> define the mapping of ResourceType to nested stack.
>
>
> General question:
> Do we want to support different providers of the same Resource type
> within the same template? - I assume yes.
>
>
> If I were to suggest baby steps:
> 1) have property valid on all resources "provider_url"
>     prove you can start an inbuilt resource from a
>     nested stack template with all the property validation goodness.
> 2) add "heat publish-template/list-templates/.."
> 3) add the environment concept to make defining the mapping more user
>     friendly - this would just set the "provider_url" property on the
>     resources so you don't have to edit templates or have super long
>     command lines.

+1

I think the environment stuff needs a similar plan drawn up, but to a 
first approximation this was my thought too - the environment is a 
particular set of Plugins, Providers and Backends. You'd have the option 
of selecting which environment you want when you create the stack.

cheers,
Zane.