-
Notifications
You must be signed in to change notification settings - Fork 492
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
fix S3 provider priorities #10004
fix S3 provider priorities #10004
Conversation
src/main/java/edu/harvard/iq/dataverse/dataaccess/S3AccessIO.java
Outdated
Show resolved
Hide resolved
src/main/java/edu/harvard/iq/dataverse/dataaccess/S3AccessIO.java
Outdated
Show resolved
Hide resolved
src/main/java/edu/harvard/iq/dataverse/dataaccess/S3AccessIO.java
Outdated
Show resolved
Hide resolved
Co-authored-by: Oliver Bertuch <poikilotherm@users.noreply.github.com>
It would be nice to review and merge our new S3 tests... ... before reviewing, testing, and merging this PR. |
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 haven't tested this but I don't see anything obviously wrong with it. Approved.
Do you still think this is the case? @pdurbin |
It's not a hard requirement or anything. |
// much but potentially make the failure (in the unlikely case a bucket doesn't | ||
// exist/just disappeared) happen slightly earlier (here versus at the first | ||
// file/metadata access). | ||
|
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.
Good call.
Looking good. |
What this PR does / why we need it: This PR addresses priority issues that existed between the 3 types of credential providers used by S3 stores. Before - the global role-based creds, if set, would override the per store profile or instance credentials. Now they do not, and static creds won't be ignored if/when a default profile exists in the Unix account running Payara.
The PR also includes removal of a redundant check that the bucket exists that would run for every file access.
Which issue(s) this PR closes:
Closes #10003
Special notes for your reviewer: New priority rules are listed in a source comment. As this is a bug fix, it looks to me like the current guides say the right thing about priorities. So I don't see anything to change in the docs (without doing a big rewrite of the whole S3 setup section!). Similarly, since this is a bug fix for a reasonably rare case (role-based access was broken from 4.20 to 5.13, and you have to be using two different S3 providers), I don't know that anything is needed in the release notes.
Suggestions on how to test this:
Regression testing that S3 setup works. Depending on how far you want to go, you could check all the combinations of EC2 role based access is/isn't set, the S3 store has a .profile set or not, (the profile actually exists in the .aws/credentials file or not), and the static microprofile config is/isn't set and verify that setting a profile or static creds wins over the role based method, profile wins over static when both are set, setting nothing results in the default profile in the .aws/credentials file being used, etc. (I have tested at QDR that this fix works in the case where role-based creds exist and we have an S3 store that has to use a non-default profile instead.)
Does this PR introduce a user interface change? If mockups are available, please link/include them here:
Is there a release notes update needed for this change?:
Additional documentation: