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.

Difference between revisions of "Globus EOL assessment"

From EGIWiki
Jump to navigation Jump to search
 
(15 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Announcement  ==
Please note that this page has been moved to [https://wiki.egi.eu/wiki/GT-EOS:Globus-Toolkit_EOS here].
 
"starting in January 2018, the Globus team at the University of Chicago will no longer support the open source Globus Toolkit" [https://www.globus.org/blog/support-open-source-globus-toolkit-ends-january-2018 www.globus.org/blog/support-open-source-globus-toolkit-ends-january-2018]
 
== Affected products  ==
 
{| width="1154" cellspacing="1" cellpadding="1" border="1"
|-
| '''Product'''
| '''Contact'''
| '''Notes'''
| '''Status'''
| '''Plans'''
|-
| ARC-CE
| Maiken Pedersen
|
|
|
|-
| 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<br>
|
|
|
|-
| 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.<br> - LCAS is probably not going to be made globus-free (that would be too<br> &nbsp; much effort) and just removed as a dependency for the glexec-wn:<br> &nbsp; The functionality of LCAS, apart from the check-executable plugin, is<br> &nbsp; also available via LCMAPS plugins.<br> - LCMAPS also depends on Globus, but can relatively easily be adapted to<br> &nbsp; have the globus-depending code split-off into a separate library.<br> - none of the UMD-provided lcmaps plugins depends directly on Globus.<br> <br> Whether the splitting of LCMAPS will be necessary depends of course on<br> what the exact future of Globus is going to be.
 
|-
| xrootd
| MattiasEllert
|
|
|
|}
 
<br>
 
Contacts from [https://wiki.egi.eu/wiki/UMD_products_ID_cards UMD product ID cards page] and [https://wiki.egi.eu/wiki/Technology_Providers Technology Providers page]
 
== Notes<br>  ==
<div class="truncatedRichText">
*GSI package can probably be replaced directly with OpenSSL (requires work)
</div>
== Log  ==
<pre>[2017-05-29] Andrea Manzi reported at URT meeting about Globus announcement
[2017-06-16] Creating wiki
[2017-06-16] Contacted Product Teams
[2017-06-19] [https://indico.cern.ch/event/609911/contributions/2629544/attachments/1478848/2292200/WLCG-WorkshopIntro-Man-190617.pdf WLCG WS] I. Collier in touch with NSF to ask about support for LHC, they recognize the problem. No feedback yet. What will OSG and EGI do? Fall back is: WLCG takes relevant packages and maintains them (gsi, gridftp, myproxy) and perhaps eventually replaces them.
 
</pre>

Latest revision as of 16:29, 30 November 2017

Please note that this page has been moved to here.