Re: [openstack-dev] [Heat] Heat template example repository

[Lance Haig]

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

Re: [openstack-dev] [Heat] Heat template example repository

[Mehdi Abaakouk]

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.

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.

--
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [Heat] Heat template example repository

[Lance Haig]

On 18.05.17 08:00, Mehdi Abaakouk wrote:

Hi,

On Mon, May 15, 2017 at 01:01:57PM -0400, Zane Bitter wrote:

On 15/05/17 12:10, Steven Hardy wrote:

On Mon, May 15, 2017 at 04:46:28PM +0200, Lance Haig wrote:

Hi Steve,

I am happy to assist in any way to be honest.


It was great to meet you in Boston, and thanks very much for 
volunteering to help out.


BTW one issue I'm aware of is that the autoscaling template examples 
we have all use OS::Ceilometer::* resources for alarms. We have a 
global environment thingy that maps those to OS::Aodh::*, so at least 
in theory those templates should continue to work, but there are 
actually no examples that I can find of autoscaling templates doing 
things the way we want everyone to do 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 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 we need to have a discussion about what is the most effective 
way forward.


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

Re: [openstack-dev] [Heat] Heat template example repository

[Lance Haig]

On 17.05.17 22:18, Zane Bitter wrote:

On 16/05/17 10:32, Lance Haig wrote:

