On Jun 6, 11:13 pm, Ryan Bowlby <rbowlb...@gmail.com> wrote: > Hi Guys, > > I searched through the forum and found a few related threads but no clear > puppet sanctioned solution. We have several modules that require the same > package, for example rsync or gcc.
Yes, this is one of the facets of the module compatibility problem. There is no best solution. > We usually solve these conflicts by > making that package a standalone module. Do you mean a class? You shouldn't need an entire module for each package. > We don't want to have modules > exist for the sole purpose of installing gcc. Initially we had a > development-tools module that installed the RH equivalent of the > "Development Tools" yum group. In some cases only a third of the packages > were truly required, so this solution seems suboptimal. You could split it up into several classes, most declaring multiple packages, each with some kind of logical consistency so that you could pick and choose among them to tailor the config to the needs of specific nodes. That's an intermediate between your first and second options, and it could substantially reduce the installation of unneeded packages. > What would be the downside of creating a module called common-packages > which would become the central location for simple packages (no > daemon/service, etc)? Declare all the packages within the common-packages > class as virtual resources. Then each module can feed off that class for > the individual packages it requires. This would solve the problem caused by > multiple identical package resources being defined throughout modules. I don't see much additional downside beyond what you already have. Using virtual resources is one of the commonly recommended approaches to this sort of module compatibility issue. It is particularly appropriate for Package resources, where different modules rarely have different requirements for resource parameters. Felix is right, though, that class 'common-packages' would not be suitable for sharing, nor would modules with any explicit dependencies on that class. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. 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.
