Revision as of 15:06, 6 July 2015

There's a number of different items of middleware that we use, and this page collects together the immediate and long term velocity for those.

UMD

The UMD is an EGI project, that aims to consolidate all the available middleware in a single repository, after some basic end user acceptance testing has been carried out. Because of this extra layer of testing (Staged Rollout), it is generally recommended that software should be installed from the UMD repository, rather than elsewhere. This results in a lag time of 1-2 weeks between release by middleware provider and inclusion in the UMD.

The main page about the UMD is at http://repository.egi.eu/ There is an official release schedule at https://wiki.egi.eu/wiki/UMD_Release_Schedule which is notionally 3 monthly.

At present the UMD includes software from EMI and IGE.

EMI

EMI did three releases, called EMI-1, EMI-2, and, just for the whimsy of it, EMI-3. EMI-1 was initially released in April 2011, EMI-2 is was in April 2012, and EMI-3 in April 2013.

The EMI project rolls together a number of different middleware producers that were previously separate - notable gLite, ARC, UNICORE, DPM and dCache.

Recent and immediate updates to EMI software were at https://twiki.cern.ch/twiki/bin/view/EMI/EmiEgiGOM (This is typically updated with a view to the next 2-3 weeks), although that ppears to have stopped getting updated.

The EMI project has ended, and it's not totally clear what happening with funding the various bits of software at present.

EMI 1

EMI-1 put a new layer of branding over the existing software, and moved directories around to be more compliant with the Linux Filesystems standards. It supports SL5, plus any others individual products do. This is now out of date, and everyone should be moved to EMI-2. Or EMI-3, if you want to live on the cutting edge.

EMI 2

EMI-2 should increased operating system support to SL5, SL6 and Debian. But only very limied packages on Debian. Other than that, it doesn't appear to be much different. Argus integration is progressing with this released. EMI-2 is also out of date and is no longer in use.

EMI 3

EMI 3 is out - and contains the first version of the EES. The EES appears to be a particularly shy and retiring beast, and any sightings should be reported. It's the final EMI release, so after this we're into 'here be dragons' territory.

EES

The Emi Execution Service is not a method for removal of unwanted developers under Grid control. Instead, it's a description of a way of talking to a CE. Much like the OGSA BES, or CREAM native, or the Globus Gatekeeper interfaces. The key things that separate the EES from other such options is that it shall be supported by all three of the EMI CE providers, and that it doesn't use JSDL. Instead, it provides it's own schema for describing work to be done. This (it is claimed) will allow the model of publishing data and of describing jobs to be the same language, and also to have a job description language that supports multiple providers without needing extensions.

Uptake of this appears to be somewhat underwhelming.

HTCondor

Née Condor, HTCondor is the UWisc middleware for HTC. STFC has been running Condor for a while, and some NGS sites had [www.ngs.ac.uk/sites/default/files/IF08-condor.ppt HTCondor in NGS]. ClassAds were used extensively in job matching.

IGE

IGE package up Globus 5 services, after matching them to the LCMAPS/LCAS/SCAS/Argus authZ/authN stack. These are then pushed to EGI, and therefore are best used via the UMD. If one needs a simple GridFTP server or Globus Gatekeeper, then IGE might be a good source of that.

QCG

The QosCosGrid middleware is of Polish origin, is BES compliant, and is used, amongst other cases, by the Mapper project. This means, to support the Mapper VO's, you need to install it.