Open Stack

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