I hear you Clint. I'm not an expert on heat templates so it is possible to
do this all with one. However I don't want to use Jinja to replace the heat
template logic just for sane template loading. We are already using Jinja
templates to load custom config files. So it makes sense to re-use the sam
Also using one template for every life situations is a mess, someday it
would become himera. And if i don't want to inject something but template
relays on some kind of parameter, heat would return exception on attempt to
validate template with part of expected parameters.
_
Only trove administrator has access to heat templates, user cannot
manipulate templates, if he could we would not need trove at all. And idea
is to store only one template per datastore. And, i know that templates
could be parametrized. But, keep in mind, that we cannot inject in
templates anything
+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
> I like simple. To me it
Excerpts from Robert Myers's message of 2013-10-29 07:54:59 -0700:
> I'm pulling this conversation out of the gerrit review as I think it needs
> more discussion.
>
> https://review.openstack.org/#/c/53499/
>
After reading the comments in that review, it seems to me that you
don't need a client
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
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
w
+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
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
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 al
10 matches
Mail list logo
