-
Notifications
You must be signed in to change notification settings - Fork 559
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
New S3 backend #1086
New S3 backend #1086
Conversation
This doesn't address #869 (comment) AFAICT. |
Oh oops my bad, I completely missed that. I'll look into it! |
Codecov Report
@@ Coverage Diff @@
## main #1086 +/- ##
==========================================
+ Coverage 55.72% 59.47% +3.75%
==========================================
Files 47 45 -2
Lines 11809 11774 -35
Branches 2099 2106 +7
==========================================
+ Hits 6580 7003 +423
+ Misses 3915 3404 -511
- Partials 1314 1367 +53
Continue to review full report at Codecov.
|
@alessandrod do you have an update? thanks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, would you mind rebasing this off main
?
Sorry for the delay in reviewing this so far, but I'll dig into it if you're able to update it :)
From the AWS sdk github:
Since you wanted to not bump the MSRV for the upcoming Release, I guess this PR will have to wait until after |
Hmm, I suppose you're right - I assumed that there's be an older version of the AWS SDK that would be compatible with Rust 1.48, but looks like that's not the case: the oldest published version I could find ( |
Rebased, sorry for the delay 😊 |
Looks like we have some CI failures:
I'm guessing that this will be blocked on #1121 anyways, which is itself blocked on Milestone 3. |
Yep, it looks like |
Just wanted to say thanks @alessandrod for this PR. The |
I have resolved conflicts and made a PR to the author's branch. The struggle for a new S3 backend will not be abandoned :P |
The backend uses the official AWS SDK for Rust. It supports SCCACHE_BUCKET, SCCACHE_REGION and SCCACHE_ENDPOINT like the old backend. It does not support SCCACHE_S3_USE_SSL. The backend adds support for a new SCCACHE_S3_NO_CREDENTIALS key that can be set to implement a readonly cache that does not require AWS credentials at all. This is useful to speed up public pull request builds that typically can't access AWS credentials for security reasons.
I've rebased this, sorry for the delay! Someone kick tests pls. |
Is there a particular reason why the aws dependencies are on version 0.3? I tested with 0.12 and it works fine on my machine. |
I started using this PR instead of the one in the main. Needed to compile it so here is the link and the yaml anchor i am using for gitlab. I hope all of you will find it useful: .with-sccache-new-s3:
before_script:
# stop the sccache server just in case so it can pick up the env vars, it will start again
- sccache --stop-server
- wget -q https://ipfs.anagolay.network/ipfs/bafybeidovvudc7jcc3ulkz2t4pew4fa5ylnzoaf67b67kc3yderuavx3hy -O /usr/local/bin/sccache
- chmod +x /usr/local/bin/sccache
- sccache --version
- sccache --show-stats |
RegionProviderChain::first_try(region.map(|r| Region::new(r.to_owned()))) | ||
.or_default_provider(); | ||
|
||
let shared_config = aws_config::from_env().region(region_provider).load().await; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should not pull in env vars here, but rather use the arguments and the arguments alone. Everything else should be part of the config file. There are two reasons, mainly maintainability, reproducibility of tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'd like to chip in. why not pull envs in? the whole AWS compatible cli works the same way. and passing the AWS_ACCESS_SECRET_KEY as an argument sounds terribly risky
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not saying to remove the functionality, but with clap there is an easier way to provide the information in one place. If env is pulled in from allover the place, that's not maintainable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The clap approach of centrally pulling in AWS credentials from related arguments would lead to less maintainability in this case.
The aws_config crate pulls credentials from different sources with their corresponding precedences.
If the access key id and secret access key method-usage is hard-coded, authentication options such as a CLI credentials file, IAM roles for ECS tasks and IAM roles for service accounts become unusable right from the get-go.
Also, future CLI authentication method integrations, e.g., IAM roles anywhere, would have to be added manually instead of just updating the aws_config crate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, there is one nit that must be resolved, otherwise looks good to me. Going to test on a rather old minio cluster before merging. Could you also bump the dependencies to their latest versions?
Does this require openssl under the hood or is there an option to use rustls instead, if so that should be the default.
Thank you for your work and endurance on this!
bump! This is so close to being merged. @alessandrod, can you bump the dependencies as per the request in the previous comment above? |
Opened a rebased version of this PR in #1403, hopefully it will speed things up. |
merged here: |
thanks for the work! |
The backend uses the official AWS SDK for Rust.
Supersedes #869 (including readonly mode with
SCCACHE_S3_NO_CREDENTIALS
), and fixes #632 #281 and #217The new backend is largely compatible with the old one in terms of conf settings, except that it does not support
SCCACHE_S3_USE_SSL=0
. SSL is always required at the moment.