Hi Steve, I am happy to assist in any way to be honest.
The backwards compatibility is not always correct as I have seen when developing our library of templates on Liberty and then trying to deploy it on Mitaka for example.
As you guys mentioned in our discussions the Networking example I quoted is not something you guys can deal with as the source project affects this.
Unless we can use this exercise to test these and fix them then I am happier.
My vision would be to have a set of templates and examples that are tested regularly against a running OS deployment so that we can make sure the combinations still run. I am sure we can agree on a way to do this with CICD so that we test the fetureset.
I look forward to assisting the community with this. Regards Lance On 15.05.17 16:03, Steven Hardy wrote:
On Mon, May 15, 2017 at 03:21:30AM -0400, Lance Haig wrote:Good to know that there is interest.Thanks for starting this effort - I agree it would be great to see the example templates we provide improved and over time become better references for heat features (as well as being more well tested).I was thinking that we should perhaps create a directory for each openstack version.I'm personally not keen on this - Heat should handle old HOT versions in a backwards compatible way, and we can use the template version (which supports using the release name in recent heat versions) to document the required version e.g if demonstrating some new resource or function. FWIW we did already try something similar in the early days of heat, where we had duplicate wordpress examples for different releases (operating systems not OpenStack versions but it's the same problem). We found that old versions quickly became unmaintained, and ultimately got broken anyway due to changes unrelated to Heat or OpenStack versions.so we start say with a mitaka directory and then move the files there and test them all so that they work with Liberty. Then we can copy it over to Mitaka and do the same but add the extra functionality.While some manual testing each release is better than nothing, honestly I feel like CI testing some (or ideally all) examples is the only way to ensure they're not broken. Clearly that's going to be more work initially, but it'd be worth considering I think. To make this simple for template authors, we could perhaps just create the template with the default parameters, and codify some special place to define the expected ouput values (we could for example have a special expected_output parameter which the CI test consumes and compares after the stack create completes).and then Newton etc... That way if someone is on a specific version they only have to go to a specific directory to get the examples they need.As mentioned above, I think just using the template version should be enough - we could even generate some docs using this to highlight example templates that are specific to a release? Steve __________________________________________________________________________ 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
