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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ 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