On 18.05.17 15:02, Mehdi Abaakouk wrote:
On Thu, May 18, 2017 at 11:26:41AM +0200, Lance Haig wrote:
One of the challenges we have is that we have users who are on
different versions of heat and so if we change the examples to
accommodate the new features then we effectively block them from
being able to use these or learn from them.
This is not only an Aodh/Ceilometer alarm issue. I can confirm that
whatever the resource prefix, this works well.
But an alarm description also contains a query an external API to
retrieve statistics. Aodh alarms are currently able to
query the deprecated Ceilometer-API and the Gnocchi-API. Creating
that query the deprecated Ceilometer-API is obviously deprecated too.
Unfortunately, I have seen that all templates still use the deprecated
Ceilometer-API. Since Ocata, this API don't even run by default.
I just propose an update for one template as example here:
I can't really do the others, I don't have enough knowledge in
I think, it's too late to use term 'new feature' for
Aodh/Telemetry/Gnocchi. It's not new anymore, but current. The current
templates just doesn't work since at least 3 cycles... And the repo
still doesn't have templates that use the current supported APIs.
I think this is what we are trying to address.
Not everyone is on the newest heat version for example The conditionals
in heat will be a new feature for the customers we work with as they are
on much older versions so for people who develop heat and are running
the newest releases these things are no longer new. But for someone like
myself who us trying to assist our customers with using heat everything
newer that what they are running is a new feature.
The heat-examples repo does not have templates that show or explain how
to use the different features of heat and I just want to make sure that
we also remember that some people are using older versions of heat.
I would say that we look to support whatever current versions of heat
In reality most people who are using the examples are not running the
newest version of heat they are running older versions and if we
disregard them then I think it will be a shame.
How many previous version do you want to support in this repos ? I
more of 2-3 cycles, you may just fixes all autoscaling/autohealing
My current focus is on corporate users of heat who want an easy way to
consume openstack without having to do much work. They will in the end
learn more and grow their deployments as they need, so it will be good
to start them off with a good understanding and some best practice when
Our current heat library is written for heat template version 2015-10-15
as this is the most up-to date one our clients use and so I can test
everything we build on that. I don't at the moment have access to
anything newer to test the templates against. This will be the version I
target for now as what i want to do.
Then I will target every newer release of the template versions.
As suggested earlier it might be a good idea to have a stable branch of
the heat-templates that are available for consumption by users.
We can then have a development branch that is used to test against all
new features or development work.
I see that we can get the stable versions working first. and then we can
start on the development branch.
I will start a new thread on how we will structure the new heat-template
repository and if we are going to use the heat-lib repository as part of
the main heat project.
OpenStack Development Mailing List (not for usage questions)