[openstack-dev] [tripleo] tripleo-heat-templates, vendor plugins and the new hiera hook

Steven Hardy shardy at redhat.com
Wed Jan 25 15:32:03 UTC 2017

On Wed, Jan 25, 2017 at 02:59:42PM +0200, Marios Andreou wrote:
> Hi, as part of the composable upgrades workflow shaping up for Newton to
> Ocata, we need to install the new hiera hook that was first added with
> [1] and disable the old hook and data as part of the upgrade
> initialization [2]. Most of the existing hieradata was ported to use the
> new hook in [3]. The deletion of the old hiera data is necessary for the
> Ocata upgrade, but it also means it will break any plugins still using
> the 'old' os-apply-config hiera hook.
> In order to be able to upgrade to Ocata any templates that define hiera
> data need to be using the new hiera hook and then the overcloud nodes
> need to have the new hook installed (installing is done in [2] as a
> matter of necessity, and that is what prompted this email in the first
> place). I've had a go at updating all the plugin templates that are
> still using the old hiera data with a review at [4] which I have -1 for now.
> I'll try and reach out to some individuals more directly as well but
> wanted to get the review at [4] and this email out as a first step,

Thanks for raising this marios, and yeah it's unfortunate as we've had to
do a switch from the old to new hiera hook this release with out a
transition where both work.

I think we probably need to do the following:

1. Convert anything in t-h-t refering to the old hook to the new (seems you
have this in progress, we need to ensure it all lands before ocata)

2. Write a good release note for t-h-t explaining the change, referencing
docs which show how to convert to use the new hook

3. Figure out a way to make the 99-refresh-completed script signal failure
if anyone tries to deploy with the old hook (vs potentially silently
failing then hanging the deploy, which I think is what will happen atm).

I think ensuring a good error path should mitigate this change, since it's
fairly simple for folks to switch to the new hook provided we can document
it and point to those docs in the error I think.

Be good to get input from Dan on this too, as he might have ideas on how we
could maintain both hooks for one release.



More information about the OpenStack-dev mailing list