The traces you'll find it of are probably from when we used to ship it
as a dependency, but it's since been removed. The core Foreman instance
(which is under the SCL of course) had a dependency on loading the
Puppet library to parse reports etc, and so we had to additionally build
Puppet under ruby193.
In Foreman 1.3 we removed the code that used it internally and so no
longer ship ruby193-puppet. You'll find a copy of our old spec here:
https://github.com/theforeman/foreman-packaging/blob/master/rpms/epel-6/ruby193-puppet/puppet.spec
The other place you might see it is related to OpenShift Origin, as they
use SCLs heavily and I think may rebuild the package.
I think you're pretty much on your own, but it's a direction that I
think Puppet might go in. The Puppet team have been talking about
dropping Ruby 1.8.7 support, and to gain the performance enhancements in
Ruby 1.9, would move to some sort of vendored Ruby install. I hope that
if they do, it'll be based on SCL.
Red Hat shipped RHOS 3.0 with an SCL based Puppet, but since switched
back to non-SCL. The main issues I saw were about file locations, e.g.
where Puppet's $confdir and $vardir should be (/etc/puppet or
/opt/rh/…/etc/puppet, or /etc/opt/rh… which follows FHS). This
then caused problems with things like our installer, which are designed
only for the /etc/puppet location and need various parameters set to
move it. Of course, you can install it under SCL but continue to use a
confdir/vardir on the root filesystem if you're not worried about standards!
The second issue we saw was Puppet's unreadiness for Ruby 1.9 in places
(e.g. unicode support). I think this has got better, particularly in
the very latest 3.x releases, 3.5 included.
It's probably the standardisation of configuration paths and init
scripts that is the messiest obstacle, and probably the most confusing
for users who are used to these being under /etc and /var. If this is
just for your site, then it makes sense, you'll get some good benefits
from Ruby 1.9.
···
On 26/03/14 11:36, attila.bogar@gmail.com wrote:
> Hi All,
>
> I've just joined this group, haven't used foreman in production yet -
> I'm relatively new to foreman.
>
> I set up foreman environment with open source puppet in a vagrant
> environment and what I noticed is that the EL6 ruby 1.8.7 time to time
> crashed (often) (not with foreman, but with puppet).
>
> So I recompiled puppet and facter against ruby193 SCL.
>
> The foreman installer in 1.4.2 is using system ruby foreman-installer
> and foreman-proxy. This broke the installation as my puppet gem was in
> the in ruby193 SCL.
>
> Alright, I rebuilt the SRPMS against the SCL too - foreman-proxy and
> foreman-installer.
> It went relatively smoothly except the clamp rubygem was not prepared
> for SCL, spec needed patching.
>
> The foreman-proxy didn't stop with the init scripts, hence I changed the
> /usr/bin/ruby193-ruby to use exec for the scl part. This kept the pid
> for the init system, worked like a charm.
>
> I'm wondering if this is a viable approach and is there anybody out
> there using foreman completely in SCL ruby193?
>
> I also googled for ruby193-puppet and found some traces, so I guess some
> of you guys must be using it with SCL.
> I'd like to know what are best practices for this are the scl modded
> puppet - are there any specs published somewhere to compare it with my
> version.
>
> Thanks for you comments in advance!
–
Dominic Cleal
Red Hat Engineering
