Open Stack

On 10/16/2013 02:21 PM, 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.
>
I think users should be told that it is possible but foolhardy to mix CM
tools in a single server. The exception to this *might* be allowing one
Heat::CloudInit (or Heat::SoftwareConfig) component to install the other
CM tool on a pristine image before running the other components that use
that tool.

Initially I thought that each component type should be able to ensure
that its CM tool is installed before invoking that tool. The realities
of doing this the right way all the time are difficult though[1] so I've
backed away from this for now. It can always be added as an enhancement
later. In the meantime users are free to build images that have all
required prerequisites, or install them with a Heat::CloudInit (or
Heat::SoftwareConfig) component on boot.

> 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).
>
A stated goal of the heat template format is that it be fit-for-use by
humans. Pre-processing is a perfectly valid technique for other services
that use heat and we encourage that. However if the pre-processing is to
work around usability issues in the template format I would rather focus
on fixing those issues.

[1] Currently the most reliable way of installing heat-cfntools on any
arbitrary pristine image is in a venv
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131016/d581f0f4/attachment.html>