On Wed, Apr 14, 2010 at 8:33 AM, Frederik Wagner <[email protected]> wrote:
> <snip>
> So far so good. Now my problem emerges, when a module depends on an
> other module. This should be version independent (and even better
> independent of the module name). For example:
> I have a generic nas-<version>::virtual module, which provides
> mountpoint as virtual resources. These can be realized in multiple
> other modules, without explicitly prepending a Nas-<version>::Virtual,
> so I am independent of version and module name.
I don't personally do a whole lot with the realize function, but the
way I lay out my modules may help with the version dependency problem
you're facing.
In modules I write, my init.pp simply includes a manifest named the
same as the module. For the ntp module I just have import "ntp.pp" in
init.pp
I place all classes in ntp.pp. The first class named ntp is
responsible for doing a selection based on facts to determine the
specific class for the platform the module is configuring. This looks
something like:
# modules/ntp/manifests/ntp.pp
class ntp {
case $operatingsystem {
"RedHat", "CentOS": { include ntp::linux-rh }
"Solaris": { include ntp::solaris }
default: { include ntp::unconfigured }
}
}
class ntp::common { # do stuff }
class ntp::linux-rh inherits ntp::common { # override stuff }
class ntp::solaris inherits ntp::common { # override stuff }
class ntp::unconfigured { # throw warning }
# EOF
ntp::linux-rh and ntp::solaris both inherit from ntp::common and
provide platform specific overrides of the base class. This allows me
to simply classify the node as "ntp" and let the module sort out the
platform specifics, or do nothing at all if the platform isn't
supported. (I do have the unconfigured classes throw warnings).
You should be able to do something similar with specific versions of
your modules. Rather than copy your entire module directory, you
could have modules/nas/manifest/nas-{1,2,3,4,...}.pp, have init.pp do
a import "*.pp" and then have your node classification point at your
specific "versioned" class, e.g. nas::nas-3 (or some better naming
scheme). To achieve your dependency on some consistent "non
versioned" class you could have all of your versioned classes include
or descend from another class in the module, say nas::common or
nas::nas. This class wouldn't necessarily do anything except provide
an anchor to reference in your other modules.
Does this make sense? This is purely me thinking out loud while half
way through my first cup of coffee, so this may not actually solve the
problem but I believe puppet is currently able to provide what you
need, although it may be too much of a hack to be a desirable
solution.
Hope this helps,
--
Jeff McCune
--
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.
