Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

URT:UMD products ID cards

From EGIWiki
Jump to navigation Jump to search


This page reports the main information about the products currently released in UMD:

  • Support calendar for the major releases currently supported
  • Preferred release channels to get the future updates

Product ID cards for UMD4

Product ID cards for UMD4 products can be found here https://wiki.egi.eu/wiki/UMD_products_ID_cards

Products ID cards for UMD2/UMD3

APEL

  • UMD-2 : 3.3.0
    • End of security support 2014-04-30
  • UMD-3 :
    • Packages are available on github page: http://apel.github.io/
    • Latest version of APEL software is 1.1.3 (lib, parsers, client, server) and the SSM messaging software is 2.1.1.
  • Planning to continue to support the current version by maintaining the code in the medium to long term.
    • There are no major updates planned. New features will be added only as part of our funded work to extend the client to new accounting types. This should not impact the CPU accounting client which we intend to continue to support in its current form.
  • We are committing to running the accounting repository service for the next 2 years.
    • In that time, don't expect to make any compatibility-breaking changes to the CPU accounting client. We will be using it as a platform to develop accounting for other usage types. So the main development effort will be in other areas. We will continue to maintain the code as it is the basis for this development in other areas and the accounting repository service that we are providing.

ARC

  • UMD-2 : 2.0.1
    • End of security support 2014-04-30
  • UMD-3 : 4.2.0
  • EPEL: 5.0.3
  • The policy of NorduGrid is to have one major release per year.
    • We support the current release until the next major release is out.
    • Users are then advised to move to the new major release.
    • Feature requests are treated in the same way as bugfixes.
  • Next major release is planned for March 2016 so 15.03 (ARC 5) will be supported until then.
    • Backward incompatibilities should always be expected in any ARC major release, but we can't guarantee that we will break backward compatibility in the next major release.
    • It will be supported until the next major release, so most likely until end of 2015.

ARGUS

  • UMD-2 : 1.5.0
    • End of security support 2014-04-30
  • UMD-3 : 1.6.0
    • End of security support 2014-04-30
  • Release channels (e.g. EMI repos, EPEL repos..):
  • Product main web page:

BDII core

  • UMD-2 : 1.4.0
    • End of security support 2014-04-30
  • UMD-3 : 1.5.0
  • Support for the BDII is guaranteed.
  • For the time being, there aren't any plans for a new major release. If bug fixes or security vulnerabilities are discovered, they will be fixed.
  • BDII codebase has been the same for EMI 2 and EMI 3, and as there are no new features planned, we can expect a long support of the existing versions.

BDII Site

  • UMD-2 : 1.1.0
    • End of security support 2014-04-30
  • UMD-3 : 1.2.0
  • Support for the BDII is guaranteed.
  • For the time being, there aren't any plans for a new major release. If bug fixes or security vulnerabilities are discovered, they will be fixed.
  • BDII codebase has been the same for EMI 2 and EMI 3, and as there are no new features planned, we can expect a long support of the existing versions.

BDII Top

  • UMD-2 : 1.0.1; 1.0.2
    • End of security support 2014-04-30
  • UMD-3 : 1.1.X
  • Support for the BDII is guaranteed.
  • For the time being, there aren't any plans for a new major release. If bug fixes or security vulnerabilities are discovered, they will be fixed.
  • BDII codebase has been the same for EMI 2 and EMI 3, and as there are no new features planned, we can expect a long support of the existing versions.

BLAH

CANl

  • UMD-3 : 2.0.7
    • canl-c++ - is part of ARC

canl-c

  • Reactive maintenance, possibly new features if required. These products are used also in EGI's Federated Cloud platform.
  • There are currently no plans to retire EMI-3 products
  • No tangible plans for other major releases

canl-java

  • currently there are two parallel canl-java major releases:
    • 1.?.?: in EMI repos and Maven central
    • 2.?.?: in Maven central only, i.e. no RPMs/debs.
  • Differences:
    • 2.x depends on latest BouncyCastle, 1.x on 1.46.
    • So far the branches are pretty similar (most of 2.x features and all bugfixes were backported to 1.x).
    • No plans nor time to think about moving 2.x to EMI repositories (due to problems with BC - packaging and compatibility).
  • Updates to the current major release - yes new major releases - no plans so far (besides 2.x which is already available). The problem is that maintaining a matrix of different canl versions compatible with different BC versions is not possible for me.
  • minor features - to the end of 2014. Bigger developments won't be included.
  • standard support - to the end of 2014, but if needed it can be prolonged.
  • security support - to the end of 2014
  • no major release planned (besides 2.x which are different wrt to BC dependency).
    • 2.x are backwards incompatible due to conflicting dependency usage.

