Open Stack

A very quick note that this dovetails with the version discovery work I'm driving currently. Heat should use clients which know how to talk to many versions OpenStack and can differentiate on their own. When we get to capability discovery as well then Heat can even be aware of what is supported and what is not across its own engine.


-          Gabriel

From: Steve Baker [mailto:sbaker at redhat.com]
Sent: Tuesday, May 21, 2013 7:46 PM
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] [Heat] Running latest Heat against older OpenStacks

At the Design Summit a number of people mentioned that they would like to run the latest release of Heat against their own installation of an older OpenStack release.

As a project we're not against this in principle, however we don't currently have the resources to develop or test against anything other than latest OpenStack (unless by coincidence of the provided dev environment).

It would be very useful to us for people to describe their use cases for running Heat against older OpenStack installations - feel free to contribute them to this thread.

We're about to have the beginnings of some Tempest integration tests[1]. I'd like to suggest that these be used as a coordination point for testing latest Heat against private installations. For those running Heat against older OpenStack installations the following would be done:
- Run the heat tempest tests against your own Heat/OpenStack environment
- Participate in finding and fixing regressions that appear in your own environment (bug reports good, failing tempest tests better, fixes best)

There are a couple of caveats worth mentioning:
- the transition from our own CloudWatch-lite alarming to ceilometer might be messy - there might be a limit to how much we can mitigate the pain
- it seems reasonable for latest heat to depend on the latest released client libs. Any regressions involving recent client libs running on older APIs probably need to be taken to those client projects.

In the medium to long term we have some roadmap items which have implications here, including:
- a local installation of Heat configured to point at a public OpenStack cloud - auth and other quirks of each cloud need to be handled
- a single installation of Heat which can deploy to multiple clouds (private and public)
- Heat DSL concepts [2] of Providers and Environments should allow Heat to change any aspect of its behavior to support older installations.

[1] https://review.openstack.org/#/q/topic:bp/add-basic-heat-tests,n,z
[2] https://wiki.openstack.org/wiki/Heat/DSL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130522/5c007ca4/attachment.html>