SCIENTIFIC-LINUX-USERS Archives

May 2015

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
David Sommerseth <[log in to unmask]>
Reply To:
David Sommerseth <[log in to unmask]>
Date:
Wed, 20 May 2015 22:36:42 +0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (32 lines)
This sounds like a little troll-bait.  But I also feel your claim that Red Hat not being willing to fix things in EL6 is missing the point of enterprise distributions.  I generally disagree to your statement, but on the other hand - you are not completely wrong either.

First of all, you should beware of the life cycle policy of RHEL, which impacts SL.
<https://access.redhat.com/support/policy/updates/errata/>

That means that once a new major release of RHEL is out, it aims to be rock solid and stable for a long time.  That means that rebasing to newer package versions doesn't happen if the risk to destabilize the distribution is too high.  But roughly every 3-4 year, a new major release is made available which does bring in newer versions of the packages in the distribution.  However, minor releases gets a lot of bug fixes, enhancements and security fixes.  But generally when a new major release has arrived, the primary focus is naturaly on that release - but EL6 still gets lots of love and care for a long time forward.  But have in mind that Red Hat isn't such a big company compared to other in the same market segment.  So Red Hat must focus on the important areas.  Some features which you might feel is lacking in EL6 maybe can function better in EL7.  The world does need to move forward too.  Just like there are nice features in newer Windows or OSX releases which never will be made
available in older releases.

I am a strong believer in the model Red Hat has chosen. Because it means that once a RHEL release is public, it is possible to sleep at night as the distribution (to my experience, having done a few RHEL and 30+ SL/CentOS installations from scratch in production) is rock solid and stable.  And security issues are fixed fairly quickly too.  The nature of this slow process means that EL6 does begin to show its age, and EL5 feels like a ancient dinosaur; this is all very normal.  But despite that, these installations are usually very reliable. For me, that is probably the biggest advantage.

The backside of this model is that if you want more bleeding edge feature, you need to do reinstalls with a newer EL release.  Nowadays that means moving towards EL7.  But for me that has not been such a big issue, as most of my boxes are virtualized.  I can install a new VM with a newer EL release, test it, deploy it into production and retire the old one.  VMs makes life fairly easy.  Of course upgrading a (K)VM host is a much bigger deal.  But I've successfully moved a production machine  hosting 10 VMs which ran Fedora 12 to SL6.  I took good backups, especially of all configuration files, installed SL in separate logical volumes and booted SL, tweaked qemu/libvirtd configs and could start all the VMs without any issues.  This approach also gave me a rollback possibility. It would not surprise me if this is possible to do going from SL6 to SL7 on the VM host too.

So my (biased) opinion is that the RHEL base gives you a predictable data centre, which normally is rock solid.  And the flexibility of VMs means that you can have a servers which are updated more rapidly than others, according to their needs.  I also try to separate services into more VMs, so for web services I often have a reverse proxy frontend (based on varnish or nginx) which then multiplexes the requests to different backend web-servers, which uses VMs with database servers.  That means that I can change the web-backend servers more transparent and still use the same database.  I can prepare a new frontend, test it out and just flip the public routing to the new backend, without changing the backends.  Or an upgraded replacement database server can be tested out, and data moved over from the current production data with minimum down-time.  And there are probably even more clever solutions which can make such migrations even more seemless and transparent.

With this ... I can, surely with some work, migrate from EL major releases in a pace which fits my needs.  If the KVM setup has been done in a proper way, you can even migrate VMs from an older server to a newer server more transparently with close to no downtime (depening on configuration).

The result is, I get a rock solid environment which doesn't lock me to particular EL releases.  But I prefer this predictable stability over automated major upgrades or packages which is rebased too frequently - which can cause further instability.  But as always, YMMV.

On 20 May 2015 05:29:12 CEST, ToddAndMargo <[log in to unmask]> wrote:
>Hi All,
>
>Despite Red Hat's assurance that EL6 will be supported
>till 2020, I am finding a lot of stuff that Red Hat
>is not willing to fix in EL6, but is going to or already has
>fixed in EL7.


--
kind regards,

David Sommerseth

ATOM RSS1 RSS2