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

Clint Byrum clint at fewbar.com
Tue Nov 12 18:32:50 UTC 2013


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.



More information about the OpenStack-dev mailing list