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

Update managing-files-with-ganga.md #258

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

mesmith75
Copy link
Contributor

@mesmith75 mesmith75 commented Feb 11, 2021

I am not sure replicating all your outputdata to CERN is right. You should access files directly with the PFNs.

second-analysis-steps/managing-files-with-ganga.md Outdated Show resolved Hide resolved
```python
j.backend.getOutputDataAccessURLs()
```
which will return a list of the PFNs for any DiracFile object created in your job output.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I don't think this is a big issue but) this duplicates the other lesson from first-analysis-steps https://lhcb.github.io/starterkit-lessons/first-analysis-steps/ganga-data.html
Maybe some cross-references could be useful.

@alexpearce
Copy link
Member

If I remember rightly (and I probably don't because it was a looong time ago), we figured that CERN replicas were easiest for the analyst because the access pattern was simple. Generating a Grid certificate was annoying in certain environments (e.g. a Docker container, or a CI).

But I remember some work on this area a while ago, to try to make things easier. @cburr you looked in to simpler certificate generation right?

@ryuwd
Copy link
Contributor

ryuwd commented Feb 12, 2021

If I remember rightly (and I probably don't because it was a looong time ago), we figured that CERN replicas were easiest for the analyst because the access pattern was simple. Generating a Grid certificate was annoying in certain environments (e.g. a Docker container, or a CI).

If I could get a valid grid certificate in my CI job environment which grants read-only access to my files, I'd gladly use that over replicating to EOS and using kerberos to authenticate. Currently though I'm not so sure whether it's a good idea to paste an unencrypted grid certificate into a protected/masked GitLab CI variable.

@cburr
Copy link

cburr commented Feb 12, 2021

If I remember rightly (and I probably don't because it was a looong time ago), we figured that CERN replicas were easiest for the analyst because the access pattern was simple. Generating a Grid certificate was annoying in certain environments (e.g. a Docker container, or a CI).

But I remember some work on this area a while ago, to try to make things easier. @cburr you looked in to simpler certificate generation right?

You have the wrong Chris Burr. You are looking for @chrisburr

@alexpearce
Copy link
Member

You have the wrong Chris Burr.

Oops, very sorry! 🙊 (cburr is his username in our internal system.)

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

Successfully merging this pull request may close these issues.

None yet

5 participants