Hi Jeff, thanks for your ideas!
On Wed, Apr 14, 2010 at 3:12 PM, Jeff McCune <[email protected]> wrote: > 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. This makes sense. I cold have a 'wrapper' for each module including a versioned class depending on some passed parameter, e.g. I pass through my external node script the version of the nas module $nas_version and define a class like: class nas::mount { include nas::mount-$nas_version } in this way I could get rid of the naming scheme in the main class, but - as far as I tried it - it's not possible to include classes with names composed of variables... Further I'm not yet seeing how I get rid of my virtual resource problem... or wait... I then could use an own class per mountpoint instead of a virtual resource. So using include instead of realize. hmm... Thanks a lot so far. Frederik > > 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. > > -- 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.
