Tags:
create new tag
view all tags

Future LCFG Platform

Background

In Informatics we have used Redhat as our primary computing platform for 20 years, beginning with Redhat 5 and 6, going through various Fedora (3, 5, 6) and then onto ScientificLinux (5, 6, 7). Although it has served us well we're increasingly finding it to be a poor fit with the requirements of our desktop environment.

At the annual review meeting in December 2018 we discussed whether RHEL was a good choice for our desktop platform or whether we should consider swapping to an alternative. Below are some thoughts on the issues we have with RHEL.

Length of Release Cycle

The greatest issue we have with RHEL for our desktop machines is the length of time between major releases, it is simply far too long which leaves important applications significantly out-of-date.

RHEL have attempted to deal with this problem with the introduction of software collections but users often find using these to be rather awkward. Redhat have also chosen to make major upgrades to certain parts of the distribution (in particular the Gnome desktop environment) which we would prefer to remain unchanged. Specifically we need applications to be more up-to-date whilst having fewer unexpected changes to the general environment in between major releases.

Furthermore, as Redhat is a licensed product this problem is exacerbated by us needing to use a derivative distribution (ScientificLinux or Centos). Once Redhat make a release we must wait for the completion of the rebuilding process which increases the delays.

Predictability of Releases

We have no way of predicting when the next major Redhat release will occur. This means we do not know how it will fit into our teaching calendar and thus we cannot schedule work appropriately. Contrast this with Ubuntu where they have made a Long-Term-Support (LTS) release in April every 2 years since 2008.

Fish Ladder Approach

Over time the size of the differences between the current and next releases of any Linux distribution naturally increases. Thus the longer the release cycle the greater the effort required in one go to update the supported DICE platform. A larger porting project results in a larger time gap between when the upstream vendor makes a release and the point at which we can roll-out a supported platform to our users.

We would prefer a "Fish Ladder" solution where we can tackle regular smaller steps rather than having to attempt to scale a single enormous dam in one giant leap.

A large project to port to a new platform once every 4 years may well involve exactly the same amount of effort as for two smaller projects. However, 2 smaller projects are almost certainly less stressful for computing staff, they will also be easier to prioritise against other projects and users will get access to new software in a more timely manner.

Software Availability

The main RHEL distribution is fairly small. This problem is alleviated by using the "Extra Packages for Enterprise Linux" (EPEL) repository which provides builds of packages from Fedora. Sadly, EPEL suffers from a number of problems which make it much less useful than we would like. Most importantly, when a new RHEL distribution is released the EPEL repository for that release is pretty much empty. This means that significant software (e.g. the KDE and MATE desktop environments) are simply not available and we have to build many packages. We are also reliant on the package maintainers as to what software appears in EPEL, it is not a complete build of Fedora. Over time the quantity of packages does increase to cover most of what we require but these packages tend to only be updated when security issues are found. Consequently over time the age of packages becomes a major issue and we end up returning to building many packages locally. Once the RHEL distribution is released there is a tendency for it to fairly rapidly diverge from Fedora, this means that many Fedora packages can no longer be built on RHEL due to a lack of support for new features in specfiles, this makes local package building even more time consuming. As EPEL is a separate project from RHEL it can also have problems with dependencies when Redhat release updates, for example, at the time of writing it is not possible to install the MATE desktop environment without also enabling the "epel testing" repository.

Contrast this with Ubuntu which provides the largest number of packages (~77000) all of which are available when the distribution is released. There is also fairly excellent official and wider community support for backported packages which makes it easier to selectively update applications where necessary.

Support for Major Upgrades

We have always had to reinstall machines for major upgrades of RHEL as upgrades are not well supported. Although there are other advantages to this approach, for example, changing partition layout to match latest requirements, it would be nice to have the option to just upgrade the packages.

Topics for Investigation

Software Packaging

Building packages of locally developed software for an alternative platform must be just as straightforward as it is now with building RPMs. That means that we the LCFG build tools suite must be updated to add support for the platform (e.g. install locations in filesystem). Ideally the generation of packaging metadata (the alternative to a specfile) would be more-or-less fully automated. There also needs to be support for building packages (i.e. like the current devrpm and rpm commands).

Software Management

We need to be able to manage local package repositories and mirror upstream repositories. Currently that is done with homegrown scripts but it would be nice if we could use standard tools which don't require lots of development.

We need a tool which can manage the installation of software on a system (i.e. like updaterpms).

System Installer

We need to be able to install a system in an automated fashion similar to how it is currently done which allows us to hook in LCFG. One option which should be investigated is FAI - Fully Automatic Installation which has support for ScientificLinux, Centos, Debian and Ubuntu.

-- squinney - 2019-01-11

Topic revision: r2 - 2019-01-11 - squinney
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback