<div dir="ltr">So I guess the only contention point is to either store the templates by type or by datastore. I don't see the use case where you'd have completely different paths for templates, so there is really no need for two separate template paths. My idea is to group the templates by data_store because as we add more data_stores the flat file structure will get harder to manage. So either:<div>
<br></div><div>- templates/{data_store}/config</div><div>- templates/{data_store}/heat</div><div><br></div><div>or</div><div><br></div><div>- templates/config/{data_store}.config</div><div>- templates/heat/{data_store}.heat</div>
<div><br></div><div>During lookup of the templates it is either:</div><div><br></div><div>config_template = '%s/config.template' % service_type</div><div>heat_template = '%s/heat.template' % service_type</div>
<div><br></div><div>or</div><div><br></div><div><div>config_template = 'config/%s.config.template' % service_type</div><div>heat_template = 'heat/%s.heat.template' % service_type</div></div><div><br></div>
<div>My perference is to group by data_store type, but I'm curious to what others think.</div><div><br></div><div>Robert</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 29, 2013 at 10:15 AM, Denis Makogon <span dir="ltr"><<a href="mailto:dmakogon@mirantis.com" target="_blank">dmakogon@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Robert, i also have thoughts about templates.<br><br></div>Your suggestion is rather complex. Let me explain why is it so:<br>
</div><div> 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:<br>
</div> - templates/configuration/{datastore}.config.template;<br></div> - templates/heat/{datastore}.heat.template.<br><br></div><div>Heat templates would be static until in trove become super-complex in instance configuration like Savanna (Hadoop on OpenStack).<br>
</div><div><br></div>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.<br>
<br></div>Please take a look at this one <a href="https://review.openstack.org/#/c/54315/" target="_blank">https://review.openstack.org/#/c/54315/</a><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/10/29 Robert Myers <span dir="ltr"><<a href="mailto:myer0052@gmail.com" target="_blank">myer0052@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">I'm pulling this conversation out of the gerrit review as I think it needs more discussion.<div>
<br>
</div><div><a href="https://review.openstack.org/#/c/53499/" target="_blank">https://review.openstack.org/#/c/53499/</a><br>
</div><div><br></div><div>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:</div><div><br></div><div>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)</div>
<div>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.</div>
<div>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.</div>
<div>4. The default templates could be package with trove (using the Jijna PackageLoader) so the initial setup out of the box will work.</div><div><br></div><div>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 </div>
<div><br></div><div>- trove/templates/{data_store}.config.template</div><div>- trove/templates/{data_store}.heat.template</div><div><br></div><div><br></div><div>I suggest that we move this into a folder structure like so:</div>
<div><br></div><div>- trove/template/{data_store}/config.template</div><div>- trove/template/{data_store}/heat.template</div><div>- trove/template/{data_store}/the_next.template</div><div> </div><div>Thanks!</div><span><font color="#888888"><div>
Robert</div>
</font></span></div>
<br></div></div>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>