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 <[email protected]> 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 [email protected]. >> 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 [email protected]. 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.
