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

[Dan Prince]

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.

Dan