GT-EOS:Globus-Toolkit EOS

Globus Toolkit - End of Support Announcement

On May 2017, the Globus team at the University of Chicago announced that they will no longer support the open source Globus Toolkit from January 2018 - see: www.globus.org/blog/support-open-source-globus-toolkit-ends-january-2018

This wiki page is aimed at tracking developments in assessing the impact of this announcement, and ongoing work in ensuring that impact to software with dependencies on Globus Toolkit (GT) is minimized. A publically available mailing list has been setup tracking discussions and work related to this topic: gt-eos@mailman.egi.eu. For information about subscribing to this mailing list and accessing its archives, please click here.

Although EGI hosts this page and the gt-eos@mailman.egi.eu mailing list, the work carried out in this area involves multiple organizations and is neither coordinated nor led by EGI.

Grid Community Forum (GridCF)

The Grid Community Forum GridCF has been setup to provide broad community-based support for core software packages in grid computing. GridCF aims to support a new software stack called the Grid Community Toolkit (GCT). The GCT is an open-source fork of GT.

Globus components dependencies

• GridFTP
• GSI
• MyProxy

Affected products

Product	Contact	Notes	Status	Plans
ARC-CE	Maiken Pedersen			Same message as Andrea for StoRM.
CREAM-CE	Cristina Aiftimiei, Paolo Andreetto	CREAM and BLAH both affected		[2017-06-19]  At a first glance we have dependencies from the globus toolkit in the CREAM UI and BLAH. There're no dependencies in the CREAM service. In the worker node it is just necessary to replace the commands grid-proxy-* with the java-base voms-proxy-* The toolkit is used basically for: - dealing with proxies - transferring data via gridftp The first point shouldn't be a big trouble, there's a canl-c library that can replace the globus-gsi (in theory). The real issue is the gridftp. What can we use instead of the gridftp? Do you have any feedback from the community about this? We need a file transfer service which supports rfc3820 proxies, or at least a service with pluggable authentication. In my analysis I don't take into consideration the second level dependencies, such as globus in lcmaps/lcas or gridsite. WebDAV: This is a feasible solution. We can have webdav support in tomcat and re-using our trustmanager for dealing with proxies. The major drawback is the performance of an HTTP-based protocol, expecially with big files. In CREAM we need gridftp not only for transferring the sandboxes, which in several cases can be very large, but also for staging the output of the job in the service area. It could be interesting to investigate the new HTTP 2.0 (RFC 7540). As far as I can remember is very different from previous version, it's a binary full-duplex protocol.
DPM	Andrea Manzi
StoRM	Andrea Ceccanti, Cristina Aiftimiei			we are aware of this issue and started an internal discussion on what could be the consequences and the impact on our software. The critical component for StoRM is Globus GridFTP. We can migrate away from GridFTP, but it will take some time. At WLCG workshop the issue was acknowledged [1, slide 18], so I expect that we can either rely on a support extension or on WLCG taking over support for some of the components (in the same fashion INFN took over the maintenance and support for key core Argus components). Cheers, Andrea [1]: https://indico.cern.ch/event/609911/contributions/2629544/attachments/1478848/2292200/WLCG-WorkshopIntro-Man-190617.pdf
WN/UI	Andrea Manzi
FTS3	Andrea Manzi
GFAL2	Andrea Manzi	CGSI-gSOAP and srm-ifce depend on GFAL2
glexec-wn	Mischa Sallé			[2017-06-21] - gLExec-wn depends on Globus via both LCAS and via LCMAPS. - LCAS can probably be made Globus free or 'separated-off' too when really needed (for example for the check-executable plugin) - the functionality of LCAS for glexec-wn, apart from the check-executable plugin, is also available via LCMAPS plugins - LCMAPS also depends on Globus, but can relatively easily be adapted to have the globus-depending code split-off into a separate library - none of the UMD-provided lcmaps plugins depends directly on Globus - the lcas-lcmaps-gt4-interface of course also depends on Globus, but its only use-case (like with the argus-gsi-pep-callout) are within Globus products themselves
xrootd	MattiasEllert
MyProxy	Jim Basney			One option is to continue maintaining MyProxy by removing the dependencies on Globus libraries and packaging. I think all MyProxy functionality can be implemented using OpenSSL rather than GSI APIs. Porting the proxy repository functionality will be more effort than just porting the CA functionality, I think, so we should understand the requirements for both those pieces. The good news is that OpenSSL already contains support for proxy certificates. In any case CILogon and OAuth for MyProxy will continue as OAuth / OpenID Connect providers. We're going to rename OAuth for MyProxy (OA4MP) and document how it can be used without MyProxy. We have big plans for OA4MP.

Contacts from UMD product ID cards page and Technology Providers page

Globus Toolkit Documentation and Mailing lists

Globus Toolkit documentation is currently available in the following areas:

https://github.com/globus/globus-toolkit-documentation

Notes

• GSI package can probably be replaced directly with OpenSSL (requires work)