[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