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

The patches:


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?


I like the idea of getting them into CI as soon as possible without flipping the default and breaking everyone :)


OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to