Open Stack

Excerpts form Clint Byrum's message on 12.11.2013 19:32:50:
> From: Clint Byrum <clint at fewbar.com>
> To: openstack-dev <openstack-dev at lists.openstack.org>,
> Date: 12.11.2013 19:35
> Subject: Re: [openstack-dev] [Heat] HOT software configuration
> refined after design summit discussions
>
> Excerpts from Thomas Spatzier's message of 2013-11-11 08:57:58 -0800:
> >
> > Hi all,
> >
> > I have just posted the following wiki page to reflect a refined
proposal
<snip>
> Hi Thomas, thanks for spelling this out clearly.
>
> I am still -1 on anything that specifies the place a configuration is
> hosted inside the configuration definition itself. Because configurations
> are encapsulated by servers, it makes more sense to me that the servers
> (or server groups) would specify their configurations. If changing to a

IMO the current proposal does _not_ the concrete hosting inside component
definition. The component definition is in this external template file and
all we do is give it a pointer to the server at deploy time so that the
implementation can perform whatever is needed to perform at that time.
The resource in the actual template file is like the intermediate
association resource you are suggesting below (similar to what
VolumeAttachment does), so this is the place where you say which component
gets deployed where. This represents a concrete use of a software
component. Again, all we do is pass in a pointer to the server where _this
use_ of the software component shall be installed.

> more logical model is just too hard for TOSCA to adapt to, then I suggest
> this be an area that TOSCA differs from Heat. We don't need two models

The current proposal was done completely unrelated to TOSCA, but really
just a try to have a pragmatic approach for solving the use cases we talked
about. I don't really care in which directions the relations point. Both
ways can be easily mapped to TOSCA. I just think the current proposal is
intuitive, at least to me. And you could see it as kind of a short notation
that avoids another association class.

> for communicating configurations to servers, and I'd prefer Heat stay
> focused on making HOT template authors' and users' lives better.
>
> I have seen an alternative approach which separates a configuration
> definition from a configuration deployer. This at least makes it clear
> that the configuration is a part of a server. In pseudo-HOT:
>
> resources:
>   WebConfig:
>     type: OS::Heat::ChefCookbook
>     properties:
>       cookbook_url: https://some.test/foo
>       parameters:
>         endpoint_host:
>           type: string
>   WebServer:
>     type: OS::Nova::Server
>     properties:
>       image: webserver
>       flavor: 100
>   DeployWebConfig:
>     type: OS::Heat::ConfigDeployer
>     properties:
>       configuration: {get_resource: WebConfig}
>       on_server: {get_resource: WebServer}
>       parameters:
>         endpoint_host: {get_attribute: [ WebServer, first_ip]}

The DeployWebConfig association class actually is the 'mysql' resource in
the template on the wiki page. See the Design alternative section I put it.
That would be fine with me as well.

>
<snip>