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

[#6024] feat(iceberg): refactor Iceberg credential code to reuse credential component in Gravitino server #6021

Merged
merged 7 commits into from
Dec 30, 2024

Conversation

FANNG1
Copy link
Contributor

@FANNG1 FANNG1 commented Dec 27, 2024

What changes were proposed in this pull request?

  1. reuse CatalogCredentialManager to manage the credentials in Iceberg catalog.
  2. use CatalogWrapperForREST to manage some REST specific operations like credential vending.
  3. depracate catalog-provider-type , use catalog-providers instead.

Why are the changes needed?

Fix: #6024

Does this PR introduce any user-facing change?

yes, depracate catalog-provider-type , use catalog-providers, do some compatibility work.

How was this patch tested?

run with s3 token

@FANNG1 FANNG1 force-pushed the iceberg_credential branch 2 times, most recently from 45db206 to 1582bd3 Compare December 27, 2024 06:29
@FANNG1 FANNG1 changed the title [SIP] refactor Iceberg credential [#6024] feat(iceberg): refactor Iceberg credential code to reuse credential component in Gravitino server Dec 27, 2024
@FANNG1
Copy link
Contributor Author

FANNG1 commented Dec 27, 2024

@jerryshao @orenccl @theoryxu please help to review when you have time, thanks

this.httpServletRequest = httpRequest;
this.remoteHostName = httpRequest.getRemoteHost();
this.httpHeaders = IcebergRestUtils.getHttpHeaders(httpRequest);
this.catalogName = catalogName;
this.userName = PrincipalUtils.getCurrentUserName();
this.requestCredentialVending = requestCredentialVending;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Trying to get credential information from httpHeaders, test jersey test fails for couldn't get real HTTP headers, try find some solution

} else if (credentialProviders.size() > 1) {
throw new RuntimeException("There are multiple credential providers for the catalog.");
}
return getCredential(credentialProviders.keySet().iterator().next(), context);
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we use a more meaningful exception instead of RuntimeException?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated

// Get credential with only one credential provider.
public Credential getCredential(CredentialContext context) {
if (credentialProviders.size() == 0) {
throw new RuntimeException("There are not any credential provider for the catalog.");
Copy link
Contributor

Choose a reason for hiding this comment

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

"There is no credential..."

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated

}

@SuppressWarnings("deprecation")
private Map<String, String> normalizeCredentialProperties(Map<String, String> properties) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think the name "normalize" cannot fully describe the meaning of this method, this method doesn't normalize anything, it just check and keep the compatibility of the deprecated configs. It would be better to have a new name.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated with adjustCredentialPropertiesForCompatibility

Comment on lines +72 to +89
public LoadTableResponse createTable(
Namespace namespace, CreateTableRequest request, boolean requestCredential) {
LoadTableResponse loadTableResponse = super.createTable(namespace, request);
if (requestCredential) {
return injectCredentialConfig(
TableIdentifier.of(namespace, request.name()), loadTableResponse);
}
return loadTableResponse;
}

public LoadTableResponse loadTable(TableIdentifier identifier, boolean requestCredential) {
LoadTableResponse loadTableResponse = super.loadTable(identifier);
if (requestCredential) {
return injectCredentialConfig(identifier, loadTableResponse);
}
return loadTableResponse;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I assume these two methods should add @Override annotation, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

no, the method is different for requestCredential parameter

*
* @return true if the request is for credential vending, false otherwise.
*/
public boolean isRequestCredentialVending() {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we rename to requestCredentialVending?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

Copy link
Collaborator

@orenccl orenccl left a comment

Choose a reason for hiding this comment

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

I have read the code, found no issues, and learned from it.

@jerryshao
Copy link
Contributor

Seems like there's some conflicts need to be resolved.

@FANNG1 FANNG1 force-pushed the iceberg_credential branch from ae4a7c4 to ee2e233 Compare December 28, 2024 13:52
@FANNG1
Copy link
Contributor Author

FANNG1 commented Dec 28, 2024

Seems like there's some conflicts need to be resolved.

updated

.doc("Credential providers, separated by comma.")
.version(ConfigConstants.VERSION_0_8_0)
.stringConf()
.create();
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you use toSequence() for this configuration.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated

}

@SuppressWarnings("deprecation")
private Map<String, String> adjustCredentialPropertiesForCompatibility(
Copy link
Contributor

Choose a reason for hiding this comment

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

The name is too long, I think we can use checkForCompatibility.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated

MapUtils.getFilteredMap(
config.getIcebergCatalogProperties(),
key -> catalogPropertiesToClientKeys.contains(key));
// To compatibility with old version
Copy link
Contributor

Choose a reason for hiding this comment

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

"To be compatible with..."

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated

new ConfigBuilder(CredentialConstants.CREDENTIAL_PROVIDERS)
.doc("Credential providers, separated by comma.")
.version(ConfigConstants.VERSION_0_8_0)
.stringConf()
.create();
.toSequence()
.createWithDefault(Collections.emptyList());
Copy link
Contributor

Choose a reason for hiding this comment

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

It's weird that changes to List here alone is enough? Do you need to change to other places that uses this variable, how can they pass the type check?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The config entry defined here is not used to get providers, updated the code, please review again

@jerryshao jerryshao merged commit 528d0ea into apache:main Dec 30, 2024
26 checks passed
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.

[Improvement] Refactor Iceberg REST server credential code
3 participants