Re: mustache documentation and recommedations

That is why we use in SCL framework a bundle where we gather all the 
vars. This will never change and the other services can make use of 
these variables. That is nice for example openldap configurations. A lot
of services make use of these vars. Our data "container" is `scl`, eg:
cfengine syntax
   * $(scl.openldap[server]
   * $(scl.ssh[ListenAddress])

mustach:
   * vars.scl.openldap.server
   * vars.scl.ssh.ListenAddress

This will never change and we can refer to other vars in different services.

On 19/01/2023 16:00, [email protected] wrote:
> We use several mustache templates.  Originally we only made little use 
> of "template_data".  More recently we are using it more (see below).  
> Overall things are OK either way.
> 
> But I'm encountering something where I'd like to see recommendations and 
> cannot seem to find any.  Here's part of our "sshd_config" template, 
> that doesn't yet use "template_data".
> 
> ---------------------------------------------------------
> {{#classes.g_cs_login_pri}}
> {{#vars.g.primary_network_ip}}
> ListenAddress {{.}}
> {{/vars.g.primary_network_ip}}
> {{/classes.g_cs_login_pri}}
> 
> {{#vars.dls_cs_ssh.denied_users}}
> DenyUsers {{.}}
> {{/vars.dls_cs_ssh.denied_users}}
> ---------------------------------------------------------
> 
> Notice how this template definition requires knowledge of the CFE bundle 
> names "g" and "dls_cs_ssh".
> 
> Now, suppose we refactor the CFE code and rename "dls_cs_ssh" to 
> something else.  And suppose, as is quite probable, we overlook (or 
> similarly forget) this corresponding change in a different file.  Then 
> this template will start failing, as it introduces unexpected errors 
> onto the client machines.  The refactoring process is fragile.
> 
> Now in theory we can address this by using "template" data.  This would 
> allow the "vars" items to be simplified to:
> 
> ---------------------------------------------------------
> {{#primary_network_ip}}
> ListenAddress {{.}}
> {{/vprimary_network_ip}}
> 
> {{#denied_users}}
> DenyUsers {{.}}
> {{/denied_users}}
> ---------------------------------------------------------
> 
> because the calling bundle can handle the data much more cleanly and 
> consistently and, where appropriate, use CFE's "$(this.bundle)".
> 
> (We have done such refactoring in other places and it has been very 
> successful.)
> 
> But you'll also notice how this cannot handle the "classes" information 
> as it stands.
> 
> Is there a recommended and succinctly documented way to be able to use 
> "template_data" to pass not only the "vars" but also the "classes"?
> 
> I suspect I could probably hack a way towards inventing my own JSON data 
> structure that would somehow capture all this.  But if that is the way I 
> should go, then it would be re-assuring to know that this is recommended 
> and documented.
> 
> -- David Lee
> 
> -- 
> You received this message because you are subscribed to the Google 
> Groups "help-cfengine" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to [email protected] 
> <mailto:[email protected]>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/help-cfengine/a27a3806-dd5f-4a13-adde-b190b33828b6n%40googlegroups.com <https://groups.google.com/d/msgid/help-cfengine/a27a3806-dd5f-4a13-adde-b190b33828b6n%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
--
Bas van der Vlies
| High Performance Computing & Visualization | SURF| Science Park 140 | 
1098 XG  Amsterdam
| T +31 (0) 20 800 1300  | [email protected] | www.surf.nl |

-- 
You received this message because you are subscribed to the Google Groups "help-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web visit https://groups.google.com/d/msgid/help-cfengine/d2b95402-8bbb-b9fa-9e31-5c41836dd78b%40surf.nl.