CREAM

CREAM LSF module

  • EMI-3 : 2.2.1
  • The current release of 2.2.1 is out of date and should be updated to 2.3.7-1 in UMD-3 as soon as possible. This is the latest version which is available in github.
  • After that - only provide bug fix releases.
  • The info-dynamic-scheduler-lsf is supported at best effort basis. We will continue to do so as long as we need it ourselves, that is as long as we run CREAM CEs with LSF. Currently, there is no plan to retire these CEs yet.
  • No major release planned.

CREAM (S)GE module

  • UMD-3 : 2.1.0
    • best effort support
    • End of Full Support: 2014-04-30
    • End of Standard Updates: 2014-10-30
    • End of Security Updates & EOL: 2015-04-30
  • New major release:
    • Probably in 2015

CREAM SLURM module

CREAM Torque module

CVMFS

dCache-srmclient

We want to inform you, that srm client 2.2.27 is available.

  • UMD-3 : 2.2.22
    • The client will be supported as long as needed and have no new version. However, there is available a 2.6.12-1 srm-client release, which however needs Java 7 on runtime.

DCACHE

  • UMD-3: 2.13.54
    • New release in app db: 2.13.54
  • new golden release 2.16 is available, this, as always will then be supported for two years


  • UMD-3: 2.10.28
    • New release in app db: 2.10.28
    • support the dCache server 2.6 branch until at least end of April 2015
  • new golden release 2.10 in July, this, as always will then be supported for two years
  • golden releases are often backward incompatible
    • Within golden releases we try not to implement new features to keep them stable
    • do not differentiate between standard support and security support only, if it is supported, it is supported.
  • support calendar: http://www.dcache.org/downloads/1.9/index.shtml

DPM/LFC

  • UMD-3 : 1.8.9
  • Support for DPM/LFC is indefinite.
  • LFC:
    • There are no longer any LHC VOs using the LFC.
    • It will still be supported for other VOs, albeit at best-effort.
  • Not planning a major release - in the "major=backward incompatible" sense

EMI UI

EMI WN

Frontier-Squid

FTS3

GFAL/lcg_util

  • UMD-3 : 1.16.0
    • it has been unsupported since October 2014. It has been replaced replaced by gfal2 and gfal2-util.

Data Management Clients (DMC)

gLExec-wn

  • UMD-3 : 1.2.0
    • continued support till at least spring-2016 for gLExec and its direct dependencies like LCMAPS, LCAS, SCAS and their modules such as the Argus C-PEP plugin (including its dependency argus-pep-api-c)
    • we move to a rolling-update model, but do not plan to introduce backward incompatible changes to the ABI or API without officially deprecating the interface at least 11 months in advance
    • security bug fixes will not be rolled in with standard updates, but will always be available as individual fixes
    • we are willing to coordinate API and ABI interface deprecation time lines with EGI UMD and in coordination with other EMI partners.
  • We are supporting our other components under the same conditions. This includes Argus-EES (incl. the Argus-EES-PEPD-OH) and the former-IGE Security-Integration packages (lcas-lcmaps-gt4-interface, lcmaps-plugins-jobrep, saml2-xacml2-c-lib and lcmaps-plugins-scas-client). Also included are the C-based Argus components argus-pep-api-c, argus-gsi-pep-callout and argus-pep-cli.
  • All support and maintenance will continue under the Nikhef PDP reference conditions:
    • security and critical bug fix support is included,
    • any feature requests and any pro-active maintenance needed, provided such a feature or enhancement is also of interest to either the NL-NGI, EGI.eu or a community which is supported by the NL-NGI or Nikhef itself,
    • the necessary software distribution and integration services based on standard OS platform distribution mechanisms and packaging formats,
    • the regular support scope (documentation, 3rd level incident handling, &c) extends to all communities and users that are affiliated or associated with the NL-NGI, EGI.eu, OSG, or Nikhef itself, and for those communities that also use other "EMI" products or products endorsed by the EGCF. Support also extended to any users that obtain software from EPEL or Debian but only insofar as it concerns security and critical bug fixes.
  • The continued maintenance and support is co-supported by the Dutch National e-Infrastructure, coordinated by SURFsara b.v. Although SURFsara expects support for the national e-Infrastructure to be sustained through government funding, no formal guarantees can be given. In the unlikely case our support commitment has to change, we will inform EGI and our partners as soon as possible.

