Open Stack

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

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 proposal
> > for HOT software configuration based on discussions at the design summit
> > last week. Angus also put a sample up in an etherpad last week, but we
> did
> > not have enough time to go thru it in the design session. My write-up is
> > 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
> discussions
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131112/9eabee44/attachment.html>