MPU Futures 9/5/17

This week's MPU meeting was one of our occasional attempts to peer into the future and guess what to investigate and prioritise.

Freeing up time

We're going to need to concentrate more on user-centric, user-visible things. Informatics computing staff numbers are not going to grow, but the School of Informatics as a whole is definitely still growing. With that growth comes increasing demand for our expertise and help. We'll have to cope by abandoning areas where we don't add much value over the University's standard provision, to free up time for those things the School needs but the University doesn't do.

We need to make moving to a new or updated platform far less painful - preferably reduce the effort and time needed from months and years to a few weeks. That should free up an awful lot of time.

Adopting Ceph for virtualised shared storage for our KVM servers would massively simplify the maintenance of the Simple KVM Service, freeing up a lot of time.


Our base platform is Scientific Linux. Will it continue? We fear that it may not make it to SL8. What would we do then? We discussed a couple of options.

Centos is the obvious closest alternative to SL. The two are very similar, since they're both basically repackaged versions of RHEL.

However, there is one significant difference which we would have to accept and work with. SL continues to offer security fixes for minor OS releases for some years. We depend on this: we don't need to move a machine or service from (for instance) SL6.8 until it's ready to go to (say) SL7.3. By contrast, Centos only supports its most recent point release of each major version: no security fixes are offered for older point releases.

The frequency of major releases of RHEL - one every few years - has a downside: it's often too outmoded to support emerging technologies which our lecturers and researchers would like to use. It would be good to have a basic platform which moved a little more quickly. But which one?

  • The other obvious RHEL-related platform is Fedora, but major changes every six months would be far too frequent for us (the computing staff) to cope with.
  • Ubuntu offers a new Long Term Support (LTS) release every 18 months. That might well be a convenient timescale to work to. However, the effort of changing from RPM to APT would be high: we would need to redo our software management technology and rebuild our software repositories from scratch.

The question of platforms will be looked at by the DICE Desktop Review.

Specific shorter term needs

It seemed obvious to us that we will need expertise in certain areas in the short to medium term:

Application virtualisation. Containers. These could potentially be a convenient way of distributing software and development environments to students, without the overhead of handing out full virtual machines running entire operating systems.

External cloud services. We should be able to offer advice.

Shared virtualised storage. We should look into SEE's Ceph shared storage for (at least) our KVM service.

Desktop virtualisation. Although NX is now being developed once more, our current NX service wobbles along on a wing and a prayer. Something more robust is needed.

UEFI support. At some point we're going to have to cope with hardware which does not support the legacy BIOS facilities we depend on.

Wayland. We need to be familiar with how it differs from traditional X and how we might offer Wayland-compatible services.

Teaming. Like bonding, it's a way of aggregating NICs to provide redundancy or greater throughput.

In general, we need to keep up with emerging Linux technologies.

Topic revision: r2 - 01 Jun 2017 - 07:42:37 - ChrisCooke
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies