+1 for idea suggested in https://review.openstack.org/#/c/54315/.
We discussed to store heat templates at separate idea - so, here it is. I think it's ok to store configs in separate dirs: one for configurations and one for heat templates. 2013/10/29 Daniel Salinas <imsplit...@gmail.com> > I like simple. To me it is easier to break them out into dirs like Robert > suggested rather than eventually having a folder full of > num_datastore_types * 2 files. As for the structure, I find it more > intuitive to have the directories named for the datastore type. within > that dir you can have the templates for each. > > > On Tue, Oct 29, 2013 at 11:54 AM, Robert Myers <myer0...@gmail.com> wrote: > >> 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: >> >> - templates/{data_store}/config >> - templates/{data_store}/heat >> >> or >> >> - templates/config/{data_store}.config >> - templates/heat/{data_store}.heat >> >> During lookup of the templates it is either: >> >> config_template = '%s/config.template' % service_type >> heat_template = '%s/heat.template' % service_type >> >> or >> >> config_template = 'config/%s.config.template' % service_type >> heat_template = 'heat/%s.heat.template' % service_type >> >> My perference is to group by data_store type, but I'm curious to what >> others think. >> >> Robert >> >> >> On Tue, Oct 29, 2013 at 10:15 AM, Denis Makogon <dmako...@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 <myer0...@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@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev