Awesome, that's exactly what I was looking for.

On Mon, Mar 11, 2013 at 11:02 AM, Ellison Marks <[email protected]> wrote:

> You don't have access to the configs variable What you do have access to
> is the $title variable, which I think is what you want. This is
> automatically set by puppet to the name of the defined type's instance. In
> this case, config1, config2... config100.
>
>
> http://docs.puppetlabs.com/puppet/latest/reference/lang_defined_types.html#title-and-name
>
>
> On Monday, March 11, 2013 10:46:52 AM UTC-7, jc.listmail wrote:
>
>> So, this is mostly working now (thanks for the pointers!), but how can I
>> reference the top level "configs" within my define?  For example:
>>
>> configs:
>>   config1:
>>     Name: app1
>>     WorkingDir: /var/app1
>>   config2:
>>     Name: app2
>>     WorkingDir: /var/app2
>>   ...
>>   config100:
>>     Name: app100
>>     WorkingDir: /var/app100
>>
>>  define app::virtualApps($Name, $WorkingDir) {
>>     file {"/etc/apps/$configs[0].conf":
>>           owner => root,
>>           group => root,
>>           mode => 644,
>>           content => template("app/foo.conf.erb"
>>   }
>> I want to be able to reference "config1", "config2", ... "config100" as a
>> variable ($config)from within the define.  In this case, using them as the
>> base file name for each instance of a config file.
>>
>> The error I get when trying to process this file is:
>>
>> Error: Could not retrieve catalog from remote server: Error 400 on
>> SERVER: Must pass config to app::virtualApps[config1]
>>
>>
>> On Fri, Mar 8, 2013 at 2:49 PM, Ellison Marks <[email protected]> wrote:
>>
>>> Through create_resources, Name and WorkingDir are being passed to your
>>> defined type as parameters. Your defined type though, does not accept
>>> parameters. something like this:
>>>
>>> define app::virtualApps($Name, $WorkingDir) {
>>>
>>> should work, though you'll also have to work out case, as it seems
>>> you're using lower case in your template and upper in your YAML. The YAML,
>>> defined type parameters and template should all match, variable name-wise.
>>>
>>>
>>> On Friday, March 8, 2013 2:18:30 PM UTC-8, jc.listmail wrote:
>>>>
>>>> I'm trying to use create_resources to create a series of files with
>>>> semi-custom content based on a template.
>>>>
>>>> This is what I have:
>>>>
>>>> foo.conf.erb:
>>>>   Name "<%= name %>"
>>>>   WorkingDir "<%= working_dir %>"
>>>>   ...  a bunch of static entries
>>>>
>>>> YAML:
>>>>
>>>> configs:
>>>>   config1:
>>>>     Name: app1
>>>>     WorkingDir: /var/app1
>>>>   config2:
>>>>     Name: app2
>>>>     WorkingDir: /var/app2
>>>>   ...
>>>>   config100:
>>>>     Name: app100
>>>>     WorkingDir: /var/app100
>>>>
>>>> manifest:
>>>>   class app {
>>>>
>>>>    create_resources(app::**virtual**Apps, hiera('configs'))
>>>>
>>>>   }
>>>>
>>>>   define app::virtualApps() {
>>>>     file {"/etc/apps/$app.conf":
>>>>           owner => root,
>>>>           group => root,
>>>>           mode => 644,
>>>>           content => template("app/foo.conf.erb"
>>>>   }
>>>>
>>>>
>>>> I know this is not correct.  I am missing at least one important
>>>> concept here.  What I am stuck on is how, using create_resources, I can
>>>> reference the parameters named in the YAML config so that I end up with a
>>>> config file on the file system for each.  My understanding of
>>>> create_resources was that this would be a good use for it, in that it will
>>>> call app::virtualApps() once for each hash defined under "configs" in the
>>>> YAML file, which should result in the structure I want.  What I am not
>>>> getting is what the datastructure looks like that is being provided to
>>>> app::virtualApps() and how you can reference those parameters, both in the
>>>> define AND the associated template.
>>>>
>>>> I'd like to end up with:
>>>>
>>>> /etc/apps/app1-100.conf with the contents that look like:
>>>>
>>>> Example:
>>>>
>>>> /etc/apps/app1.conf:
>>>>   Name "app1"
>>>>   WorkingDir: "/var/app1"
>>>>   <bunch of static entries that are the same in each file>
>>>>
>>>>
>>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Puppet Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to puppet-users...@**googlegroups.com.
>>> To post to this group, send email to [email protected].
>>>
>>> Visit this group at 
>>> http://groups.google.com/**group/puppet-users?hl=en<http://groups.google.com/group/puppet-users?hl=en>
>>> .
>>> For more options, visit 
>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>> .
>>>
>>>
>>>
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to