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

CORE-163 end support of googleServiceAccount field #125

Merged
merged 1 commit into from
Nov 20, 2024
Merged

Conversation

dvoet
Copy link
Contributor

@dvoet dvoet commented Nov 20, 2024

https://broadworkbench.atlassian.net/browse/CORE-163

The problem in the ticket stems from ECM not properly purging expired fence service account keys. And because they never get removed, ECM never gets a new one. However, ECM never returns the expired key but returns a 404 instead. This triggers a 404 in DrsHub when the googleServiceAccount field is requested which causes failures in rawls when it is validating DRS URIs and workflows when it tries to resolve.

According to https://broadworkbench.atlassian.net/browse/PREQ-28, we no longer need these keys even though they are requested. Both rawls and cromwell should be able to handle their absence because there are already cases where they don't exist (e.g. kids first which is AWS).

I think it is better to discontinue use than to fix ECM's expiration problem.

Copy link

sonarcloud bot commented Nov 20, 2024

@@ -149,11 +149,6 @@ private DrsMetadata fetchObject(
var accessMethod = AccessMethodUtils.getAccessMethod(drsResponse, drsProvider, cloudPlatform);
var accessMethodType = accessMethod.map(AccessMethod::getType).orElse(null);

if (drsProvider.shouldFetchUserServiceAccount(accessMethodType, requestedFields)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can the shouldFetchUserServiceAccount method also be removed from DrsProviderInterface?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

eventually, yes. There is a bunch more to remove too.

@dvoet dvoet merged commit eebadf0 into dev Nov 20, 2024
18 checks passed
@dvoet dvoet deleted the no_more_fence_keys branch November 20, 2024 20:41
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.

3 participants