Open Stack

On Tue, Oct 15, 2013 at 09:21:12PM -0400, Mike Spreitzer wrote:
> Steve Baker <sbaker at redhat.com> wrote on 10/15/2013 06:48:53 PM:
> 
> > From: Steve Baker <sbaker at redhat.com>
> > To: openstack-dev at lists.openstack.org, 
> > Date: 10/15/2013 06:51 PM
> > Subject: [openstack-dev] [Heat] HOT Software configuration proposal
> > 
> > I've just written some proposals to address Heat's HOT software 
> > configuration needs, and I'd like to use this thread to get some 
> feedback:
> > https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config
> 
> In that proposal, each component can use a different configuration 
> management tool.
> 
> > 
> https://wiki.openstack.org/wiki/Heat/Blueprints/native-tools-bootstrap-config
> 
> 
> In this proposal, I get the idea that it is intended that each Compute 
> instance run only one configuration management tool.  At least, most of 
> the text discusses the support (e.g., the idea that each CM tool supplies 
> userdata to bootstrap itself) in terms appropriate for a single CM tool 
> per instance; also, there is no discussion of combining userdata from 
> several CM tools.

IMO it makes no sense to use more than one CM tool on a particular
instance, apart from the case already mentioned by stevebaker where
cloud-init is used to bootstrap some other tool.

>From my discussions with folks so far, they want:
- Something simple and declarative at the template interface
- A way to reuse data and knowledge from existing CM tools
  (Puppet/Chef/...) in a clean an non-complex way

> I agree with the separation of concerns issues that have been raised.  I 
> think all this software config stuff can be handled by a pre-processor 
> that takes an extended template in and outputs a plain template that can 
> be consumed by today's heat engine (no extension to the heat engine 
> necessary).

I think this is the exact opposite of the direction we should be headed.

IMO we should be abstracting the software configuration complexity behind a
Heat resource interface, not pushing it up to a pre-processor (which
implies some horribly complex interfaces at the heat template level)

Steve