Open Stack

Hi,

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.


Regards

Lance


On 31.05.17 16:03, Lance Haig wrote:
> Hi,
>
>
> On 24.05.17 18:43, Zane Bitter wrote:
>> On 19/05/17 11:00, Lance Haig wrote:
>>> Hi,
>>>
>>> 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
>>> perspective.
>>>
>>> For me the repository is quiet confusing with different styles that are
>>> used to show certain aspects and other styles for older template 
>>> examples.
>>>
>>> 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 
> again.
>>
>> 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 
>>> training
>>>     for new users.
>>>       o I know that there are documents hosted in the developer area 
>>> and
>>>         these could be utilized but I would think having a 
>>> documentation
>>>         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
>>>         possible.
>>>   * 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 
>>> have
>>>         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.
>
> Regards
>
> Lance
>
>