GridSite

  • UMD-3 : 2.2.2
    • Proactive maintenance, possibly new features if required. These products are used also in EGI's Federated Cloud platform.
  • There are currently no plans to retire EMI-3 products
  • No tangible plans for other major releases
  • Backaward incompatible changes:
    • As far as we can foresee, there would be no incompatibilities at protocol level. There could be incompatibilities at binary level. By that, I mean that products using our *libraries* would have to be rebuilt with the new major version, but old clients communicating with new servers, or vice versa, would have no issues.

gsoap-gss

  • UMD-3 : 3.2.0
    • Reactive maintenance
  • There are currently no plans to retire EMI-3 products
  • No tangible plans for other major releases
  • Backaward incompatible changes:
    • As far as we can foresee, there would be no incompatibilities at protocol level. There could be incompatibilities at binary level. By that, I mean that products using our *libraries* would have to be rebuilt with the new major version, but old clients communicating with new servers, or vice versa, would have no issues.

jclassads

*UMD-2 : 2.4.3

    • End of security support 2014-04-30
  • Release channels (e.g. EMI repos, EPEL repos..):
  • Product main web page:

jOCCI

  • CMD ?.x
  • TP: MetaCentrum (CESNET)
  • Release and distribution through Maven
  • Current versions will be supported for the foreseeable future
  • Proactive maintenance plus continued development
  • Documentation: [1]

Keystone-VOMS

  • Contacts: https://github.com/IFCA/keystone-voms/issues
  • URL is: http://ifca.github.io/keystone-voms/
  • Component Development Team Leader: Alvaro Lopez Garcia <aloga@ifca.unican.es>
  • This module is intended to provide VOMS authentication to an OpenStack Keystone V2. It is designed to be integrated as an external authentication plugin, so that Keystone will preserve its original features and users will still be able to authenticate using any of the Keystone native mechanisms.

L&B

  • UMD-3 : 4.0.12
    • Maintenance with minor improvements.
      • Planning ramp-down to reactive maintenance
    • it is currently only used in the Community platform
  • There are currently no plans to retire EMI-3 products
  • No tangible plans for other major releases

lcg-info-clients

  • UMD-3 : 1.0.1
    • minor fixes if they are really needed. No new features or major releases for sure. If one day we manage to move to GLUE 2, we will have ginfo and we would be able to decommission lcg-info-clients.
    • lcg-infosites - bug fixes, but won´t implement new features nor publish GLUE 2.
    • lcg-info - not supported
  • Just as a reminder, both commands can be used for GLUE 1 only. In both cases there haven´t been any modifications in the past two years, I would say. So we shouldn´t expect many changes in any case.

MPI

  • UMD-3 : 1.5.0
    • support is going to be provided.
    • Both adding features as requested by users and maintaining the code.
      • In principle it will be done by updating the current major release.
  • No plan for retiring the current version. New features will be implemented on this release if no major changes are needed for supporting them.
  • will be supported during this year, 2014, for sure. Probably the support will continue next year, but that is still undefined.
  • No plan for a new major release

ONe Integration

  • CMD
    • Lively development, proactive maintenance
  • Components:
    • oneacct-export
    • perun-slave-process-opennebula
    • nagios-promoo
    • itchy
    • nifty
  • Frequent ad-hoc releases as needed

ProxyRenewal

  • UMD-3 : 2.1.3
    • Reactive maintenance
  • There are currently no plans to retire EMI-3 products
  • No tangible plans for other major releases

QosCosGrid [QCG]

  • UMD-3: 3.x
    • Support model: last revision of a released major release
    • full support: at least to the end of the year 2015, hopefully longer
    • (security) bug fixes: at least to the end of the year 2018, hopefully longer
    • new major release (incompatible with the current one) will be released only if it is necessary for some reason. We will try to keep the backwards compatibility of new releases as long as possible.
  • Release channels (QCG repository):
  • Product main web page: www.qoscosgrid.org

