On Oct 21, 2009, at 3:34 AM, Sven Mueller wrote:

> Luke Kanies schrieb:
>> On Oct 19, 2009, at 6:19 AM, Bernhard Bock wrote:
>>> Hi,
>>> I'm trying to develop a class that autogenerates a config file based
>>> on an .erb template.
>>> It shall populate the config file with data exported from various
>>> hosts.
>>> Some pseudocode to clarify my issue:
>>> node n1 {
>>>  @@mytype {
>>>     "name":
>>>     property => "foo"
>>>  }
>>> }
>>> template.erb:
>>> <% mytype.each do |bar| %>
>>> <%= bar.name %>
>>> <%= bar.property %>
>>> <% end %>
>>> My question is: How can I access and iterate through the exported
>>> resources in the template? mytype.each will not work...
>> This is getting into semi-supported internal APIs, but you can get  
>> the
>> resource list from the catalog, something like this:
>> compiler.catalog.vertices.each do |resource|
>>   resource.title
>>   resource[:property]
>> end
> Being semi-supported or not, can I get to this from a template? I  
> tried
> with lookupvar('compiler') and lookupvar('compiler.catalog.vertices'),
> but lookupvar returns not the variable, but a string. And that is  
> empty
> in both cases. Do I need to define my own function to return something
> more useful?

Ah; I think you need scope.compiler.catalog, sorry.  We should make  
that visible within the template, I guess.

> Also: how can I check which type the resource has? "resource.type"  
> seems
> wrong (as I expect that the ruby Type is not the same as the type)?

It actually is 'resource.type' - Ruby has deprecated 'type' as a means  
of getting the class, so I was comfortable using it.

> The idea Bernhard had, if I understand it correctly, is to use a  
> custom
> type just to store the wanted data (and being a type, not a variable,
> many instances can exist and get exported). The data is then collected
> by a template. For me, this has two advantages (over other solutions
> available to collect data from multiple hosts):
> 1) The user can change the template as needed
> 2) The resulting file is not edited, but recreated on each run, so its
>   content is deterministic after the run, even if someone edited it
>   manually beforehand.

The downsides, though, are that you're directly mapping the resource  
to a file, which is a bit limited unless you're using file fragments  
of some kind.  And if you're doing that, why not just export a defined  
type that generates the file with a normal template?

Between two evils, I always pick the one I never tried before.
     -- Mae West
Luke Kanies | http://reductivelabs.com | http://madstop.com

You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to