XJDKC opened a new pull request, #1191:
URL: https://github.com/apache/polaris/pull/1191
<!--
Possible security vulnerabilities: STOP here and contact
[email protected] instead!
Please update the title of the PR with a meaningful message - do not
leave it "empty" or "generated"
Please update this summary field:
The summary should cover these topics, if applicable:
* the motivation for the change
* a description of the status quo, for example the current behavior
* the desired behavior
* etc
PR checklist:
- Do a self-review of your code before opening a pull request
- Make sure that there's good test coverage for the changes included in
this PR
- Run tests locally before pushing a PR (./gradlew check)
- Code should have comments where applicable. Particularly
hard-to-understand
areas deserve good in-line documentation.
- Include changes and enhancements to the documentation (in
site/content/in-dev/unreleased)
- For Work In Progress Pull Requests, please use the Draft PR feature.
Make sure to add the information BELOW this comment.
Everything in this comment will NOT be added to the PR description.
-->
For Storage Config, some properties are automatically provided by the
Polaris service. For example:
* S3
* `externalId`: if users don't provide an external id, polaris will
generate one for users, and it's not alterable
* `userARN`: this user ARN represent the identity of the polaris service
and it's provided by polaris.
* Azure
* `consentUrl`: this url is used to authorize polaris service for
accessing user-provided storage account, which is generated by polaris service
* `multiTanantAppName`: Name of the client application created for
user's storage account. User need to grant this application permission to
obtain an access token on the allowed storage location.
* GCP
* `gcsServiceAccount`: The GCS service account that represents polaris
service.
When creating a catalog, users don’t need to provide these properties,
Polaris sets them automatically and stores them in the storage config. To
retrieve these details, users must send a GET request after the catalog is
created.
For catalog updates, users also don’t need to include these properties in
the `UpdateCatalogRequest`. This request contains a new storage configuration
that does not include the service-provided properties. Previously, we simply
replaced the existing storage configuration (which contained these properties)
with the new one, unintentionally removing them from the catalog entity.
This PR fixes the issue by ensuring that the existing service-provided
properties are inherited when updating the catalog.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