rOCCI

  • CMD ?.x
  • TP: MetaCentrum (CESNET)
  • DEB + RPM packages
  • Current versions will be supported for the foreseeable future
  • Proactive maintenance plus continued development
  • Releases through AppDB
  • Documentation: [2]
  • rOCCI-server: server-side support for OpenNebula v. 4.4 and higher, AWS (Amazon Web Services)
  • Contextualization scripts for automated installation and configuration:

SLURM WN config

STORM

TORQUE server config

  • UMD-2 : 1.0.0; 1.0.1
    • End of security support 2014-04-30
  • UMD-3 : 1.0.1
    • End of security support 2014-04-30
  • NOT supported

TORQUE WN config

  • UMD-2 : 1.0.0
    • End of security support 2014-04-30
  • UMD-3 : 1.0.0
    • End of security support 2014-04-30
  • Release channels:
  • NOT supported

UNICORE Client6

  • UMD-3 : 6.0.0
    • Full support (new features) – by April 2014
    • Standard support (bug fixes) & Security support (security vulberability fixes) – until the end of 2014
  • New major release:
    • we already are working on releasing the next major release (UNICORE 7) in EGI / UMD.
    • No backward incompatibilities
    • To be released in July 2014
    • we plan to fully support UNICORE 7 at least until end of 2015, by which time the next major release should be available. Critical security fixes will be provided after that date, if required.

UNICORE Gateway

  • UMD-3 : UNICORE Gateway6 5.0.0
    • Full support (new features) – by April 2014
    • Standard support (bug fixes) & Security support (security vulberability fixes) – until the end of 2014
  • New major release:
    • Version 7.2.0 (released via UMD)
    • No backward incompatibilities
    • To be released in January 2015
    • we plan to fully support UNICORE 7 at least until end of 2015, by which time the next major release should be available. Critical security fixes will be provided after that date, if required.

UNICORE HILA

  • UMD-3 : 2.4.1
    • NOT supported

UNICORE Registry

  • UMD-3 : UNICORE Registry6 6.0.0
    • Full support (new features) – by April 2014
    • Standard support (bug fixes) & Security support (security vulberability fixes) – until the end of 2014
  • New major release:
    • Version 7.2.0 (released via UMD)
    • No backward incompatibilities
    • To be released in January 2015
    • we plan to fully support UNICORE 7 at least until end of 2015, by which time the next major release should be available. Critical security fixes will be provided after that date, if required.

UNICORE TSI

  • UMD-3 : UNICORE TSI6 5.1.0
    • Full support (new features) – by April 2014
    • Standard support (bug fixes) & Security support (security vulberability fixes) – until the end of 2014
  • New major release:
    • Version 7.2.0 (released via UMD)
    • No backward incompatibilities
    • Individual packages for batch systems (nobatch, torque, slurm, sge, lsf)
    • To be released in January 2015
    • we plan to fully support UNICORE 7 at least until end of 2015, by which time the next major release should be available. Critical security fixes will be provided after that date, if required.

UNICORE UVOS

  • UMD-3 : 1.6.0
    • NOT supported

UNICORE XUUDB

  • UMD-3 : 2.0.0
    • Full support (new features) – by April 2014
    • Standard support (bug fixes) & Security support (security vulberability fixes) – until the end of 2014
  • New major release:
    • Version 2.1.2 (released via UMD)
    • No backward incompatibilities
    • To be released in January 2015
    • we plan to fully support UNICORE 7 at least until end of 2015, by which time the next major release should be available. Critical security fixes will be provided after that date, if required.

UNICORE/X

  • UMD-3 : UNICORE UNICOREX6 6.0.0
    • Full support (new features) – by April 2014
    • Standard support (bug fixes) & Security support (security vulberability fixes) – until the end of 2014
  • New major release:
    • Version 7.2.0 (released via UMD)
    • No backward incompatibilities
    • To be released in January 2015
    • we plan to fully support UNICORE 7 at least until end of 2015, by which time the next major release should be available. Critical security fixes will be provided after that date, if required.

VOMS admin

VOMS

WMS

yaim-core

  • UMD-3 : 5.1.1
    • End of security support 2014-04-30
  • Release channels (e.g. EMI repos, EPEL repos..):
  • Product main web page:

