You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

The purpose of this page is collecting the list of the Technology Providers, namely institutions, enterprises, projects that develop services, products, middleware and provide EGI with them.

The TPs that provide products integrated in the EGI distributions are indicated in the corresponding column "Integration with UMD/CMD".

If products are integrated in CMD, you will see them listed in the following page:

If products are integrated in UMD, you will see them listed at

NameComponentsLeaderContactGGUS SupportIssue TrackingReleasesHomepageIntegration with UMD/CMD
  • AMGA
Soonwook Hwang
  • Unit: AMGA
  • QoS level: Base

  • Schedule:
  • Notes:

  • APEL Client, Library, Parsers, and Server
Adrian Coveney
  • Unit: APEL
  • QoS level: Medium

ARGUS Collaboration
  • PEP client and server (Policy Enforcement Point)
  • PAP (Policy Administration Point)
  • PDP (Policy Decision Point)
  • Config and Monitoring packages
  • ARGUS EES & LCMAPS plugin for Argus
ARGUS Collaboration
  • Unit: 
  • QoS level:
  • Schedule:
  • Notes:

Grid Information System
  • BDII core
  • BDII top
  • BDII site
Maria Alandes Pradillo
  • Schedule:
  • Notes:
  • CREAM [LSF|Torque|SLURM] module
Lisa Zangrando
  • Schedule:
  • Notes:
CREAM (S)GE module
  • CREAM (S)GE module
  • Schedule:
  • Notes:
  • CVMFS server
  • CVMFS client

  • Unit:  CVMFS
  • QoS level: Base
CERN Data Management
  • DMC (Data management Clients)
  • FTS3
Oliver Keeble
  • Schedule:
  • Notes:

  • dCache server and clients
Patrick Fuhrmann
  • Schedule:
  • Notes:
  • UI
  • WN
Cristina Aiftimiei
  • Unit:  EMI UI, EMI WN
  • QoS level: Medium

  • Schedule:
  • Notes:

  • EMIR Server (DSR or GSR)
  • EMIR’s Service Endpoint Record Publisher (EMIR-SERP)
Shiraz Memon
  • Schedule:
  • Notes:
EMIR Manual
Frontier Squid
  • Frontier-Squid
Dave Dykstra (FNAL)
  • Unit:  Frontier-Squid
  • QoS level: Medium

  • Schedule:
  • Notes:
  • gLexec
  • LCAS
  • SCAS
  • Argus C-PEP plugin
Mischa Salle (NIKHEF)
  • Unit: 
  • QoS level:

  • Schedule:
  • Notes:
  • GridSite
  • L&B
  • ProxyRenewal
  • gsoap-gss
  • caNL
  • rOCCI-server
  • rOCCI-core
  • rOCCI-api
  • rOCCI-cli
  • jOCCI-core
  • jOCCI-api
  • oneacct-export
  • nagios-promoo
  • cloudkeeper
  • cloudkeeper-one
  • keystorm
Zdeněk Šustr
  • Schedule:
  • Notes:

  • QosCosGrid
Tomasz Piontek
  • Schedule:
  • Notes:

  • StoRM
Andrea Ceccanti
  • Unit:  StoRM
  • QoS level:Medium

  • Schedule:
  • Notes:

  • UNICORE-Client
  • UNICORE-Server
Bernd Schuller
  • Schedule:
  • Notes:

Lawrence Field
  • Unit:  REBUS
  • QoS level:Base

  • Schedule:
  • Notes:

gLite Identity Security
  • gLite Identity Security
John White
  • Schedule:
  • Notes:

LSF Utils
  • LSF Utils
Ulrich Schwickerath
  • Schedule:
  • Notes:

ELOG Operations
  • ELOG Operations
Stefan Roiser
  • Schedule:
  • Notes:

gLite Yaim Core
  • gLite Yaim Core
Cristina Aiftimiei
  • Schedule:
  • Notes:

  • SAGA
Antony Wilson
  • Unit:  SAGA
  • QoS level: Base

  • Schedule:
  • Notes:

  • EGCF
Ionel Muntean
  • Unit:  EGCF
  • QoS level:Base

  • Schedule:
  • Notes:

  • Keystone-VOMS
  • ooi
  • cASO
  • cloud-bdii-provider
Alvaro Lopez
  • Unit: 
  • QoS level:
  • Schedule:
  • Notes:

  • JupyterHub
  • BinderHub
  • Jupyter
