-
Notifications
You must be signed in to change notification settings - Fork 272
Add pathStyleAccess
to AwsStorageConfigInfo
#2012
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
base: main
Are you sure you want to change the base?
Conversation
polaris-core/src/main/java/org/apache/polaris/core/storage/aws/AwsStorageConfigurationInfo.java
Outdated
Show resolved
Hide resolved
} | ||
|
||
public AwsStorageConfigurationInfo( | ||
@Nonnull StorageType storageType, | ||
@Nonnull List<String> allowedLocations, | ||
@Nonnull String roleARN, | ||
@Nullable String region) { | ||
this(storageType, allowedLocations, roleARN, null, region, null, null); | ||
this(storageType, allowedLocations, roleARN, null, region, null, null, false); |
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.
We could use the default here, or just leave it null to leverage the default used in orElse
. Better not to proliferate the constants around like this.
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.
changed to use PATH_STYLE_ACCESS_DEFAULT
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.
Now that we have a default at the API level, is this actually nullable?
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 had to remove the API default.
type: boolean | ||
description: >- | ||
Whether S3 requests to files in this catalog should use 'path-style addressing for buckets'. | ||
Default: false. |
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 believe OpenAPI actually supports default values, maybe we could just use that?
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.
Added default: false
, changed example to true
.
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.
Actually I had to roll this back. Using Open API defaults breaks strict backward compatibility because is causes the attribute with a default
value to be always returned to clients (even when not in use) - CI caught this.
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.
What exactly was the failure in CI? The client would fail to parse a response because it didn't recognize the property?
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.
CatalogSerializationTest
detected a change in the JSON text (when the new properties are not set)
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.
actually, never mind, I'll expand this PR a bit :)
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. PTAL.
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.
Thanks, the changes look better, but my concern about the default remains
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.
TBH, I do not understand the whole discussion about "is this a breaking change".
As Polaris is primarily an Iceberg REST catalog, we have to let JSON parsing ignore unknown properties, because that is a requirement from Iceberg REST. There is also exactly one JSON parser (ObjectMapper
) for all endpoints. The situation is unfortunate but a consequence of generating the OpenAPI code. Jackson itself allows much more fine grained control over how types are (de)serialized and allows back/forwards compatibility targeting functionality like @JsonView
- but that's not usable w/ the code generation approach.
So fact is that unknown properties in JSON objects in any Polaris REST payload have to be ignored. As that fact leaks to all Polaris APIs, it also leaks to clients. This means, that a new property is not a breaking change. If clients fail on unknown properties, it's a bug in those client.
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.
@eric-maynard : the new test shows AWS config data roundtrips via API with and without (defaults) values for the new properties.
If the new properties are not set, clients will not see them in JSON outputs of the REST API endpoints. So, this change does not break existing installations and old clients as long as Polaris users do not use the new properties. If users do reconfigure catalogs to use the new properties, it's the user's responsibility to also update clients to be compatible with the catalog JSON configuration (e.g. use new CLI).
polaris-core/src/main/java/org/apache/polaris/core/storage/aws/AwsStorageConfigurationInfo.java
Outdated
Show resolved
Hide resolved
polaris-core/src/main/java/org/apache/polaris/core/storage/aws/AwsStorageConfigurationInfo.java
Outdated
Show resolved
Hide resolved
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.
LGTM !
I had to remove one commit (discussed in the API yaml comment thread). PTAL. |
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.
Let's clarify if this is a breaking change (does it need to target 2.0? Go into API version 2?) and plan accordingly before merging.
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.
LGTM
This change allows configuring the "path-style" access mode in S3 clients (both in Polaris Servers and Iceberg REST Catalog API clients). This change is applicable both to AWS storage and to non-AWS S3-compatible storage (apache#1530). The Management API change is backward-compatible.
@eric-maynard : I believe I addressed your backward-compatibility concern in the latest push. Could you review again? |
This change allows configuring the "path-style" access mode in S3 clients (both in Polaris Servers and Iceberg REST Catalog API clients).
This change is applicable both to AWS storage and to non-AWS S3-compatible storage (#1530).
The Management API change is backward-compatible.
Includes a fix to AWS config object round-trip via generated API classes.
Dev ML discussion: https://lists.apache.org/thread/oxy2yd4mbq06zr4z57lfptgy95c3lyhb