New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pluggable LFN2PFN algorithms #570
Comments
Fully agree with all Brian wrote 😄(This also hooks in a little bit with the way we import external policies. eventually we should have a better mechanism to import the policies, without the need of them being part of the rucio package - but lets have a separate issue for this) Just one side note, as I looked at the code recently. For the site2site transfers a different method ( |
Ok, I have a work-in-progress branch for this -- will be testing this out for LIGO (where this is most urgent). |
Additionally adds python client API for retrieving a PFN.
…fn2pfn Transfers: Implement pluggable LFN2PFN algorithms. Fixes #570
Alright, I think this one is good to go! |
Outside ATLAS (particularly, for CMS), space tokens are optional at some SRM endpoints. Previously, for rucio#574, we fixed the conveyor to handle empty space tokens. Additionally, the fix for the client-side of rucio#575 got mistakenly wrapped up in rucio#570 (pluggable LFN2PFN) and put into `next`. This is the missing piece for `master`.
Previously, we introduced a mechanism to specify the algorithm used for LFN2PFN at the RSE. The options now are
default
andidentity
. Thedefault
algorithm creates subdirectories based on hashes of the LFN, whileidentity
is the identity function: LFN is used directly.As new communities come in, each has their own twist on the LFN2PFN mapping. Currently, there's no good way to add community-specific code for the mapping. I propose we:
So, Rucio could continue to offer one or two stock algorithms -- but as experiments mature, this can become part of their policies.
The text was updated successfully, but these errors were encountered: