openstack team mailing list archive
Mailing list archive
Fwd: [openstack-dev] [Heat] Running latest Heat against older OpenStacks
Steve Baker <sbaker@xxxxxxxxxx>
Thu, 23 May 2013 09:38:33 +1200
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5
Reposting here since this is mostly user related.
-------- Original Message --------
Subject: [openstack-dev] [Heat] Running latest Heat against older
Date: Wed, 22 May 2013 14:46:19 +1200
From: Steve Baker <sbaker@xxxxxxxxxx>
Reply-To: OpenStack Development Mailing List
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
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.
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  of Providers and Environments should allow Heat
to change any aspect of its behavior to support older installations.