On May 28, 3:00 am, Luke Kanies <[email protected]> wrote:
> External data (that is, data specified outside of Puppet manifests)
> seems to keep coming up. This is a relatively long description of
> where it seems we are and where we should go from here.
I'd like to +1 this discussion in general. My personal #1 wishlist
item is the 'data from other nodes' problem that Daniel mentions.
It seems to me that more separation between logic and data is needed
in Puppet manifests. It's one of the main problems I see with module
redistribution. Apache module A is written for Debian, Apache module B
is written for RHEL, etc. Even if that was cleaned up you still see
$adminpassword variables, and not everyone wants the same list of
modules loaded/installed.
> * Alessandro's presentation caused someone to point out to me
> afterward that case statements of this ilk:
>
> case $operatingsytem {
> debian: { ... }
> redhat: { ... }
>
> }
I echo Jonathans sentiments on this. I think a better alternative to
he above is something like this:
class apache {
include apache::$operatingsystem
}
To add solaris support I add solaris.pp into the load path.
Class[apache::solaris] can then include or inherit
Class[apache::base], as needed. Then I extend the module and limit
conflict with upstream manifests. It may not be ideal, but it works
today.
> * Users should probably be able to put their external data in a
> database, preferably in their external node tool
I'd like to second Daniels comments regarding data of other nodes.
This is pretty much required when configuring distributed services.
Today I can get most of the the way there with storeconfigs & clever
defines, but it's not ideal. I posted a question about hacking faux
distributed key value storage using storeconfigs, but got crickets.
A common use case for me is OpenLDAP replication (syncrepl). Each
slave is identified by a 3 digit integer (rid), which must be unique
in the replication group, that needs to persist for the life of that
replica. So each new slave needs to know the rid of every existing
slave, and then pick the next available rid. The same pattern applies
to MySQL replication, for example.
> I also don't like the idea of just relying on a function - I'd like a
> class to be able to declare that it relies on external data, so that
> users know what they can configure in their class.
Isn't this part of parameterized classes? Today I'd probably do 'if
$value == "" { fail("must define \$value") }' where required.
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" 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-dev?hl=en.
