Re: [openstack-dev] [Trove] Templates in Trove
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 same
loading mechanism to allow administrators to add their own custom heat
templates in a well known location.
I don't want to re-invent the wheel either.
Robert
On Tue, Oct 29, 2013 at 12:24 PM, Clint Byrum wrote:
> 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 side template for your Heat template.
>
> The only argument for templating is "If I want some things to be
> custom I can't have them custom."
>
> You may not realize this, but Heat templates already have basic string
> replacement facilities and mappings, which is _all_ you need here.
>
> Use parameters. Pass _EVERYTHING_ into the stacks you're creating as
> parameters. Then let admins customize using Heat, not _another_
> language.
>
> For instance, somebody brought up wanting to have UserData be
> customizable. It is like this now:
>
> UserData:
> Fn::Base64:
> Fn::Join:
> - ''
> - ["#!/bin/bash -v\n",
> "/opt/aws/bin/cfn-init\n",
> "sudo service trove-guest start\n"]
>
> Since you're using yaml, you don't have to se Fn::Join like in json,
> so simplify to this first:
>
> UserData:
> Fn::Base64: |
> #!/bin/bash -v
> /opt/aws/bin/cfn-init
> sudo service trove-guest start
>
> Now, the suggestion was that users might want to do a different prep
> per service_type. First, we need to make service_type a parameter
>
>
> Parameters:
> service_type:
> Type: String
> Default: mysql
>
> Now we need to shove it in where needed:
>
> Metadata:
> AWS::CloudFormation::Init:
> config:
> files:
> /etc/guest_info:
> content:
> Fn::Join:
> - ''
> - ["[DEFAULT]\nguest_id=", {Ref: InstanceId},
> "\nservice_type=", {Ref: service_type}, "]"
> mode: '000644'
> owner: root
> group: root
>
> Now, if a user wants to have a different script:
>
> Mappings:
> ServiceToScript:
> mysql:
> script: |
> #!/bin/bash -v
> /opt/aws/bin/cfn-init
> sudo service trove-guest start
> galera:
> script: |
> #!/bin/bash
> /opt/aws/bin/cfn-init
> galera-super-thingy
> sudo service trove-guest start
>
>
> And then they replace the userdata as such:
>
> UserData:
> Fn::FindInMap:
> - ServiceToScript
> - {Ref: service_type}
> - script
>
> Please can we at least _try_ not to reinvent things!
>
> ___
> 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
Re: [openstack-dev] [Trove] Templates in Trove
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. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Trove] Templates in Trove
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 (like custom userdata) without modifying project code.
For now there is no need to do this, and i suppose we would not need it
untill some super-custom modifications are needed - userdata is not one of
them.
In trove we have working template which would prepare instance and deliver
code on VM - this is main goal, nothing else.
2013/10/29 Clint Byrum
> 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 side template for your Heat template.
>
> The only argument for templating is "If I want some things to be
> custom I can't have them custom."
>
> You may not realize this, but Heat templates already have basic string
> replacement facilities and mappings, which is _all_ you need here.
>
> Use parameters. Pass _EVERYTHING_ into the stacks you're creating as
> parameters. Then let admins customize using Heat, not _another_
> language.
>
> For instance, somebody brought up wanting to have UserData be
> customizable. It is like this now:
>
> UserData:
> Fn::Base64:
> Fn::Join:
> - ''
> - ["#!/bin/bash -v\n",
> "/opt/aws/bin/cfn-init\n",
> "sudo service trove-guest start\n"]
>
> Since you're using yaml, you don't have to se Fn::Join like in json,
> so simplify to this first:
>
> UserData:
> Fn::Base64: |
> #!/bin/bash -v
> /opt/aws/bin/cfn-init
> sudo service trove-guest start
>
> Now, the suggestion was that users might want to do a different prep
> per service_type. First, we need to make service_type a parameter
>
>
> Parameters:
> service_type:
> Type: String
> Default: mysql
>
> Now we need to shove it in where needed:
>
> Metadata:
> AWS::CloudFormation::Init:
> config:
> files:
> /etc/guest_info:
> content:
> Fn::Join:
> - ''
> - ["[DEFAULT]\nguest_id=", {Ref: InstanceId},
> "\nservice_type=", {Ref: service_type}, "]"
> mode: '000644'
> owner: root
> group: root
>
> Now, if a user wants to have a different script:
>
> Mappings:
> ServiceToScript:
> mysql:
> script: |
> #!/bin/bash -v
> /opt/aws/bin/cfn-init
> sudo service trove-guest start
> galera:
> script: |
> #!/bin/bash
> /opt/aws/bin/cfn-init
> galera-super-thingy
> sudo service trove-guest start
>
>
> And then they replace the userdata as such:
>
> UserData:
> Fn::FindInMap:
> - ServiceToScript
> - {Ref: service_type}
> - script
>
> Please can we at least _try_ not to reinvent things!
>
> ___
> 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
Re: [openstack-dev] [Trove] Templates in Trove
+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 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 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 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
>>>
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
>>>
>>>
>>
>>
Re: [openstack-dev] [Trove] Templates in Trove
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 side template for your Heat template.
The only argument for templating is "If I want some things to be
custom I can't have them custom."
You may not realize this, but Heat templates already have basic string
replacement facilities and mappings, which is _all_ you need here.
Use parameters. Pass _EVERYTHING_ into the stacks you're creating as
parameters. Then let admins customize using Heat, not _another_
language.
For instance, somebody brought up wanting to have UserData be
customizable. It is like this now:
UserData:
Fn::Base64:
Fn::Join:
- ''
- ["#!/bin/bash -v\n",
"/opt/aws/bin/cfn-init\n",
"sudo service trove-guest start\n"]
Since you're using yaml, you don't have to se Fn::Join like in json,
so simplify to this first:
UserData:
Fn::Base64: |
#!/bin/bash -v
/opt/aws/bin/cfn-init
sudo service trove-guest start
Now, the suggestion was that users might want to do a different prep
per service_type. First, we need to make service_type a parameter
Parameters:
service_type:
Type: String
Default: mysql
Now we need to shove it in where needed:
Metadata:
AWS::CloudFormation::Init:
config:
files:
/etc/guest_info:
content:
Fn::Join:
- ''
- ["[DEFAULT]\nguest_id=", {Ref: InstanceId},
"\nservice_type=", {Ref: service_type}, "]"
mode: '000644'
owner: root
group: root
Now, if a user wants to have a different script:
Mappings:
ServiceToScript:
mysql:
script: |
#!/bin/bash -v
/opt/aws/bin/cfn-init
sudo service trove-guest start
galera:
script: |
#!/bin/bash
/opt/aws/bin/cfn-init
galera-super-thingy
sudo service trove-guest start
And then they replace the userdata as such:
UserData:
Fn::FindInMap:
- ServiceToScript
- {Ref: service_type}
- script
Please can we at least _try_ not to reinvent things!
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Trove] Templates in Trove
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 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 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
>>
>>> 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
Re: [openstack-dev] [Trove] Templates in Trove
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 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
>
>> 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
Re: [openstack-dev] [Trove] Templates in Trove
+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 new
data stores this way.
Denis
I think we could see in the not so distant future where the heat templates
*could* be dynamic in nature. (clusters and such)
On Tue, Oct 29, 2013 at 10:15 AM, Denis Makogon 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
>
>> 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
Re: [openstack-dev] [Trove] Templates in Trove
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
> 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] [Trove] Templates in Trove
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
