-
Notifications
You must be signed in to change notification settings - Fork 382
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
Conversation
45db206
to
1582bd3
Compare
@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; |
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.
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); |
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.
Can we use a more meaningful exception instead of RuntimeException
?
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.
ok
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.
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."); |
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.
"There is no credential..."
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.
updated
} | ||
|
||
@SuppressWarnings("deprecation") | ||
private Map<String, String> normalizeCredentialProperties(Map<String, String> properties) { |
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 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.
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.
ok
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.
updated with adjustCredentialPropertiesForCompatibility
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; | ||
} |
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 assume these two methods should add @Override
annotation, right?
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.
no, the method is different for requestCredential
parameter
* | ||
* @return true if the request is for credential vending, false otherwise. | ||
*/ | ||
public boolean isRequestCredentialVending() { |
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.
Can we rename to requestCredentialVending
?
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.
done
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 have read the code, found no issues, and learned from it.
Seems like there's some conflicts need to be resolved. |
ae4a7c4
to
ee2e233
Compare
updated |
.doc("Credential providers, separated by comma.") | ||
.version(ConfigConstants.VERSION_0_8_0) | ||
.stringConf() | ||
.create(); |
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.
Can you use toSequence()
for this configuration.
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.
updated
} | ||
|
||
@SuppressWarnings("deprecation") | ||
private Map<String, String> adjustCredentialPropertiesForCompatibility( |
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.
The name is too long, I think we can use checkForCompatibility
.
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.
updated
MapUtils.getFilteredMap( | ||
config.getIcebergCatalogProperties(), | ||
key -> catalogPropertiesToClientKeys.contains(key)); | ||
// To compatibility with old version |
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.
"To be compatible with..."
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.
updated
new ConfigBuilder(CredentialConstants.CREDENTIAL_PROVIDERS) | ||
.doc("Credential providers, separated by comma.") | ||
.version(ConfigConstants.VERSION_0_8_0) | ||
.stringConf() | ||
.create(); | ||
.toSequence() | ||
.createWithDefault(Collections.emptyList()); |
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.
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?
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.
The config entry defined here is not used to get providers, updated the code, please review again
What changes were proposed in this pull request?
CatalogCredentialManager
to manage the credentials in Iceberg catalog.CatalogWrapperForREST
to manage some REST specific operations like credential vending.catalog-provider-type
, usecatalog-providers
instead.Why are the changes needed?
Fix: #6024
Does this PR introduce any user-facing change?
yes, depracate
catalog-provider-type
, usecatalog-providers
, do some compatibility work.How was this patch tested?
run with s3 token