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

New S3 backend #1086

Closed
wants to merge 1 commit into from
Closed

New S3 backend #1086

wants to merge 1 commit into from

Conversation

alessandrod
Copy link
Contributor

The backend uses the official AWS SDK for Rust.

Supersedes #869 (including readonly mode with SCCACHE_S3_NO_CREDENTIALS), and fixes #632 #281 and #217

The 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.

@glandium
Copy link
Collaborator

glandium commented Jan 4, 2022

This doesn't address #869 (comment) AFAICT.

@alessandrod
Copy link
Contributor Author

This doesn't address #869 (comment) AFAICT.

Oh oops my bad, I completely missed that. I'll look into it!

@codecov-commenter
Copy link

codecov-commenter commented Jan 14, 2022

Codecov Report

Merging #1086 (788e4db) into main (586c308) will increase coverage by 3.75%.
The diff coverage is 3.84%.

Impacted file tree graph

@@            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     
Impacted Files Coverage Δ
src/cache/cache.rs 35.00% <0.00%> (-0.39%) ⬇️
src/cache/s3.rs 0.00% <0.00%> (ø)
src/lib.rs 44.44% <ø> (ø)
src/config.rs 57.99% <27.27%> (+1.91%) ⬆️
src/dist/pkg.rs 29.54% <0.00%> (-26.02%) ⬇️
tests/sccache_cargo.rs 84.05% <0.00%> (-15.95%) ⬇️
src/compiler/c.rs 64.13% <0.00%> (-10.05%) ⬇️
src/dist/cache.rs 53.17% <0.00%> (-0.43%) ⬇️
src/compiler/msvc.rs 65.46% <0.00%> (+0.15%) ⬆️
... and 15 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 586c308...788e4db. Read the comment docs.

@sylvestre
Copy link
Collaborator

@alessandrod do you have an update? thanks

Copy link
Contributor

@mitchhentges mitchhentges left a 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 :)

@jschwe
Copy link
Contributor

jschwe commented Feb 15, 2022

From the AWS sdk github:

The SDK currently requires a minimum of Rust 1.54, and is not guaranteed to build on compiler versions earlier than that. While we are still in alpha, we will be keeping the minimum compiler version two releases behind the latest stable release where possible (so if the latest stable were 1.55, we would be on 1.53). However, we are not making any guarantees around this at present. Increases in minimum required Rust version will be called out in the Release Notes for new releases of the SDK.

Since you wanted to not bump the MSRV for the upcoming Release, I guess this PR will have to wait until after 0.2.16 anyway?

@mitchhentges
Copy link
Contributor

Since you wanted to not bump the MSRV for the upcoming Release, I guess this PR will have to wait until after 0.2.16 anyway?

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 (0.2.0) still required at least Rust 1.54.

@alessandrod
Copy link
Contributor Author

Rebased, sorry for the delay 😊

@alessandrod alessandrod requested a review from mitchhentges March 1, 2022 09:31
@mitchhentges
Copy link
Contributor

Looks like we have some CI failures:

error: failed to parse manifest at `/home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/time-0.3.7/Cargo.toml`

Caused by:
  feature `resolver` is required

  this Cargo does not support nightly features, but if you
  switch to nightly channel you can add
  `cargo-features = ["resolver"]` to enable this feature

I'm guessing that this will be blocked on #1121 anyways, which is itself blocked on Milestone 3.

@alessandrod
Copy link
Contributor Author

Yep, it looks like resolver was added in cargo 1.51

@jrcichra
Copy link

Just wanted to say thanks @alessandrod for this PR. The main branch wasn't working with my Minio cluster (getting 404 Not Found ) errors. Your PR solved those issues and works great for me 💯

@mitchhentges mitchhentges removed their request for review May 5, 2022 13:33
@GZGavinZhao
Copy link
Contributor

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.
@alessandrod
Copy link
Contributor Author

I've rebased this, sorry for the delay! Someone kick tests pls.

@GZGavinZhao
Copy link
Contributor

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.

@woss
Copy link

woss commented Jul 22, 2022

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;
Copy link
Collaborator

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.

Copy link

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

Copy link
Collaborator

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.

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.

Copy link
Collaborator

@drahnr drahnr left a 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!

@ajschmidt8
Copy link
Contributor

bump! This is so close to being merged.

@alessandrod, can you bump the dependencies as per the request in the previous comment above?

@messense
Copy link
Contributor

Opened a rebased version of this PR in #1403, hopefully it will speed things up.

@sylvestre
Copy link
Collaborator

merged here:
#1403

@sylvestre sylvestre closed this Nov 14, 2022
@sylvestre
Copy link
Collaborator

thanks for the work!

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.

403 when trying to write to S3