On Friday, September 28, 2012 8:47:03 AM UTC-5, jcbollinger wrote:
>
>
>
> On Friday, September 28, 2012 3:31:11 AM UTC-5, pierre-emmanuel degand
> wrote:
>>
>> Hi, I try to include or import a lot of configuration files in a node,
>> but it doesn't work :/
>>
>> I create a module to configure bind, but i have a lot of domains to
>> configure in the node of my server, so i decided to create an other module
>> just to register my configuration with 1 file per domain (i have around 200
>> domains, so arount 200 files...).
>>
>> My tree (for the configuration module) :
>> module/
>>
>> conf_bind/
>>
>> manifests/
>>
>> init.pp
>>
>> bind/
>>
>> domain1_conf.pp
>>
>> ...
>>
>> domain200_conf.pp
>>
>>
>> Init.pp :
>> class conf_bind {
>> }
>>
>> I tried " import 'bind/*.pp' " , but it worked only once on my VM... The
>> only solution i have now it's to include my domain*_conf one by one, but
>> i'll be very long...
>>
>> If someone got an idea :) thanks
>>
>>
> The 'import' function is the wrong tool for this job (indeed there is only
> about one job for which it is appropriate).
>
> You don't describe the contents of your bind/domainX_conf.pp manifests,
> but with the layout you describe, each should be of this form:
>
> class conf_bind::bind::domainX_conf {
> # declarations for configuring domain X...
> }
>
> Then in the module's init.pp you would have:
>
> class conf_bind {
> include 'conf_bind::bind::domain1_conf'
> include 'conf_bind::bind::domain2_conf'
> # ...
> include 'conf_bind::bind::domain200_conf'
> }
>
> Puppet DSL does not provide a way to use pattern matching to assign
> classes to nodes, and it does not provide for textual interpolation in the
> manner of the C preprocessor's "#include" directive. In particular,
> Puppet's 'include' function performs a fundamentally different job than
> does cpp's "#include".
>
>
On the other hand, there is probably an all-around better way to do this.
I'm guessing that the manifests for your domains are all pretty much the
same form, but with different data. In that case, you might be better off
separating the data from the manifests.
Puppet's primary general-purpose data access API is hiera, which is an
add-on to Puppet 2 but a built-in in Puppet 3. If you organize your data
suitably then you can use hiera to serve it up to your module as a hash of
hashes something like this:
{
domain1 => {
propertyA => 'valueA1',
propertyB => 'valueB1',
...
},
...
domain200 => {
propertyA => 'valueA200',
propertyB => 'valueB200',
...
}
}
Combine that with a suitable Puppet defined type and the create_resources()
function, and your module can hook it all together something like this:
class conf_bind {
create_resources('conf_bind::domain', hiera('bind_domains'))
}
where 'conf_bind::domain' is the name of the defined type that wraps the
per-domain declarations, and 'bind_domains' is the key with which hiera
will look up your data.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/qwb4qQdG4D0J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
