Open Stack

Hi Angus,

some thoughts inline below (I cut out some of the original mail to shorten
it).

Angus Salkeld <asalkeld at redhat.com> wrote on 26.04.2013 03:35:36:

> From: Angus Salkeld <asalkeld at redhat.com>
> To: openstack-dev at lists.openstack.org,
> Date: 26.04.2013 03:36
> Subject: Re: [openstack-dev] [Heat] A concrete proposal for Heat
Providers
>
> On 25/04/13 21:35 +0200, Zane Bitter wrote:
...
> > + Operators can reuse the mechanism to provide versioned Plugins
> >and/or multiple implementations of Resource types.
> >
>
> Nice Zane,
>
> Just to clarify what this gives the user....
>
>
>    vim ~/my_hot_nested_stacks/foo.template
>
>    heat publish-template --private ~/my_hot_nested_stacks/
> foo.template --type "AWS::RDS::DBInstance"
> (returns the url to the template)
>    http://..../foo.template
>
>
> So now we have a user generated nested stack that can replace the
> builtin one (and the mechanism to do the mapping).
>
> now I just use any template that uses a "AWS::RDS::DBInstance"
> resource and my nested stack is used.
>
> 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.

Looks like technically this would work, but agree that this looks strange.
I guess one goal of the DSL work is to make this look more intuitive,
right?
So am I right that in summary the next steps and outcomes of the DSL work
would be:
1) Be able to cover a current CFN template in the new format with equal or
superset functionality, so that CFN can be covered by it. Sounded like
everyone was looking for a neutral, non-CFN-dependent format.
2) Fold in the concepts brought in by Zane to the DSL in a clean way.

Right?

>
>
> 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.

Always an URL (well, URL can be used in way some ways, but post often it's
a pointer to a file), or use provider IDs that I saw at some point?

One additional question I have (not sure if it fits here): Are those nested
stacks treated separated, or does the engine kind of merge them at
deployment time into one large stack? In the latter case, an orchestration
engine could probably do more optimization, or also choose to place things
on the VM if desired. Of course, it can also bring side-effects so it
should probably be configurable.

> 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.
>
>
> More crazy ideas:
> what about starting a db instance as a normal stack and then
> "attaching" to it? It's just a stack after all (it's just already
> running).
>
>    heat stack-create wordpress -f wp.templ -P "..." \
>    --use "AWS::RDS::DBInstance=stack-url"
>
> This way you could reuse services (might need a refcount tho').
> Any one see this as a good idea?

Yeah, that makes a lot of sense and is definitely needed. Instead of
expressing this in the command line, you could also image expressing this
as a parameter/input to a template where you ask the user to either create
a new instance of DBInstance or select from one of the existing ones.

>
> -Angus
>
> >
> >So, in summary, this plan appears to provide real, identified value
> >to users; relies for the most part on existing technology in Heat
> >(nested stacks are actually pretty cool, if I may say so); includes a
> >series of changes required to implement the feature; has zero impact
> >on existing users; does not IMO decrease maintainability of the Heat
> >code base; and is entirely achievable before the Havana feature
> >freeze, which is only ~4 months from now.
> >
> >That said, I am not wedded to any of the particular details of this
> >proposal - though I do regard it as a real proposal, not just a straw
> >man. If anybody has suggestions for where I've got the requirements,
> >concepts or implementation ideas wrong then rip in. But I'd love to
> >hear either a discussion at the level of these concrete details or a
> >competing proposal at a similar level.
> >
> >
> >For easier collation, please categorise your response as follows:
> > (A) I'm appalled at the mere suggestion
> > (B) This just prevents us solving the real problem (please specify)
> > (C) Meh
> > (D) This looks kind of interesting
> > (E) OMG!! UNICORNS!!!
> >
> >;)
> >
> >cheers,
> >Zane.
> >
> >_______________________________________________
> >OpenStack-dev mailing list
> >OpenStack-dev at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>