Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131029/e32b6487/attachment.html>