Open Stack

 +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 <imsplitbit at 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 <myer0052 at 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 <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
>>>
>>>
>>
>> _______________________________________________
>> 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/eb534133/attachment.html>