SAGA

  • UMD-2 : 1.6.1; 1.6.2
    • End of security support ????-??-??
  • Reelase channels (e.g. EPEL repos, IGE repos..):
  • Product main web page:

IGE-Security-Integration

  • UMD-3 : 3.? (should have 3.0.0 but got stranded in staged rollout).
  • Components:
    • LCAS-LCMAPS-GT4-interface (dependency for number of EMI components)
    • SAML2-XACML2-C-lib (dependency for SCAS and Argus-EES)
    • lcmaps-plugins-scas-client
    • lcmaps-plugins-jobrep
  • Release channels: EPEL, Debian, IGE/EGCF

Globus products

globus-32-bit

  • UMD-3 : 5.2.4
    • will all be maintained in EGCF release 4!
  • A new major release of the Globus tools, GT6, will be coming out within a month or two. EGCF will package this new release as 4.0 to reflect this change from upstream.
    • HOWEVER: the GT6 release WILL be backwards compatible with GT5! Therefore, we will NOT continue to add new features to EGCF release V3 but instead go with EGCF release V4

globus-default-security

  • UMD-2 : 5.2.1; 5.2.2
    • End of security support ????-??-??
  • Reelase channels (e.g. EPEL repos, IGE repos..):
  • Product main web page:

Globus GRAM5

  • UMD-3 : 5.2.5
    • will all be maintained in EGCF release 4!
  • A new major release of the Globus tools, GT6, will be coming out within a month or two. EGCF will package this new release as 4.0 to reflect this change from upstream.
    • HOWEVER: the GT6 release WILL be backwards compatible with GT5! Therefore, we will NOT continue to add new features to EGCF release V3 but instead go with EGCF release V4

Globus GridFTP

  • UMD-3 : 5.2.5
    • will all be maintained in EGCF release 4!
  • A new major release of the Globus tools, GT6, will be coming out within a month or two. EGCF will package this new release as 4.0 to reflect this change from upstream.
    • HOWEVER: the GT6 release WILL be backwards compatible with GT5! Therefore, we will NOT continue to add new features to EGCF release V3 but instead go with EGCF release V4

Globus GSISSH

  • UMD-3 : 5.3.10
    • will all be maintained in EGCF release 4!
  • A new major release of the Globus tools, GT6, will be coming out within a month or two. EGCF will package this new release as 4.0 to reflect this change from upstream.
    • HOWEVER: the GT6 release WILL be backwards compatible with GT5! Therefore, we will NOT continue to add new features to EGCF release V3 but instead go with EGCF release V4

globus-myproxy

TOREMOVE

  • UMD-2 : 5.6.3; 5.9.1
    • End of security support ????-??-??
  • Reelase channels (e.g. EPEL repos, IGE repos..):
  • Product main web page:

globus-rls

TOREMOVE

  • UMD-2 : 5.2.2
    • End of security support ????-??-??
  • Reelase channels (e.g. EPEL repos, IGE repos..):
  • Product main web page:

GridWay

  • UMD-3 : 5.14.0
    • is no longer actively maintained. There will be security fixes but no major new release is planned. Therefore, it will NOT be in EGCF release V4.

GridSAFE

  • UMD-3 : 1.3.1
    • is being actively maintained and will be included in the EGCF V4 release. However, user support is only available with limited effort.
  • A new major release of the Globus tools, GT6, will be coming out within a month or two. EGCF will package this new release as 4.0 to reflect this change from upstream.
    • HOWEVER: the GT6 release WILL be backwards compatible with GT5! Therefore, we will NOT continue to add new features to EGCF release V3 but instead go with EGCF release V4.

GSI-SSHTerm

  • UMD-3 : 2.0.0
    • will be maintained in EGCF release 4!
    • Maintenance for at least 1 year, however, we assume a much longer maintenance with new features being integrated constantly.

NOT in UMD

STS & Pseudonymity

  • Henri Mikkonen (henri.mikkonen@nimbleidm.com)
    • can still provide security/bug -fixing support for STS and Pseudonymity, but it should be noted that I'm not funded for this activity

Hydra

  • John White (john.white@cern.ch)
    • if there are requests for Hydra I'm happy to fix them. Haven't received anything lately though. I've been adding a Java client to the suite. Once the Java client is tested I'll make a new release.