---------- Forwarded message ---------- From: devzero2000 <pinto.e...@gmail.com> Date: Sun, 27 May 2012 08:14:53 +0200 Subject: Fwd: [Puppet Users] Managing Puppet modules as RPMs To: rpm-u...@rpm5.org
Fyi. Despite some FUD the use case is interesting for devops. Best regards ---------- Forwarded message ---------- From: devzero2000 <pinto.e...@gmail.com> Date: Sun, 27 May 2012 08:10:54 +0200 Subject: Re: [Puppet Users] Managing Puppet modules as RPMs To: puppet-us...@googlegroups.com Sorry for the top posting. Imnsho, rpm had always permitted to have multiple package version if they not conflict, in fact the usual case is the kernel. Anyway your question is most rpm related: so if you like i suggest you to ask to a rpm mailing list. Best regards 2012/5/27, Anthony Shortland <anth...@dtosolutions.com>: > 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. > > The problem arises when you consider the conflict that arises between the > "natural" use of Yum-based RPM installation and the Puppet master's module > delivery mechanisms. > > Puppet allows "modulepath" to be set on an environment-by-environment basis, > of course, thus supporting delivering different versions of modules from a > master managing several environments. > > The restriction lies with Yum/RPM's inability to allow multiple versions of > the same (relocatable) package to be installed on the same system (even good > old System V packages could do that!). > > I'm looking for workarounds that aren't too egregious to either system! > > Here are the ideas we've come up with so far: > > 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 > 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. > > Is the second method workable? It seems to be a blend between agent and > apply modes. > > We don't want to use apply mode since we really value using the master (even > supplemented with Hiera) to act as the resource model provider to deliver > configuration attributes to the agents as well as act as the node provider > for Rundeck (used for distributed orchestration) using the Puppet/Rundeck > plug-in (which doesn't seem to be environment aware - but that's another > story!). > > We'd appreciate any comments and feedback on this. > > Thanks, > > Anthony. > > > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@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. > > -- Inviato dal mio dispositivo mobile -- Inviato dal mio dispositivo mobile -- Inviato dal mio dispositivo mobile ______________________________________________________________________ RPM Package Manager http://rpm5.org User Communication List rpm-users@rpm5.org