What if instead of a directory per release, we just had a 'deprecated'
directory where we move stuff that is going away (e.g. anything
relying on OS::Glance::Image), and then deleted them when it
disappeared from any supported release (e.g. LBaaSv1 must be close if
it isn't gone already).


I agree in general this would be good. How would we deal with users who
are running older versions of openstack?
Most of the customers I support have Liberty and newer so I would
perhaps like to have these available as tested.
The challenge for us is that the newer the OStack version the more
features are available e.g. conditionals etc..
To support that in a backwards compatible fashion is going to be tough I
think. Unless I am missing something.


'stable' branches could achieve that, and it's the most feasible way 
to actually CI test them against older releases anyway.

Ok this sounds good. We just need to see if it is feasible to implement.



As we've proven, maintaining these templates has been a challenge
given the
available resources, so I guess I'm still in favor of not duplicating
a bunch
of templates, e.g perhaps we could focus on a target of CI testing
templates on the current stable release as a first step?


I'd rather do CI against Heat master, I think, but yeah that sounds
like the first step. Note that if we're doing CI on old stuff then
we'd need to do heat-templates stable branches rather than
directory-per-release.

With my suggestion above, we could just not check anything in the
'deprecated' directory maybe?

I agree in part.
If we are using the heat examples to test the functionality of the
master branch then that would be a good idea.
If we want to provide useable templates for users to reference and use
then I would suggest we test against stable.


The downside of that is you can't add a template that uses a new 
feature in Heat until after the next release (which includes that 
feature).


I think the answer here is to have stable heat-templates test against 
stable heat and master against master.

Agree completely.



I am sure we could find a way to do both.
I would suggets that we first get reliable CICD running on the current
templates and fix what we can in there.
Then we can look at what would be a good way forward.

I am just brain dumping so any other ideas would also be good.



As you guys mentioned in our discussions the Networking example I
quoted is
not something you guys can deal with as the source project affects
this.

Unless we can use this exercise to test these and fix them then I am
happier.

My vision would be to have a set of templates and examples that are
tested
regularly against a running OS deployment so that we can make sure 
the

combinations still run. I am sure we can agree on a way to do this
with CICD
so that we test the fetureset.


Agreed, getting the approach to testing agreed seems like the first
step -
FYI we do already have automated scenario tests in the main heat tree
that
consume templates similar to many of the examples:

https://github.com/openstack/heat/tree/master/heat_integrationtests/scenario 




So, in theory, getting a similar test running on heat_templates
should be
fairly simple, but getting all the existing templates working is
likely to
be a bigger challenge.


Even if we just ran the 'template validate' command on them to check
that all of the resource types & properties still exist, that would be
pretty helpful. It'd catch of of the times when we break backwards
compatibility so we can decide to either fix it or deprecate/remove
the obsolete template. (Note that you still need all of the services
installed, or at least endpoints in the catalog, for the validation to
work.)


So apparently Thomas already implemented this (nice!). The limitation 
is that we're ignoring errors where the template contains a resource 
where the endpoint is not in the service catalog. That's likely to 
mean a lot of these templates aren't _really_ getting tested.


In theory all we have to do to fix that is add endpoints for all of 
them in the catalog (afaik we shouldn't need to actually run any of 
the services).


If we have the ability to have "offline" endpoints to validate against 
this would make CICD for the templates much easier.
It would be good then to have this available for people who are 
developing on a laptop when offline.


I hope we are able to do this.

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

Re: [openstack-dev] [Heat] Heat template example repository

[Mehdi Abaakouk]

Hi,

On Mon, May 15, 2017 at 01:01:57PM -0400, Zane Bitter wrote:

On 15/05/17 12:10, Steven Hardy wrote:

On Mon, May 15, 2017 at 04:46:28PM +0200, Lance Haig wrote:

Hi Steve,

I am happy to assist in any way to be honest.


It was great to meet you in Boston, and thanks very much for 
volunteering to help out.


BTW one issue I'm aware of is that the autoscaling template examples 
we have all use OS::Ceilometer::* resources for alarms. We have a 
global environment thingy that maps those to OS::Aodh::*, so at least 
in theory those templates should continue to work, but there are 
actually no examples that I can find of autoscaling templates doing 
things the way we want everyone to do 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 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.

Cheers,

--
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [Heat] Heat template example repository

[Zane Bitter]

On 16/05/17 10:32, Lance Haig wrote:

What if instead of a directory per release, we just had a 'deprecated'
directory where we move stuff that is going away (e.g. anything
relying on OS::Glance::Image), and then deleted them when it
disappeared from any supported release (e.g. LBaaSv1 must be close if
it isn't gone already).


I agree in general this would be good. How would we deal with users who
are running older versions of openstack?
Most of the customers I support have Liberty and newer so I would
perhaps like to have these available as tested.
The challenge for us is that the newer the OStack version the more
features are available e.g. conditionals etc..
To support that in a backwards compatible fashion is going to be tough I
think. Unless I am missing something.


'stable' branches could achieve that, and it's the most feasible way to 
actually CI test them against older releases anyway.



As we've proven, maintaining these templates has been a challenge
given the
available resources, so I guess I'm still in favor of not duplicating
a bunch
of templates, e.g perhaps we could focus on a target of CI testing
templates on the current stable release as a first step?


I'd rather do CI against Heat master, I think, but yeah that sounds
like the first step. Note that if we're doing CI on old stuff then
we'd need to do heat-templates stable branches rather than
directory-per-release.

With my suggestion above, we could just not check anything in the
'deprecated' directory maybe?

I agree in part.
If we are using the heat examples to test the functionality of the
master branch then that would be a good idea.
If we want to provide useable templates for users to reference and use
then I would suggest we test against stable.


The downside of that is you can't add a template that uses a new feature 
in Heat until after the next release (which includes that feature).


I think the answer here is to have stable heat-templates test against 
stable heat and master against master.



I am sure we could find a way to do both.
I would suggets that we first get reliable CICD running on the current
templates and fix what we can in there.
Then we can look at what would be a good way forward.

I am just brain dumping so any other ideas would also be good.



As you guys mentioned in our discussions the Networking example I
quoted is
not something you guys can deal with as the source project affects
this.

Unless we can use this exercise to test these and fix them then I am
happier.

My vision would be to have a set of templates and examples that are
tested
regularly against a running OS deployment so that we can make sure the
combinations still run. I am sure we can agree on a way to do this
with CICD
so that we test the fetureset.


Agreed, getting the approach to testing agreed seems like the first
step -
FYI we do already have automated scenario tests in the main heat tree
that
consume templates similar to many of the examples:

https://github.com/openstack/heat/tree/master/heat_integrationtests/scenario


So, in theory, getting a similar test running on heat_templates
should be
fairly simple, but getting all the existing templates working is
likely to
be a bigger challenge.


Even if we just ran the 'template validate' command on them to check
that all of the resource types & properties still exist, that would be
pretty helpful. It'd catch of of the times when we break backwards
compatibility so we can decide to either fix it or deprecate/remove
the obsolete template. (Note that you still need all of the services
installed, or at least endpoints in the catalog, for the validation to
work.)


So apparently Thomas already implemented this (nice!). The limitation is 
that we're ignoring errors where the template contains a resource where 
the endpoint is not in the service catalog. That's likely to mean a lot 
of these templates aren't _really_ getting tested.


In theory all we have to do to fix that is add endpoints for all of them 
in the catalog (afaik we shouldn't need to actually run any of the 
services).


- ZB

__
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

Re: [openstack-dev] [Heat] Heat template example repository

[Lance Haig]

On 15.05.17 19:01, Zane Bitter wrote:

On 15/05/17 12:10, Steven Hardy wrote:

On Mon, May 15, 2017 at 04:46:28PM +0200, Lance Haig wrote:

Hi Steve,

I am happy to assist in any way to be honest.


It was great to meet you in Boston, and thanks very much for 
volunteering to help out.


BTW one issue I'm aware of is that the autoscaling template examples 
we have all use OS::Ceilometer::* resources for alarms. We have a 
global environment thingy that maps those to OS::Aodh::*, so at least 
in theory those templates should continue to work, but there are 
actually no examples that I can find of autoscaling templates doing 
things the way we want everyone to do them.
I think we can perhaps come up with some standard scenarios that we want 
to showcase and then we can work on getting this setup.


I might suggest that you look at the repo that my colleague Florin and I 
setup for our library and training material.

https://github.com/heat-extras

In the lib repo we have a test directory that tests each library 
template it might be an idea as to how to achieve test coverage of the 
different resources.
We currently just run yamllint testing with the script in there but I am 
sure we can add other tests as needed.



The backwards compatibility is not always correct as I have seen when
developing our library of templates on Liberty and then trying to 
deploy it

on Mitaka for example.


Yeah, I guess it's true that there are sometimes deprecated resource
interfaces that get removed on upgrade to a new OpenStack version, 
and that

is independent of the HOT version.


What if instead of a directory per release, we just had a 'deprecated' 
directory where we move stuff that is going away (e.g. anything 
relying on OS::Glance::Image), and then deleted them when it 
disappeared from any supported release (e.g. LBaaSv1 must be close if 
it isn't gone already).


I agree in general this would be good. How would we deal with users who 
are running older versions of openstack?
Most of the customers I support have Liberty and newer so I would 
perhaps like to have these available as tested.
The challenge for us is that the newer the OStack version the more 
features are available e.g. conditionals etc..
To support that in a backwards compatible fashion is going to be tough I 
think. Unless I am missing something.
As we've proven, maintaining these templates has been a challenge 
given the
available resources, so I guess I'm still in favor of not duplicating 
a bunch

of templates, e.g perhaps we could focus on a target of CI testing
templates on the current stable release as a first step?


I'd rather do CI against Heat master, I think, but yeah that sounds 
like the first step. Note that if we're doing CI on old stuff then 
we'd need to do heat-templates stable branches rather than 
directory-per-release.


With my suggestion above, we could just not check anything in the 
'deprecated' directory maybe?

I agree in part.
If we are using the heat examples to test the functionality of the 
master branch then that would be a good idea.
If we want to provide useable templates for users to reference and use 
then I would suggest we test against stable.


I am sure we could find a way to do both.
I would suggets that we first get reliable CICD running on the current 
templates and fix what we can in there.

Then we can look at what would be a good way forward.

I am just brain dumping so any other ideas would also be good.


As you guys mentioned in our discussions the Networking example I 
quoted is
not something you guys can deal with as the source project affects 
this.


Unless we can use this exercise to test these and fix them then I am
happier.

My vision would be to have a set of templates and examples that are 
tested

regularly against a running OS deployment so that we can make sure the
combinations still run. I am sure we can agree on a way to do this 
with CICD

so that we test the fetureset.


Agreed, getting the approach to testing agreed seems like the first 
step -
FYI we do already have automated scenario tests in the main heat tree 
that

consume templates similar to many of the examples:

https://github.com/openstack/heat/tree/master/heat_integrationtests/scenario 



So, in theory, getting a similar test running on heat_templates 
should be
fairly simple, but getting all the existing templates working is 
likely to

be a bigger challenge.


Even if we just ran the 'template validate' command on them to check 
that all of the resource types & properties still exist, that would be 
pretty helpful. It'd catch of of the times when we break backwards 
compatibility so we can decide to either fix it or deprecate/remove 
the obsolete template. (Note that you still need all of the services 
installed, or at least endpoints in the catalog, for the validation to 
work.)


Actually creating all of the stuff would be nice, but it'll likely be 
difficult (just keeping up-to-date OS images to boot from is a giant 

Re: [openstack-dev] [Heat] Heat template example repository

[Lance Haig]

On 15.05.17 18:10, Steven Hardy wrote:

On Mon, May 15, 2017 at 04:46:28PM +0200, Lance Haig wrote:

Hi Steve,

I am happy to assist in any way to be honest.

The backwards compatibility is not always correct as I have seen when
developing our library of templates on Liberty and then trying to deploy it
on Mitaka for example.

Yeah, I guess it's true that there are sometimes deprecated resource
interfaces that get removed on upgrade to a new OpenStack version, and that
is independent of the HOT version.

As we've proven, maintaining these templates has been a challenge given the
available resources, so I guess I'm still in favor of not duplicating a bunch
of templates, e.g perhaps we could focus on a target of CI testing
templates on the current stable release as a first step?

I think this is a good way to go.
If we get the tests running we will soon see what is broken and what not 
on the stable release and then make a call as to how to go about fixing 
that.

As you guys mentioned in our discussions the Networking example I quoted is
not something you guys can deal with as the source project affects this.

Unless we can use this exercise to test these and fix them then I am
happier.

My vision would be to have a set of templates and examples that are tested
regularly against a running OS deployment so that we can make sure the
combinations still run. I am sure we can agree on a way to do this with CICD
so that we test the fetureset.

Agreed, getting the approach to testing agreed seems like the first step -
FYI we do already have automated scenario tests in the main heat tree that
consume templates similar to many of the examples:

https://github.com/openstack/heat/tree/master/heat_integrationtests/scenario

So, in theory, getting a similar test running on heat_templates should be
fairly simple, but getting all the existing templates working is likely to
be a bigger challenge.

I am happy to work on getting the existing templates tested if that helps.
As a newbie contributor I would need some help getting started and then 
I would do the work.


If you can assist with the places to start I would appreciate it.

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

Re: [openstack-dev] [Heat] Heat template example repository

[Zane Bitter]

On 15/05/17 12:10, Steven Hardy wrote:

On Mon, May 15, 2017 at 04:46:28PM +0200, Lance Haig wrote:

Hi Steve,

I am happy to assist in any way to be honest.


It was great to meet you in Boston, and thanks very much for 
volunteering to help out.


BTW one issue I'm aware of is that the autoscaling template examples we 
have all use OS::Ceilometer::* resources for alarms. We have a global 
environment thingy that maps those to OS::Aodh::*, so at least in theory 
those templates should continue to work, but there are actually no 
examples that I can find of autoscaling templates doing things the way 
we want everyone to do them.



The backwards compatibility is not always correct as I have seen when
developing our library of templates on Liberty and then trying to deploy it
on Mitaka for example.


Yeah, I guess it's true that there are sometimes deprecated resource
interfaces that get removed on upgrade to a new OpenStack version, and that
is independent of the HOT version.


What if instead of a directory per release, we just had a 'deprecated' 
directory where we move stuff that is going away (e.g. anything relying 
on OS::Glance::Image), and then deleted them when it disappeared from 
any supported release (e.g. LBaaSv1 must be close if it isn't gone already).



As we've proven, maintaining these templates has been a challenge given the
available resources, so I guess I'm still in favor of not duplicating a bunch
of templates, e.g perhaps we could focus on a target of CI testing
templates on the current stable release as a first step?


I'd rather do CI against Heat master, I think, but yeah that sounds like 
the first step. Note that if we're doing CI on old stuff then we'd need 
to do heat-templates stable branches rather than directory-per-release.


With my suggestion above, we could just not check anything in the 
'deprecated' directory maybe?



As you guys mentioned in our discussions the Networking example I quoted is
not something you guys can deal with as the source project affects this.

Unless we can use this exercise to test these and fix them then I am
happier.

My vision would be to have a set of templates and examples that are tested
regularly against a running OS deployment so that we can make sure the
combinations still run. I am sure we can agree on a way to do this with CICD
so that we test the fetureset.


Agreed, getting the approach to testing agreed seems like the first step -
FYI we do already have automated scenario tests in the main heat tree that
consume templates similar to many of the examples:

https://github.com/openstack/heat/tree/master/heat_integrationtests/scenario

So, in theory, getting a similar test running on heat_templates should be
fairly simple, but getting all the existing templates working is likely to
be a bigger challenge.


Even if we just ran the 'template validate' command on them to check 
that all of the resource types & properties still exist, that would be 
pretty helpful. It'd catch of of the times when we break backwards 
compatibility so we can decide to either fix it or deprecate/remove the 
obsolete template. (Note that you still need all of the services 
installed, or at least endpoints in the catalog, for the validation to 
work.)


Actually creating all of the stuff would be nice, but it'll likely be 
difficult (just keeping up-to-date OS images to boot from is a giant 
pain). And even then that isn't sufficient to test that it actually 
_works_. Let's keep that out of scope for now?


cheers,
Zane.

__
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

Re: [openstack-dev] [Heat] Heat template example repository

[Kaz Shinohara]

Hi Lico and team,


Let me show up in this thread again, because I think now is really good
timing to introduce myself.
My name is Kazunori Shinohara (Kaz) working for NTT Communications as
software engineer.
I'm taking Heat as public cloud's orchestration services by adding own
resource plugins and some patches, I do believe my experience on this
should help the further development of Heat and the relevant projects.

In the last summit, I got upstream institute and Heat onboarding session, I
guess I was next to Lance at there.
Now I've done my first contribution for a document bug with Zane and
Huang's help.
https://review.openstack.org/#/c/463154/
I will definitely keep contributing more*, esp..bug and blueprint part,
also I don't mind any tasks like as template example if I can help.*

> *tutorial*: We got some reports about the lack of tutorials for for for
features like software config/ rolling upgrade,
Yea I think so, honestly speaking I skipped software config function for
our public cloud because I could not figure out well how it works

> Also, we do hope to get more reports on how people use heat,
I will be able to have feedback from actual use case on our public cloud
going forward.

>(Wednesdays at 1500 UTC in #openstack-meeting-5) :)
I will join too.

Regards,

Kaz Shinohara
IRC: kazsh

2017-05-16 1:10 GMT+09:00 Steven Hardy :

> On Mon, May 15, 2017 at 04:46:28PM +0200, Lance Haig wrote:
> > Hi Steve,
> >
> > I am happy to assist in any way to be honest.
> >
> > The backwards compatibility is not always correct as I have seen when
> > developing our library of templates on Liberty and then trying to deploy
> it
> > on Mitaka for example.
>
> Yeah, I guess it's true that there are sometimes deprecated resource
> interfaces that get removed on upgrade to a new OpenStack version, and that
> is independent of the HOT version.
>
> As we've proven, maintaining these templates has been a challenge given the
> available resources, so I guess I'm still in favor of not duplicating a
> bunch
> of templates, e.g perhaps we could focus on a target of CI testing
> templates on the current stable release as a first step?
>
> > As you guys mentioned in our discussions the Networking example I quoted
> is
> > not something you guys can deal with as the source project affects this.
> >
> > Unless we can use this exercise to test these and fix them then I am
> > happier.
> >
> > My vision would be to have a set of templates and examples that are
> tested
> > regularly against a running OS deployment so that we can make sure the
> > combinations still run. I am sure we can agree on a way to do this with
> CICD
> > so that we test the fetureset.
>
> Agreed, getting the approach to testing agreed seems like the first step -
> FYI we do already have automated scenario tests in the main heat tree that
> consume templates similar to many of the examples:
>
> https://github.com/openstack/heat/tree/master/heat_
> integrationtests/scenario
>
> So, in theory, getting a similar test running on heat_templates should be
> fairly simple, but getting all the existing templates working is likely to
> be a bigger challenge.
>
> Steve
>
> __
> 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
>
__
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

Re: [openstack-dev] [Heat] Heat template example repository

[Steven Hardy]

On Mon, May 15, 2017 at 04:46:28PM +0200, Lance Haig wrote:
> Hi Steve,
> 
> I am happy to assist in any way to be honest.
> 
> The backwards compatibility is not always correct as I have seen when
> developing our library of templates on Liberty and then trying to deploy it
> on Mitaka for example.

Yeah, I guess it's true that there are sometimes deprecated resource
interfaces that get removed on upgrade to a new OpenStack version, and that
is independent of the HOT version.

As we've proven, maintaining these templates has been a challenge given the
available resources, so I guess I'm still in favor of not duplicating a bunch
of templates, e.g perhaps we could focus on a target of CI testing
templates on the current stable release as a first step?

> As you guys mentioned in our discussions the Networking example I quoted is
> not something you guys can deal with as the source project affects this.
> 
> Unless we can use this exercise to test these and fix them then I am
> happier.
> 
> My vision would be to have a set of templates and examples that are tested
> regularly against a running OS deployment so that we can make sure the
> combinations still run. I am sure we can agree on a way to do this with CICD
> so that we test the fetureset.

Agreed, getting the approach to testing agreed seems like the first step -
FYI we do already have automated scenario tests in the main heat tree that
consume templates similar to many of the examples:

https://github.com/openstack/heat/tree/master/heat_integrationtests/scenario

So, in theory, getting a similar test running on heat_templates should be
fairly simple, but getting all the existing templates working is likely to
be a bigger challenge.

Steve

__
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

Re: [openstack-dev] [Heat] Heat template example repository

[Lance Haig]

Hi Steve,

I am happy to assist in any way to be honest.

The backwards compatibility is not always correct as I have seen when 
developing our library of templates on Liberty and then trying to deploy 
it on Mitaka for example.


As you guys mentioned in our discussions the Networking example I quoted 
is not something you guys can deal with as the source project affects this.


Unless we can use this exercise to test these and fix them then I am 
happier.


My vision would be to have a set of templates and examples that are 
tested regularly against a running OS deployment so that we can make 
sure the combinations still run. I am sure we can agree on a way to do 
this with CICD so that we test the fetureset.


I look forward to assisting the community with this.

Regards

Lance



On 15.05.17 16:03, Steven Hardy wrote:

On Mon, May 15, 2017 at 03:21:30AM -0400, Lance Haig wrote:

Good to know that there is interest.

Thanks for starting this effort - I agree it would be great to see the
example templates we provide improved and over time become better
references for heat features (as well as being more well tested).


I was thinking that we should perhaps create a directory for each
openstack version.

I'm personally not keen on this - Heat should handle old HOT versions in a
backwards compatible way, and we can use the template version (which
supports using the release name in recent heat versions) to document the
required version e.g if demonstrating some new resource or function.

FWIW we did already try something similar in the early days of heat, where
we had duplicate wordpress examples for different releases (operating
systems not OpenStack versions but it's the same problem).  We found that
old versions quickly became unmaintained, and ultimately got broken anyway
due to changes unrelated to Heat or OpenStack versions.


so we start say with a mitaka directory and then move the files there and
test them all so that they work with Liberty.
Then we can copy it over to Mitaka and do the same but add the extra
functionality.

While some manual testing each release is better than nothing, honestly I
feel like CI testing some (or ideally all) examples is the only way to
ensure they're not broken.  Clearly that's going to be more work initially,
but it'd be worth considering I think.

To make this simple for template authors, we could perhaps just create the
template with the default parameters, and codify some special place to
define the expected ouput values (we could for example have a special
expected_output parameter which the CI test consumes and compares after the
stack create completes).


and then Newton etc...
That way if someone is on a specific version they only have to go to a
specific directory to get the examples they need.

As mentioned above, I think just using the template version should be
enough - we could even generate some docs using this to highlight example
templates that are specific to a release?

Steve

__
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



__
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

Re: [openstack-dev] [Heat] Heat template example repository

[Lance Haig]

Hi Rico,

Great to meet you at the summit.


The version related templates I think would work as follows.

In each named directory we would have the same set of templates
e.g.
Single instance
Clustered instance
resource group
etc..

And so if you are on Pike you would go to the pike directory and you 
will find all th3e examples we have created for pike.


I am not sure that I properly understand how we want to take this 
forward as the current structure of the repository is confusing.


DO we just want to update all the examples there with the latest "Pike" 
way of creating these resources or do we want to have some backwards 
compatibility?

We will need to agree on that at first I think.

I will definitely join the meeting.

Regards

Lance


On 15.05.17 12:13, Rico Lin wrote:

Hi Lance and all others who shows interest

IMO, after some feedback from the summit. I think it will be greate to 
have efforts on


  * **bug/blueprint*: We needs more people doing fix/review/spec.
Since we still on the way to make heat more handy as Orchestration
tools*
  * *template example*: Since we do have some new functions but didn't
actually give a proper update of it.
  * *tutorial*: We got some reports about the lack of tutorials for
for for features like software config/ rolling upgrade, so I
definitely think we require some improvement here.
  * *test*: Our integration test(tempest test) seems not cover
every scenario (like we just cover some snapshots test these few
weeks). Also, we do hope to get more reports on how people use
heat, and what's the test result.

So yes from me, Lance, that will help:)

Also, most of our functions can be directly called by future version, 
so if we separate it into versions, how can Pike user find that 
example? I like to idea to make all user aware of template version. 
but not sure to make version specific directory will help. Maybe a 
version info in template description will do? We can discussion this 
at the meeting (Wednesdays at 1500 UTC in #openstack-meeting-5) :)


2017-05-15 15:21 GMT+08:00 Lance Haig >:


Good to know that there is interest.

I was thinking that we should perhaps create a directory for each
openstack version.

so we start say with a mitaka directory and then move the files
there and test them all so that they work with Liberty.
Then we can copy it over to Mitaka and do the same but add the
extra functionality.
and then Newton etc...

That way if someone is on a specific version they only have to go
to a specific directory to get the examples they need.

What do you think?

Lance


On 14 May 2017 at 23:14, Kaz Shinohara mailto:ksnhr.t...@gmail.com>> wrote:

Hi Lance,

I like it too.
We should keep them updated according to the latest spec and
actual use cases.

Regards,
Kaz Shinohara


2017-05-13 13:00 GMT+09:00 Foss Geek mailto:thefossg...@gmail.com>>:

Hi Lance, I am also interested to assisting you on this.

Thanks
Mohan

On 11-May-2017 2:25 am, "Lance Haig" mailto:lnh...@gmail.com>> wrote:

Hi,

I would like to introduce myself to the heat team.

My name is Lance Haig I currently work for Mirantis
doing workload onboarding to openstack.

Part of my job is assisting customers with using the
new Openstack cloud they have been given.

I recently gave a talk with a colleague Florin
Stingaciu on LCM with heat at the Boston Summit.

I am interested in assisting the project.

We have noticed that there are some outdated examples
in the heat-examples repository and I am not sure that
they all still function.

I was wondering if it would be valuable for me to take
a look at these and fix them or perhaps we can rethink
how we present the examples.

I am interested in what you guys think.

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





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openst

Re: [openstack-dev] [Heat] Heat template example repository

[Steven Hardy]

On Mon, May 15, 2017 at 03:21:30AM -0400, Lance Haig wrote:
>Good to know that there is interest.

Thanks for starting this effort - I agree it would be great to see the
example templates we provide improved and over time become better
references for heat features (as well as being more well tested).

>I was thinking that we should perhaps create a directory for each
>openstack version.

I'm personally not keen on this - Heat should handle old HOT versions in a
backwards compatible way, and we can use the template version (which
supports using the release name in recent heat versions) to document the
required version e.g if demonstrating some new resource or function.

FWIW we did already try something similar in the early days of heat, where
we had duplicate wordpress examples for different releases (operating
systems not OpenStack versions but it's the same problem).  We found that
old versions quickly became unmaintained, and ultimately got broken anyway
due to changes unrelated to Heat or OpenStack versions.

>so we start say with a mitaka directory and then move the files there and
>test them all so that they work with Liberty.
>Then we can copy it over to Mitaka and do the same but add the extra
>functionality.

While some manual testing each release is better than nothing, honestly I
feel like CI testing some (or ideally all) examples is the only way to
ensure they're not broken.  Clearly that's going to be more work initially,
but it'd be worth considering I think.

To make this simple for template authors, we could perhaps just create the
template with the default parameters, and codify some special place to
define the expected ouput values (we could for example have a special
expected_output parameter which the CI test consumes and compares after the
stack create completes).

>and then Newton etc...
>That way if someone is on a specific version they only have to go to a
>specific directory to get the examples they need.

As mentioned above, I think just using the template version should be
enough - we could even generate some docs using this to highlight example
templates that are specific to a release?

Steve

__
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

Re: [openstack-dev] [Heat] Heat template example repository

[Rico Lin]

Hi Lance and all others who shows interest

IMO, after some feedback from the summit. I think it will be greate to have
efforts on


   - *bug/blueprint: We needs more people doing fix/review/spec. Since we
   still on the way to make heat more handy as Orchestration tools*
   - *template example*: Since we do have some new functions but didn't
   actually give a proper update of it.
   - *tutorial*: We got some reports about the lack of tutorials for for
   for features like software config/ rolling upgrade, so I definitely think
   we require some improvement here.
   - *test*: Our integration test(tempest test) seems not cover
   every scenario (like we just cover some snapshots test these few weeks).
   Also, we do hope to get more reports on how people use heat, and what's the
   test result.

So yes from me, Lance, that will help:)

Also, most of our functions can be directly called by future version, so if
we separate it into versions, how can Pike user find that example? I like
to idea to make all user aware of template version. but not sure to make
version specific directory will help. Maybe a version info in template
description will do? We can discussion this at the meeting (Wednesdays at
1500 UTC in #openstack-meeting-5) :)

2017-05-15 15:21 GMT+08:00 Lance Haig :

> Good to know that there is interest.
>
> I was thinking that we should perhaps create a directory for each
> openstack version.
>
> so we start say with a mitaka directory and then move the files there and
> test them all so that they work with Liberty.
> Then we can copy it over to Mitaka and do the same but add the extra
> functionality.
> and then Newton etc...
>
> That way if someone is on a specific version they only have to go to a
> specific directory to get the examples they need.
>
> What do you think?
>
> Lance
>
>
> On 14 May 2017 at 23:14, Kaz Shinohara  wrote:
>
>> Hi Lance,
>>
>> I like it too.
>> We should keep them updated according to the latest spec and actual use
>> cases.
>>
>> Regards,
>> Kaz Shinohara
>>
>>
>> 2017-05-13 13:00 GMT+09:00 Foss Geek :
>>
>>> Hi Lance, I am also interested to assisting you on this.
>>>
>>> Thanks
>>> Mohan
>>> On 11-May-2017 2:25 am, "Lance Haig"  wrote:
>>>
 Hi,

 I would like to introduce myself to the heat team.

 My name is Lance Haig I currently work for Mirantis doing workload
 onboarding to openstack.

 Part of my job is assisting customers with using the new Openstack
 cloud they have been given.

 I recently gave a talk with a colleague Florin Stingaciu on LCM with
 heat at the Boston Summit.

 I am interested in assisting the project.

 We have noticed that there are some outdated examples in the
 heat-examples repository and I am not sure that they all still function.

 I was wondering if it would be valuable for me to take a look at these
 and fix them or perhaps we can rethink how we present the examples.

 I am interested in what you guys think.

 Thanks

 Lance

 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.op
 enstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> 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
>
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
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

Re: [openstack-dev] [Heat] Heat template example repository

[Lance Haig]

Good to know that there is interest.

I was thinking that we should perhaps create a directory for each openstack
version.

so we start say with a mitaka directory and then move the files there and
test them all so that they work with Liberty.
Then we can copy it over to Mitaka and do the same but add the extra
functionality.
and then Newton etc...

That way if someone is on a specific version they only have to go to a
specific directory to get the examples they need.

What do you think?

Lance


On 14 May 2017 at 23:14, Kaz Shinohara  wrote:

> Hi Lance,
>
> I like it too.
> We should keep them updated according to the latest spec and actual use
> cases.
>
> Regards,
> Kaz Shinohara
>
>
> 2017-05-13 13:00 GMT+09:00 Foss Geek :
>
>> Hi Lance, I am also interested to assisting you on this.
>>
>> Thanks
>> Mohan
>> On 11-May-2017 2:25 am, "Lance Haig"  wrote:
>>
>>> Hi,
>>>
>>> I would like to introduce myself to the heat team.
>>>
>>> My name is Lance Haig I currently work for Mirantis doing workload
>>> onboarding to openstack.
>>>
>>> Part of my job is assisting customers with using the new Openstack cloud
>>> they have been given.
>>>
>>> I recently gave a talk with a colleague Florin Stingaciu on LCM with
>>> heat at the Boston Summit.
>>>
>>> I am interested in assisting the project.
>>>
>>> We have noticed that there are some outdated examples in the
>>> heat-examples repository and I am not sure that they all still function.
>>>
>>> I was wondering if it would be valuable for me to take a look at these
>>> and fix them or perhaps we can rethink how we present the examples.
>>>
>>> I am interested in what you guys think.
>>>
>>> Thanks
>>>
>>> Lance
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> 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
>
>
__
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

Re: [openstack-dev] [Heat] Heat template example repository

[Kaz Shinohara]

Hi Lance,

I like it too.
We should keep them updated according to the latest spec and actual use
cases.

Regards,
Kaz Shinohara


2017-05-13 13:00 GMT+09:00 Foss Geek :

> Hi Lance, I am also interested to assisting you on this.
>
> Thanks
> Mohan
> On 11-May-2017 2:25 am, "Lance Haig"  wrote:
>
>> Hi,
>>
>> I would like to introduce myself to the heat team.
>>
>> My name is Lance Haig I currently work for Mirantis doing workload
>> onboarding to openstack.
>>
>> Part of my job is assisting customers with using the new Openstack cloud
>> they have been given.
>>
>> I recently gave a talk with a colleague Florin Stingaciu on LCM with heat
>> at the Boston Summit.
>>
>> I am interested in assisting the project.
>>
>> We have noticed that there are some outdated examples in the
>> heat-examples repository and I am not sure that they all still function.
>>
>> I was wondering if it would be valuable for me to take a look at these
>> and fix them or perhaps we can rethink how we present the examples.
>>
>> I am interested in what you guys think.
>>
>> Thanks
>>
>> Lance
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> 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
>
>
__
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

Re: [openstack-dev] [Heat] Heat template example repository

[Foss Geek]

Hi Lance, I am also interested to assisting you on this.

Thanks
Mohan
On 11-May-2017 2:25 am, "Lance Haig"  wrote:

> Hi,
>
> I would like to introduce myself to the heat team.
>
> My name is Lance Haig I currently work for Mirantis doing workload
> onboarding to openstack.
>
> Part of my job is assisting customers with using the new Openstack cloud
> they have been given.
>
> I recently gave a talk with a colleague Florin Stingaciu on LCM with heat
> at the Boston Summit.
>
> I am interested in assisting the project.
>
> We have noticed that there are some outdated examples in the heat-examples
> repository and I am not sure that they all still function.
>
> I was wondering if it would be valuable for me to take a look at these and
> fix them or perhaps we can rethink how we present the examples.
>
> I am interested in what you guys think.
>
> 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
>
>
__
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

Re: [openstack-dev] [Heat] Heat template example repository

[Shake Chen]

I like it.

the heat template is very old ,need to update.

On Thu, May 11, 2017 at 4:54 AM, Lance Haig  wrote:

> Hi,
>
> I would like to introduce myself to the heat team.
>
> My name is Lance Haig I currently work for Mirantis doing workload
> onboarding to openstack.
>
> Part of my job is assisting customers with using the new Openstack cloud
> they have been given.
>
> I recently gave a talk with a colleague Florin Stingaciu on LCM with heat
> at the Boston Summit.
>
> I am interested in assisting the project.
>
> We have noticed that there are some outdated examples in the heat-examples
> repository and I am not sure that they all still function.
>
> I was wondering if it would be valuable for me to take a look at these and
> fix them or perhaps we can rethink how we present the examples.
>
> I am interested in what you guys think.
>
> 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
>
>


-- 
Shake Chen
__
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