Hi,

Steven Hardy <sha...@redhat.com> writes:

> 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've created a bug to make sure this isn't forgotten before the release:

  https://bugs.launchpad.net/tripleo/+bug/1659540

>
> 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.

This would be ideal, and would remove the need for the previous bug.

Thanks,

>
> Thanks!
>
> Steve
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Sofer Athlan-Guyot

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to