On Sun, May 27, 2012 at 9:10 AM, devzero2000 <pinto.e...@gmail.com> wrote:
> 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. > > as far as i know, kernel is a very specific usage case, and while rpm does support it, yum does not (kernel multi version in yum is hard coded). Ohad > > 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-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. > > > > > > -- > Inviato dal mio dispositivo mobile > > -- > 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. > > -- 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.
