[openstack-dev] [Heat] revised structure of the heat-templates repository. Suggestions
lnhaig at gmail.com
Thu Jun 1 06:06:51 UTC 2017
One question I have not asked on this thread is.
What would you like to see changed within the repository and do you have
a suggestion onhow to fix it.
On 31.05.17 16:03, Lance Haig wrote:
> On 24.05.17 18:43, Zane Bitter wrote:
>> On 19/05/17 11:00, Lance Haig wrote:
>>> As we know the heat-templates repository has become out of date in some
>>> respects and also has been difficult to be maintained from a community
>>> For me the repository is quiet confusing with different styles that are
>>> used to show certain aspects and other styles for older template
>>> This I think leads to confusion and perhaps many people who give up on
>>> heat as a resource as things are not that clear.
>>> From discussions in other threads and on the IRC channel I have seen
>>> that there is a need to change things a bit.
>>> This is why I would like to start the discussion that we rethink the
>>> template example repository.
>>> I would like to open the discussion with mys suggestions.
>>> * We need to differentiate templates that work on earlier versions of
>>> heat that what is the current supported versions.
>> I typically use the heat_template_version for this. Technically this
>> is entirely independent of what resource types are available in Heat.
>> Nevertheless, if I submit e.g. a template that uses new resources
>> only available in Ocata, I'll set 'heat_template_version: ocata' even
>> if the template doesn't contain any Ocata-only intrinsic functions.
>> We could make that a convention.
> That is one way to achieve this.
>>> o I have suggested that we create directories that relate to
>>> different versions so that you can create a stable version of
>>> examples for the heat version and they should always remain
>>> stable for that version and once it goes out of support can
>>> remain there.
>> I'm reluctant to move existing things around unless its absolutely
>> necessary, because there are a lot of links out in the wild to
>> templates that will break. And they're links directly to the Git
>> repo, it's not like we publish them somewhere and could add redirects.
>> Although that gives me an idea: what if we published them somewhere?
>> We could make templates actually discoverable by publishing a list of
>> descriptions (instead of just the names like you get through browsing
>> the Git repo). And we could even add some metadata to indicate what
>> versions of Heat they run on.
> It would be better to do something like this. One of the biggest
> learning curves that our users have had is understanding what is
> available in what version of heat and then finding examples of
> templates that match their version.
> I wanted to create the heat-lib library so that people could easily
> find working examples for their version of heat and also use the
> library intact as is so that they can get up-to speed really quickly.
> This has enabled people to become productive much faster with heat.
>>> o This would mean people can find their version of heat and know
>>> these templates all work on their version
>> This would mean keeping multiple copies of each template and
>> maintaining them all. I don't think this is the right way to do this
>> - to maintain old stuff what you need is a stable branch. That's also
>> how you're going to be able to test against old versions of OpenStack
>> in the gate.
> Well I am not sure that this would be needed. Unless there are many
> backports of new resources to older versions of the templates.
> e.g. Would the project backport the Neuton conditionals to the Liberty
> version of heat? I am assuming not.
> That means that once a new version of heat is decided the template set
> becomes locked and you just create a copy with the new template
> version and test regression and once that is complete then you start
> adding the changes that are specific to the new version of heat.
> I know that initially it would be quiet a bit of work to setup and to
> test the versions but once they are locked then you don't touch them
>> As I suggested in the other thread, I'd be OK with moving deprecated
>> stuff to a 'deprecated' directory and then eventually deleting it.
>> Stable branches would then correctly reflect the status of those
>> templates at each previous release.
> That makes sense. I would liek to clarify the above discussion first
> before we look at how to deprecate unsupported versions. I say that as
> many of our customers are running Liberty still :-)
>>> * We should consider adding a docs section that that includes
>>> for new users.
>>> o I know that there are documents hosted in the developer area
>>> these could be utilized but I would think having a
>>> section in the repository would be a good way to keep the
>>> examples and the documents in the same place.
>>> o This docs directory could also host some training for new users
>>> and old ones on new features etc.. In a similar line to what is
>>> here in this repo https://github.com/heat-extras/heat-tutorial
>>> * We should include examples form the default hooks e.g. ansible salt
>>> etc... with SoftwareDeployments.
>>> o We found this quiet helpful for new users to understand what is
>>> * We should make sure that the validation running against the
>>> templates runs without ignoring errors.
>>> o This was noted in IRC that some errors were ignored as the
>>> endpoints or catalog was not available. It would be good to
>>> some form of headless catalog server that tests can be run
>>> against so that developers of templates can validate before
>>> submitting patches.
>> +1 to all of this.
>>> These points are here to open the discussions around this topic
>>> Please feel free to make your suggestions.
>> Thanks for kicking this off!
> I am only doing my bit.
More information about the OpenStack-dev