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

Marios Andreou marios at redhat.com
Fri Jan 27 14:35:39 UTC 2017


On 27/01/17 16:23, Dan Prince wrote:
> On Wed, 2017-01-25 at 14:59 +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.
> 
> 
> Nice catch on the old vendor hieradata. I clearly missed those

for the record... actually thanks to slagle - see discussion at
https://review.openstack.org/#/c/424715

> interfaces for the in-tree extraconfig data when doing these conversion
> (sorry about that). Would be nice to get some sort of coverage on these
> interfaces I guess.
> 
> The new hook uses Json and is much cleaner. We were accumulating a lot
> of hacks in t-h-t to work around deficiencies with the old o-a-c YAML
> element mechanism. What this means is a conversion tool is hard. Not
> impossible, but might not get 100% of the cases I think due to the
> differences in how YAML and Json can handle arrays and such with all
> the conversions going on.
> 
> Updating the rest of the in-tree interfaces (like you have done) should
> get most of it. For any out of tree extraconfig code that relies on the
> old heira element would it be reasonable to fail-fast instead? There
> isn't a great place to do this unfortunately but a couple of options:
> 
> 1) in the agent hook itself: https://review.openstack.org/#/c/426241/1
> 
> 2) in the old hiera hook: https://review.openstack.org/#/c/425955/
> 
> Option #1 handles signals more nicely but couples the old and new
> implementations a bit with the extra check. Option #2 doesn't currently
> handle signaling nicely (as shardy pointed out in the review).

fwiw #1 makes more sense to me (I didn't see that until just now, after
having reviewed #2 first thing today) just so the operator gets an early
(earlier at least) exit with some error message.

thanks

> 
> Dan
> 
>>
>> 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, marios
>>
>> [1] https://review.openstack.org/#/c/379733/
>> [2]
>> https://review.openstack.org/#/c/424715/2/extraconfig/tasks/newton_oc
>> ata_upgrade_init_common.sh
>> [3] https://review.openstack.org/#/c/384757/
>> [4] https://review.openstack.org/#/c/425154/
>>
>> _____________________________________________________________________
>> _____
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
>> cribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 




More information about the OpenStack-dev mailing list