Open Stack

+1 to Robert's suggestion

I think it makes sense to keep all data store templates that are used in
the same location. ie. templates/{data-store}/*.template
As trove expands its data stores then we have all the templates next to
each other. I think it would make it easier to remove/add support for new
data stores this way.

Denis
I think we could see in the not so distant future where the heat templates
*could* be dynamic in nature. (clusters and such)



On Tue, Oct 29, 2013 at 10:15 AM, Denis Makogon <dmakogon at mirantis.com>wrote:

> Robert,  i also have thoughts about templates.
>
> Your suggestion is rather complex. Let me explain why is it so:
>      With new datastore support you should update PackageLoader and
> FilesystemLoader with new filesystem path and package path. I would prefe
> more easy configuration and store it in next way:
>      - templates/configuration/{datastore}.config.template;
>      - templates/heat/{datastore}.heat.template.
>
> Heat templates would be static until in trove become super-complex in
> instance configuration like Savanna (Hadoop on OpenStack).
>
> What about jinja - ok , i agree to use it, but (!!!) we would not use it
> for heat template rendering, because templates are static. Trove is not so
> complex in instance configuration that is why it doesn't need to
> genereate/modify heat templates on-the-go.
>
> Please take a look at this one https://review.openstack.org/#/c/54315/
>
>
> 2013/10/29 Robert Myers <myer0052 at gmail.com>
>
>> I'm pulling this conversation out of the gerrit review as I think it
>> needs more discussion.
>>
>> https://review.openstack.org/#/c/53499/
>>
>> I want to discuss the design decision to not use Jinja templates for the
>> heat templates. My arguments for using Jinja for heat as well are:
>>
>> 1. We have to rewrite all the template loading logic. The current
>> implementation is pretty simple but in order to make in production worthy
>> it will need to handle many more edge cases as we use develop this feature.
>> The main argument I have heard against using the existing ENV is that the
>> path is hard coded. (This can and should be turned into a config flag)
>> 2. We are already using Jinja templates for config files so it will be
>> less confusing for a new person starting up. Why do these custom templates
>> go here but these over here? Having one place to override defaults makes
>> sense.
>> 3. Looking at the current heat templates I could easily see some areas
>> that could take advantage of being a real Jinja template, an admin could
>> create a base template and extend that for each different service and just
>> change a few values in each.
>> 4. The default templates could be package with trove (using the Jijna
>> PackageLoader) so the initial setup out of the box will work.
>>
>> If we go this route it would also be a good time to discuss the
>> origination of the templates. Currently the templates are just in
>>
>> - trove/templates/{data_store}.config.template
>> - trove/templates/{data_store}.heat.template
>>
>>
>> I suggest that we move this into a folder structure like so:
>>
>> - trove/template/{data_store}/config.template
>> - trove/template/{data_store}/heat.template
>> - trove/template/{data_store}/the_next.template
>>
>> Thanks!
>> Robert
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131029/1022f1e2/attachment.html>