On May 26, 8:56 pm, Anthony Shortland <[email protected]> wrote: > We're using Puppet as part of a broader toolchain that relies on delivering > software for deployment using sets of Yum-based RPM packages. We've setup > system, role and application specific Yum repositories on an > environment-by-environment basis that ensure that the required set of RPM > versions flow appropriately (e.g. from development to QA to staging and hence > to production). > > In this spirit we're packaging our Puppet modules as sets of RPMs too so the > correct versions of the system, role and application specific modules flow > along with everything else.
+1 > Hack the RPM package names to include a version discriminator (e.g. > "packageV1-1.0-noarch.rpm" rather than "package-1.0-noarch.rpm") to allow > them all to be installed on Puppet master I don't think that's too bad. Indeed, yum-based distros do exactly that for so-called "compatibility" libraries. > Use Yum/RPM to install the modules directly on the client systems and find a > way to restrict the Puppet master to managing the manifests rather than > attempting to install the modules too. Turning off pluginsync would probably be all you need to make that work configuration-wise. I'd be a bit nervous about keeping all the plugins synchronized though. I can imagine schemes to make it work, but you need more care and admin effort that way. Or there's at least one other option: cut out Yum for installing these particular RPMs on the master. Since they're targeted only for the master, delivering them via Yum provides fewer advantages than many other uses of Yum. The underlying RPM system should not object as long as the packages don't conflict. I think this is more of a hack than your first option, however, only at a higher level. I think there is some confusion here surrounding the role and purpose of these RPMs. If the primary purpose of each one is to provide a puppetmaster the ability to support a particular system, role, or application (or combination of the above), then what you're characterizing as different versions of the same RPM in fact provide separate and distinct capabilities. As such they *should* have different names. Contrast that with the situation where the primary purpose of the RPMs is to provide Puppet modules to client systems. In that case, the different "versions" provide alternative, conflicting versions of logically the same features. In that case they should have the same name, and it follows naturally that yum objects to installing more than one. All things considered, I think your option 1 is right, good, and proper, not a hack at all. John -- 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.
