[chef] Re: Re: Re: Re: Re: Re: Re: Re: Re: any plan for partial templates in Chef?


Chronological Thread 
  • From: Daniel DeLeo < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: Re: Re: Re: Re: any plan for partial templates in Chef?
  • Date: Wed, 14 Nov 2012 14:48:44 -0800


On Wednesday, November 14, 2012 at 1:38 PM, Andrea Campi wrote:




On Wed, Nov 14, 2012 at 3:29 AM, Daniel DeLeo < " target="_blank"> > wrote:

On Tuesday, November 13, 2012 at 4:26 PM, Andrea Campi wrote:

Just for kicks, I spent an hour tonight trying to figure out how complicated this would be.

This is just a proof of concept, but the spec is green.

It would probably another 1-2 hours to prepare a proper pull request. Unless this is deemed *too* crazy, of course ;)

Attachments:
- 0001-Quick-and-dirty-implementation-of-render-partial-in-.patch
Overall it's the right direction.

Some questions:
* Is there value in having the #render method take either a Hash or String to select which partial to render? Why not just have the method signature be: render(partial_name, variables_as_a_hash=nil)? If variables_as_a_hash was given, you replace the current context variables with a the specified set, otherwise keep them the same.

No other reason that a Rails mindset.
Looking at your example below, I think having the first argument be a String would make the most sense from a Chef background.
 

* Following from the above, is there any need to support running partials from different cookbooks than the template that's being rendered? Or from an on-disk (`local true`) template? This would lead you to a method/option signature like
render("partial_name", :variables => {:foo => "bar"}, :cookbook => "other-cookbook", :local => true, :source => "/var/mytemplates/partial.conf.erb")

Here too, the Rails person in me cringes a little at :local => true, but the Chef person is in strong agreement.


As for use cases, I think we want:

* partials in the same cookbook, to keep things manageable; these are easy;

* partials in different cookbooks: yes please!
There are LWRPs out there that generate a template and let you specify the name of the cookbook. So if you want to override them, you end up copying them from the original cookbook to the one that uses the LWRP—all just to change 2 lines.
Imagine being able to say:

<%= render "foo.conf.erb, :cookbook => "foo" %>
Set bar=baz   # overrides what's in the original template

* local partials: totally!

$ cat etc-hosts.erb

<% hosts.each do |h| %>…<% end %>
<%= render "/etc/hosts.local %>

* (bonus points) collection partials:

$ cat master.conf.erb
<%= render "vhost.erb", :collection => @vhosts, :as => :vhost %>

Where vhost.erb would be rendered once per element in @vhosts (that must be an Enumerable), which would be passed as @vhost
Yeah, that would be a nice addition.
 


Looking at your proposal, I'm not sure about the advantage of passing :source except regularity when compared to a Chef template resource.
Care to elaborate?
I was looking at the list of options for the template resource and adding them all in to my example. I only see this making any sense at all when using local templates, so you could write something like:

render "app specific config stanza",
  :local => true,
  :path => "/srv/my_app/current/config_stanza.erb"

Maybe that's more readable for some people? I don't have a strong opinion here.
 
 

* Is there value in the leading underscore in partial names? This will be natural for Rails people, and yet another thing to learn for everyone else. Does it make it easier to look at your cookbooks and figure out what's going on if the partials look different?

On further thought, no, I think it's too much.
Personally I find it useful to have a naming convention that tells me that a template is meant to be used as a partial.
But I don't think that warrants showing down people's throats—let them figure out their own naming convention.
I could argue both sides on this, I just wanted to make sure we thought about it. 

-- 
Daniel DeLeo




Archive powered by MHonArc 2.6.16.

§