Hi!
I would appreciate any advice on the best practices
on how to model a collection of services that each
has its own configuration file, but also share a common
one.
Now, the trouble is, that the common configuration file
is not *really* just a place for the common configuration
to reside, but also may have sections dedicated to holding
properties of a particular service (just like /etc/puppet/puppet.conf
has [main] [agent] and [master] sections).
Thus, in reality, the configuration properties are
per service and whether they need to go into a common
configuration file or a service-specific one is NOT cleanly
partitioned and is pretty awkward to remember. Which
means I really don't want to expose the common config
explicitly to the end user.
Instead, I'd like to expose the natural hierarchy of:
class service1($foo, $bar, $baz) {
}
.....
class serviceN($qoo, $zoo) {
}
but the question then becomes -- how can I model a
common configuration file behind user's back so that
$foo, $bar and $qoo end up there.
At first I was thinking that I could utilize a singleton
non-parameterized class and include it multiple
times in all of the serviceX class definitions, but it
seems I can't pass any values into it.
I suppose I can still do that and create a skeleton
of the common config in that singleton class
that would later be manipulated either by augeas or
concat patterns, but this seems to be pretty heavyweight.
What would you, guys, recommend?
Thanks,
Roman.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
