Hi Matthaus, The mcollective plugins installed by separate packages but going into the same path as an "AIO" sounds a bit like reinventing SCLs.
If mcollective was dependent on a ruby run time from an "AIO" puppet package, and one tried to upgrade puppet with mco, I'd expect there to be interesting fireworks... -Josh -- On 11/19/2014 11:28 AM, Matthaus Owens wrote: > Josh, > Facter and mcollective will both be part of the AIO. Rubygems is part > of the ruby stack that will be included in the AIO, so installing gems > shouldn't change much, you would just need to ensure that the gems are > installed using the AIO gem binary. Facter will no longer be > independently upgradable. (For testing and development, we will be > including documentation on how to run the various projects alongside > the AIO from source). Mcollective plugins will still be packaged, and > will be updated to use the new layout so they will be compatible with > the AIO package. > > The AIO model is the model that our windows packages have been using > for some time now with great success. > > On Wed, Nov 19, 2014 at 9:52 AM, Joshua Hoblitt <jhobl...@cpan.org> wrote: >> On 11/18/2014 06:11 PM, Michael Stahnke wrote: >>> On EL6.x, why not use a new SCL? Or even install into the existing >>> ruby193 SCL? >> >> Part of the goal here is to have control of the ruby version. The SCL offers >> one version of Ruby 1.9.3, Ubuntu offers another in their distribution, as >> does Mac OS X, and the next OS. Compound that with libssl fun and End of >> Life constraints on Ruby 1.9.3, and it's just not that fun. (SCLs also have >> their own lifecycle that is different than RHEL). >> >> We'll be picking one Ruby (2.1.z), and using that everywhere for a >> consistent stack. >> >> I'm not unsympathetic to the desire to vendor a version of ruby but that >> doesn't prevent the creation of a new SCL with all PL vendored (is that a >> word?) packages in it. This is a primary use case for SCLs. >> >> I'm a bit concerned about gems and other components accumulating in the path >> tree of an AIO that aren't tracked; I foresee upgrade 'fun'. I think it >> would be preferable to be able to package gems, report processing scripts, >> etc. into RPMs that install into a puppet SCL. >> >> Would facter be part of a puppet AIO? If so, would that mean it's no longer >> independently upgradable? How would you orchestrate agents installing gems >> that are needed by ruby facts? >> >> How would a puppet AIO affect mcollective? Would it be it's own AIO with >> independently vendored dependencies? How would mco agents be installed? >> >> -Josh >> >> -- >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to puppet-dev+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-dev/546CD8D6.8030903%40cpan.org. >> >> For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/546CF97B.1070002%40cpan.org. For more options, visit https://groups.google.com/d/optout.
