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

Use Rusoto client to allow connecting to non-AWS S3 instances #1

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

Conversation

bossmc
Copy link

@bossmc bossmc commented Sep 16, 2019

Move off the inline S3 client implementation to using rusoto. Mainly to support authentication above version 2 (e.g. for minio integration). The configuration API is unchanged so this should be a non-breaking change.

@bossmc bossmc changed the base branch from master to 0.2.8-workaround September 16, 2019 15:18
@bossmc bossmc changed the base branch from 0.2.8-workaround to master September 16, 2019 15:19
@bossmc
Copy link
Author

bossmc commented Sep 20, 2019

@richardwhiuk can you please give this a once over before I upstream it? Thanks!

Copy link

@richardwhiuk richardwhiuk left a comment

Choose a reason for hiding this comment

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

Looks fine - just a couple of concerns

// or make those builders put their credentials in ~/.aws/credentials
ProfileProvider::with_configuration(home.join(".boto"), "Credentials"),
];
let provider = AutoRefreshingProvider::new(ChainProvider::with_profile_providers(profile_providers));

Choose a reason for hiding this comment

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

It's not obvious to me why getting rid of the above code is OK.

src/cache/s3.rs Outdated Show resolved Hide resolved
chmanchester and others added 9 commits September 23, 2019 10:31
Previously we would lock to prevent multiple toolchain creations
at once, but the lock was acquired after checking for the presence
of the toolchain in question and determining it wasn't present.
In case multiple attempts were made to create a toolchain asynchronously
the attempts would serialize on this lock but still redundantly re-create
toolchains.
…cheduler. Fixes mozilla#513.

We've found some situations where a server will retain jobs waiting for a
client to request they be run. In practice this means that a client that's
having trouble connecting to a server (due to mozilla#516 or another issue) can
take that server offline by consuming its capacity, which will be unavailable
indefinitely as far as the scheduler is concerned. This commit takes the step
of tracking jobs that have been assigned but have not yet been started.
When receiving a heartbeat from a server, the scheduler will check the unclaimed
jobs assigned to that server and de-allocate any that have been waiting to start
for too long. The threshold for now is 1 minute for jobs that start in the
"Ready" state and 5 minutes for jobs in the "Pending" state in case toolchain
packaging and transfer overrruns the smaller threshold.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants