On 10/16/2013 02:21 PM, Mike Spreitzer wrote: > Steve Baker <sba...@redhat.com> wrote on 10/15/2013 06:48:53 PM: > > > From: Steve Baker <sba...@redhat.com> > > To: openstack-dev@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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev