[openstack-dev] [TripleO] Strategy for testing and merging the merge.py-free templates
Jay Dobies
jason.dobies at redhat.com
Tue Oct 14 12:54:21 UTC 2014
On 10/14/2014 04:55 AM, Tomas Sedovic wrote:
> Hi everyone,
>
> As outlined in the "Remove merge.py"[1] spec, Peter Belanyi and I have
> built the templates for controller, nova compute, swift and cinder nodes
> that can be deploying directly to Heat (i.e. no merge.py pass is
> necessary).
>
> The patches:
>
> https://review.openstack.org/#/c/123100/
> https://review.openstack.org/#/c/123713/
>
> I'd like to talk about testing and merging them.
>
> Both Peter and myself have successfully run them through devtest
> multiple times. The Tuskar and TripleO UI folks have managed to hook
> them up to the UI and make things work, too.
>
> That said, there is a number of limitations which don't warrant making
> them the new default just yet:
>
> * Juno Heat is required
> * python-heatclient version 0.2.11 is required to talk to Heat
> * There is currently no way in Heat to drop specific nodes from a
> ResourceGroup (say because of a hardware failure) so the "ellision"
> feature from merge.py is not supported yet
> * I haven't looked into this yet, but I'm not very optimistic about an
> upgrade path from the merge.py-based templates to the heat-native ones
>
> On the other hand, it would be great if we could add them to devtest as
> an alternative and to have them exercised by the CI. It would make it
> easier to keep them in sync and to iron out any inconsistencies.
>
>
> James Slagle proposed something like this when I talked to him on IRC:
>
> 1. teach devtest about the new templates, driven by a
> OVERCLOUD_USE_MERGE_PY switch (defaulting to the merge.py-based templates)
> 2. Do a CI run of the new template patches, merge them
> 3. Add a (initially non-voting?) job to test the heat-only templates
> 4. When we've resolved all the issues stopping up from the switch, make
> the native templates default, deprecate the merge.py ones
>
>
> This makes sense to me. Any objections/ideas?
+1
I like the idea of getting them into CI as soon as possible without
flipping the default and breaking everyone :)
> Thanks,
> Tomas
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
More information about the OpenStack-dev
mailing list