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