Benjamin RK
  • Unit: EGI Notebooks
  • QoS level: base
  • Schedule:
  • Notes:

HTCondor-CEHTCondor-CEJaime Frey

  • Unit: 
  • QoS level:

  • Schedule:
  • Notes:

  • Unit: 
  • QoS level:

  • Schedule:
  • Notes:

Support UnitProduct TeamLeaderContactQoS
Steve Traylensteve.traylen AT cern.chMedium
VOMSVOMS-StoRMAndrea Ceccantiandrea.ceccanti AT cnaf.infn.itMedium
VOMS-AdminVOMS-StoRMAndrea Ceccantiandrea.ceccanti AT cnaf.infn.itMedium
EMI UIEMI Common (UI & WN)Cristina Aiftimieicristina.aiftimiei AT pd.infn.itMedium
EMI WNEMI Common (UI & WN)Cristina Aiftimieicristina.aiftimiei AT pd.infn.itMedium
gLite SecuritygLite securityJohn WhiteJohn.White AT cern.chMedium
IDGFIDGFRobert LovasRobert.Lovas AT sztaki.mta.huMedium
WMSWMSAlvise Dorigoalvise.dorigo@pd.infn.itMedium
WNoDesWNoDeSElisabetta Ronchieri

elisabetta.ronchieri AT

Applications Database (AppDB)AppDBMarios Chatziangelouappdb-support AT iasa.grMedium
MPIgLite MPIEnol Fernandezenolfc AT ifca.unican.esMedium
GstatGstatAsa Hsu
Andrea Guariseandrea.guarise AT to.infn.itBase
Slávek Licehammerperunv3@metacentrum.czBase
UI WN Tarball SU
Matthew Doidgem.doidge AT
ARCNORDUGRID-ARCBalazs Konya / Oxana Smirnovaoxana.smirnova AT

Initial activities - Joining UMD Release Team

To be included in UMD Release Team (URT) the interested Technology Provider should provide following information:

  1. Name of the Product team
  2. Contacts (support email address, web site address)
  3. Name and contact details of the Component Development Team Leader
  4. Description of the Component/Product and its Purpose
  5. Release channels for the product:
    • where to find the packages and their updates
    • components/products should be provided in the native packaging format of the OSs supported in UMD (i.e. as rpms for SL5 & SL6, and deb packages for Debian)
    • packages should have dependencies on packages provided by the respective OS and EPEL (for Fedora/SL family)
    • any other external dependencies should be also provided or referenced as being provided by other Technology Providers part of the URT team
  6. Documentation references – installation & configuration guides, release notes, known issues and troubleshooting, reference cards
  7. Which releases, versions, are going to be released in UMD and with which support calendar
  8. Communicate if TP have information on sites already deploying the software that can be interested in acting as Early Adopters in the staged rollout phase.

All information will be included into UMD products ID card

To send join request please read: How to join

With the help of the EGI UMD Release Team (URT), the following steps need to be performed:

  1. Create GGUS Support Unit to receive and handle incidents (define level of quality of support)
  2. Agree on Technical Provider Underpinning Agreement (TP UA) with
  3. Subscribe to the UMD Release team mailing list

First release

This section describe workflow of adding first release: 

  1. First packages are pulled into the untested area of the UMD repositories
  2. UMD team starts the first verification, involving the TP, in order to:
    • understand how deployment should be done
    • check the present Quality Criteria definitions and determine if the common criteria apply or not, if specific criteria are needed for the new products
    • update the Verification and Staged Rollout Reports template, if needed
    • provide workarounds or new versions of the packages if issues are discovered
  3. after a successful verification packages are moved in the testing area of the UMD repos and the Early Adopter sites/sites are contacted for deploying the new release, and after a grace period of few days, to provide the Staged-Rollout report with the results of these testing phase.
    • If issues are discovered – if possible workarounds will be documented, otherwise the product is rejected and a new version should be provided (fixing the issues)
  4. After a successful Staged-Rollout packages are moved in the UMD Store area, and will become part of the next available UMD release.

Ongoing activities

Once Technology Provider join UMD Release Team the following activities should be performed each time new version of product has been released.

Software Delivery

Goal: Submitting new software releases

  1. Communicate information about new update
  2. Information needed for each update:
    • Product Name & Version
    • Release Notes as:
      • What’s New – bug fixes, new features
      • Installation & Configuration instructions – what needs to be done to correctly update the product (package, service) on production infrastructure
      • List of Packages to be updated
      • Location where the packages are available:
  • No labels