[openstack-dev] [Heat] HOT software configuration refined after design summit discussions

Thomas Spatzier thomas.spatzier at de.ibm.com
Wed Nov 13 08:23:40 UTC 2013

Georgy Okrokvertskhov <gokrokvertskhov at mirantis.com> wrote on 12.11.2013
> From: Georgy Okrokvertskhov <gokrokvertskhov at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>,
> Date: 12.11.2013 21:29
> Subject: Re: [openstack-dev] [Heat] HOT software configuration
> refined after design summit discussions
> Hi,
> I agree with Clint that component placement specified inside
> component configuration is not a right thing. I remember that mostly
> everyone agreed that "hosted_on" should not be in HOT templates.
> When one specify placement explicitly inside  a component definition
> it prevents the following:
> 1. Reusability - you can't reuse component without creating its
> definition copy with another placement parameter.

See my reply to Clint's mail. The deployment location in form of the
"server" reference is _not_ hardcoded in the component definition. All we
do is to provide a pointer to the server where a software shall be deployed
at deploy time. You can use a component definition in many place, and in
each place where you use it you provide it a pointer to the target server.

> 2. Composability - it will be no clear way to express composable
> configurations. There was a clear way in a template showed during
> design session where server had a list of components to be placed.

I think we have full composability with the "deployment" resources that
mark uses of software component definitions.

> 3. Deployment order - some components should be placed in strict
> order and it will be much easier just make an ordered list of
> components then express artificial dependencies between them just
> for ordering.

With the "deployment" resources and Heat's normal way of handling
dependencies between any resources, we should be able have proper ordering.
I agree that strict ordering is probably the most easy way of doing it, but
we have implementations that do deployment in a more flexible manner
without any problems.

> Thanks
> Georgy

> On Tue, Nov 12, 2013 at 10:32 AM, Clint Byrum <clint at fewbar.com> wrote:
> 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
> > for HOT software configuration based on discussions at the design
> > last week. Angus also put a sample up in an etherpad last week, but we
> > not have enough time to go thru it in the design session. My write-up
> > based on Angus' sample, actually a refinement, and on discussions we
had in
> > breaks, plus it is trying to reflect all the good input from ML
> > and Steve Baker's initial proposal.
> >
> > https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-WIP
> >
> > Please review and provide feedback.

> 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
> 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
> 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]}
> I have implementation questions about both of these approaches though,
> as it appears they'd have to reach backward in the graph to insert
> their configuration, or have a generic bucket for all configuration
> to be inserted. IMO that would look a lot like the method I proposed,
> which was to just have a list of components attached directly to the
> server like this:
> components:
>   WebConfig:
>     type: Chef::Cookbook
>     properties:
>       cookbook_url: https://some.test/foo
>       parameters:
>         endpoing_host:
>           type: string
> resources:
>   WebServer:
>     type: OS::Nova::Server
>     properties:
>       image: webserver
>       flavor: 100
>     components:
>       - webconfig:
>         component: {get_component: WebConfig}
>         parameters:
>           endpoint_host: {get_attribute: [ WebServer, first_ip ]}
> Of course, the keen eye will see the circular dependency there with the
> WebServer trying to know its own IP. We've identified quite a few use
> cases for self-referencing attributes, so that is a separate problem we
> should solve independent of the template composition problem.
> Anyway, I prefer the idea that parse-time things are called components
> and run-time things are resources. I don't need a database entry for
> "WebConfig" above. It is in the template and entirely static, just
> sitting there as a reusable chunk for servers to pull in as-needed.
> Anyway, I don't feel that we resolved any of these issues in the session
> about configuration at the summit. If we did, we did not record them
> in the etherpad or the blueprint. We barely got through the prepared
> list of requirements and only were able to spell out problems, not
> any solutions. So forgive me if I missed something and want to keep on
> discussing this.
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

> --
> Georgy Okrokvertskhov
> Technical Program Manager,
> Cloud and Infrastructure Services,
> Mirantis
> http://www.mirantis.com
> Tel. +1 650 963 9828
> Mob. +1 650 996 3284_______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list