On 18.05.17 15:02, Mehdi Abaakouk wrote:
On Thu, May 18, 2017 at 11:26:41AM +0200, Lance Haig wrote:

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 alarms
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:

https://review.openstack.org/#/c/465817/

I can't really do the others, I don't have enough knowledge in
Mistral/Senlin/Openshift.
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.

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.


How many previous version do you want to support in this repos ? I doubt it's more of 2-3 cycles, you may just fixes all autoscaling/autohealing templates
today.

I would say that we look to support whatever current versions of heat are supported. 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.

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 using heat.

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.

Thanks

Lance

__________________________________________________________________________
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

Reply via email to