Replies: 2 comments 2 replies
-
Thanks for this write-up @maseca - so to summarize, you're requesting a conversation with LP.DAAC to enable better S3-to-S3 transfers via:
The first option seems pretty straightforward to me. I'm not quite understanding the latter though - who would generate the token? Does this require a code change, and if so for which software? |
Beta Was this translation helpful? Give feedback.
-
@maseca - given some updates from conversations with the DAACs, it sounds like the IAM role option is going to require EOSDIS review. Thus, we'll have to stick with our nominal approach at least for now. Is the following diagram a correct representation of our nominal approach? If not, please make some modifications to the sequenceDiagram
autonumber
OPERA_PCM-->>CMR: Query for products for a given time range
CMR-->>OPERA_PCM: List of product metadata matches, including S3 URIs
OPERA_PCM-->>CMR: Request for AWS temporary creds
CMR-->>OPERA_PCM: AWS Temporary creds
OPERA_PCM-->>LPCLOUD: Request for downloading S3 URIs, via boto3 library in parallel
LPCLOUD-->>OPERA_PCM: Transfer S3 objects to PCM via boto3 in parallel
|
Beta Was this translation helpful? Give feedback.
-
Currently OPERA PCM uses HTTPS to stream files from LPCLOUD to our S3 buckets. Ideally, we would like to perform direct S3 to S3 file transfer, but this is not currently possible as new credentials are required which would have read access to LPDAAC's buckets and write access to our buckets. The existing Earthdata/CMR interface allows for AWS token generation with read access from LPCLOUD but said token does not provide write access to our buckets. This could potentially be resolved with either a new IAM role or via generating a new specialized token that also includes write access on our buckets. Either solution would require some collaboration with LPDAAC in order to be implemented/configured.
Beta Was this translation helpful? Give feedback.
All reactions