Open Stack

Excerpts from Thomas Spatzier's message of 2013-11-13 00:28:59 -0800:
> Angus Salkeld <asalkeld at redhat.com> wrote on 13.11.2013 00:22:44:
> > From: Angus Salkeld <asalkeld at redhat.com>
> > To: openstack-dev at lists.openstack.org,
> > Date: 13.11.2013 00:25
> > Subject: Re: [openstack-dev] [Heat] HOT software configuration
> > refined after design summit discussions
> >
> > On 12/11/13 10:32 -0800, Clint Byrum 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 discussionswe
> 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]}
> >
> >
> > This is what Thomas defined, with one optimisation.
> > - The webconfig is a yaml template.
> >
> > As you say the component is static - if so why even put it inline in
> > the template (well that was my thinking, it seems like a template not
> > really a resource).
> 
> Yes, exactly. Our idea was to put it in its own file since it is really
> static and having it in its own file makes it much more reusable.
> With 'WebConfig' defined inline in the template as in the snippet above,
> you will have to update many template files where you use the component,
> whereas you will only have to touch one place when it is in its own file.
> Ok, the example above looks simple, but in reality we will see more complex
> sets of parameters etc.
> Maybe for very simple use cases, we can allow a shortcut of inlining it in
> the template (I mentioned this in the wiki) and avoid the need for a
> separate file.
> 

I think I understand now, and we're all basically on the same page. As
usual, I was confused by the subtleties.

I think the in-line capability is critical to have in the near-term
plan, but would +2 an implementation that left it out at the beginning.

Before we "ratify" this and people run off and write code, I'd like to
present my "problems" in TripleO and try to see if I can express them
using the spec you've laid out. Will try and do that in the next couple
of days.