Open Stack

Excerpts from Angus Salkeld's message of 2013-11-12 15:22:44 -0800:
> 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 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]}
> 
> 
> 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).
> 

Doing it in-line or pulled in via some other method, I think making
things composable calls for both.

> >
> >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
> 
> Yeah, it does depend on the implementation. If we use Mistral the
> agent will need to ask Mistral for the tasks that apply to the server.
> 
> $ mistral task-consume \
>   --tags=instance_id=$(my_instance_id);stack_id=$(stack_id)
> 

Actually that makes perfect sense. Thanks. If we have a hidden work-flow
handle for any resources that have need of it passed in much the same
way we pass in the cfn-metadata-server now, that would allow us to write
our work-flow afterward. The image can decide when it wants to start
doing work-flows and can decide to just spin until the work-flow exists
and is enabled. For the tiny-work-flow case of one task it works the
same as the complicated work-flow, so I think this sounds like a
workable plan.. assuming a work-flow service. :)

> >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 ]}
> I'd change this to:
> 
>      components:
>        - webconfig:
>          component: {get_file: ./my_configs/webconfig.yaml}
>          parameters:
>            endpoint_host: {get_attribute: [ WebServer, first_ip ]}
> 
> This *could* be a short hand notation like the volumes property on
> aws instances.
> 

That makes sense.

> >
> >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.
> 
> (aside) I don't like the idea of self ref as it breaks the idea that
>          references are resolved top down. Basically we have to put in
>          a nasty hack to produce broken behaviour (first resolution is
>          bogus and only following resoultions are possibly correct).
> 
> In this case just use the deployer to break your circular dep?
>

Yes I think I have to just accept that it is easier to reason about a
second resource that gathers all of the configuration. Given a simple
work-flow service that allows processing said configuration, I think
this will make as much sense as anything else.

> >
> >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.
> 
> IMO is should just be a template/formatted file.
> 

I'd prefer that we have the ability to pull in a chunk of in-line template
as well. Perhaps that is the template resource, I have not thought that
through. It is not o-k, IMO, to push things off entirely to external
files/urls/"providers", etc. That is just cumbersome and unnecessary for
a common case which is to deploy two things using the same base config
with parameters having different values.

Of course, for my use case of having different topologies reusing bits
of config, it is perfect to have the reusable bits split into different
files.