Re: [rdo-list] python-heat-agent subpackage from openstack-heat-templates

On Tue, 2016-08-23 at 11:17 +1200, Steve Baker wrote: > Hi All > > I would like to get some feedback on this packaging change: > https://review.rdoproject.org/r/#/c/1909 > > This change creates a new subpackage python-heat-agent out of > openstack-heat-templates. > > Currently image building or boot configuration has to do a number of > non-obvious steps to end up with a server ready to perform heat- > driven > software deployments. > > The package python-heat-agent installs all dependencies and files > required to do this, resulting in a boot config on a pristine image > being as simple as: > > yum -y install https://www.rdoproject.org/repos/rdo-release.r > pm > yum -y install python-heat-agent > systemctl enable os-collect-config > systemctl start --no-block os-collect-config > > python-heat-agent installs one hook which allows configuration via > heat templates. The aim is to create another subpackage per > configuration tool hook in heat-templates. So python-heat-agent- > puppet > will install the puppet hook and depend on python-heat-agent and > puppet packages. +1. Moving away from elements for this would be very nice. FWIW, what you've done here would dovetail into the all-in-one Heat undercloud installer effort too in that we could pretty much eliminate the use of instack to bootstrap os-collect-config altogether and just use these subpackages directly. Faster, better, leaner I think.

> This depends on some upstream heat-templates changes: > https://review.openstack.org/#/q/topic:centos-rdo-boot-config > > As far as TripleO goes, this packaging approach has the potential to > eliminate the need for diskimage-builder invoking heat-templates > elements, and further reducing the use of tripleo-image-elements - > I'd like to have a discussion on openstack-dev around whether there > should be a push to remove tripleo-image-elements entirely. +1 to all of this. We've still got some refactoring to do to fully eliminate more of the os-*-config dependencies (os-apply-config, and os-net-config) but I think we are closing in on it.