Skip to content
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

MSOutput: perform custodial data placement #9842

Closed
amaltaro opened this issue Jul 14, 2020 · 6 comments · Fixed by #9911
Closed

MSOutput: perform custodial data placement #9842

amaltaro opened this issue Jul 14, 2020 · 6 comments · Fixed by #9911

Comments

@amaltaro
Copy link
Contributor

amaltaro commented Jul 14, 2020

Impact of the new feature
ReqMgr2MS

Is your feature request related to a problem? Please describe.
MSOutput needs to have the ability to make custodial data placement as well, which means, make transfer requests against MSS/Tape endpoints.

Describe the solution you'd like
This development depends on:
#9841

then we should resume the data placement implementation and adapt whatever is needed to subscribe data against the long term storage (MSS/Tape).

For DDM data transfers, it seem we need to find out the final location in the MSOutput, thus requesting DDM to move data under a specific location.
For Rucio data transfers, it could be that we just need to provide a Tape expression, and let Rucio handle the final location. Needs to be discussed and investigated though.

The general policy we discussed during the Rucio transition meeting was as follows:
a. Use the API / Eric’s logic to pick the tape RSE in MSOutput as mentioned in this issue: #9842 (comment) . The MSOutput should decide where the final destination (the site to which the tape request is made) for the dataset based on the quota and usage for all those.
b. Create the Rucio rule / DDM transfer request for the output datasets (rucio container) before the workflow gets announced (thus, when it's in closed-out state).
c. The Rucio rule should be deleted manually (eventually by Nick)

Describe alternatives you've considered
none

Additional context
To be worked once this one has been implemented: #9841

@nsmith-
Copy link

nsmith- commented Jul 16, 2020

I believe there will remain a need for a per-campaign custodial RSE expression in Rucio, the motivation being HI campaigns which often are to be only archived at FNAL. A default custodial RSE expression could be simply type=TAPE, letting Rucio balance the data as appropriate.
As @ericvaandering pointed out, the approval mechanism may create obstacles for using simple RSE expressions to match all tape sites.

@ericvaandering
Copy link
Member

Today we decided that the best way to do this would be to write a little function to select a Tier1 for us based on the the quota. Here is a little piece of code which implements the algorithm. If you tell me where you want it and which API you want to call it with, I will make a PR for @todor-ivanov

It does need quotas as inputs which don't exist on Tape right now (and probably wants available space instead of quota), but that should be simple to adapt to. But the basics should be there.

https://github.com/ericvaandering/CMSRucio/blob/weighted_rucio_choice/src/pick_rse.py

@amaltaro
Copy link
Contributor Author

One item that still needs to be decided is, whether we pick one Tape RSE per workflow or one Tape RSE per output dataset.
Nick/Eric, please let us know if you have any preference here.

@ericvaandering
Copy link
Member

I have no opinion on this

@nsmith-
Copy link

nsmith- commented Aug 26, 2020

Let's go with the current behavior, namely per-workflow tape destination.

@amaltaro
Copy link
Contributor Author

For the tape locking, we likely want to check whether a rule against tape already exists (be it the same Tape or any other tape endpoint).. If it does, then we should definitely not make another one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants