[openstack-dev] [TripleO] Strategy for testing and merging the merge.py-free templates

Tomas Sedovic tsedovic at redhat.com
Tue Oct 14 08:55:30 UTC 2014


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?

Thanks,
Tomas



More information about the OpenStack-dev mailing list