Difference between revisions of "Muddleware"

From GridPP Wiki
Jump to: navigation, search
(Replaced content with "Edited with some proposed changes - previous content beneath. = EGI repo best practice = == Current repos == * Production: UMD4 * Testing: UMD Preview = EGI Ops ongoin...")
Line 15: Line 15:
 
* Storage accounting  
 
* Storage accounting  
  
= Previous content =
 
  
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 =
+
{{KeyDocs|responsible=David Crooks|reviewdate=2018-05-8|accuratedate=2018-05-08|percentage=75}}
 
+
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, [http://research.cs.wisc.edu/htcondor/ 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. 
+
 
+
 
+
 
+
{{KeyDocs|responsible=David Crooks|reviewdate=2018-05-8|accuratedate=2015-07-06|percentage=80}}
+

Revision as of 08:31, 8 May 2018

Edited with some proposed changes - previous content beneath.

EGI repo best practice

Current repos

  • Production: UMD4
  • Testing: UMD Preview

EGI Ops ongoing campaigns

  • Update to UMD4 as UMD3 decommissioned
  • IPv6 readiness
  • webdav probes
  • Storage accounting


This page is a Key Document, and is the responsibility of David Crooks. It was last reviewed on 2018-05-8 when it was considered to be 75% complete. It was last judged to be accurate on 2018-05-08.