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

Use upstream 1.7.1 rest-catalog-open-api.yaml instead. #936

Merged

Conversation

HonahX
Copy link
Contributor

@HonahX HonahX commented Feb 4, 2025

Depends on #935

This is a second follow-up of #906. This PR makes the rest-catalog-open-api.yaml identical to the upstream released version (1.7.1)

@@ -242,8 +236,6 @@ paths:
$ref: '#/components/responses/OAuthErrorResponse'
5XX:
$ref: '#/components/responses/OAuthErrorResponse'
security:
- BearerAuth: []
Copy link
Contributor Author

Choose a reason for hiding this comment

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

It seems in Polaris the /v1/oauth/tokens has this additional security scheme override. This change is included in the original commit of Polaris.

To ensure this PR does not change anything unexpectedly, I extracted this one to polaris-catalog-apis/oauth-tokens-api.yaml. We will likely remove or update this soon anyway according to: #12

Copy link
Contributor

Choose a reason for hiding this comment

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

Now the /v1/oauth/tokens endpoint is defined in twp files, right? What controls which of the definitions is the one used in runtime?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi @dimas-b, thanks for reviewing. Currently we have polaris-catalog-service.yaml as the root yaml for building catalog api service

/v1/oauth/tokens:
$ref: './rest-catalog-open-api.yaml#/paths/~1v1~1oauth~1tokens'

It uses $ref to control the one used in the runtime. This PR updates the $ref so that it will point to the oauth-tokens-api.yaml

@HonahX
Copy link
Contributor Author

HonahX commented Feb 7, 2025

This PR is ready for review since #953 and #935 are in. @jackye1995 @dimas-b @adutra Could you please take another look at this when you have a chance? Thanks!

LICENSE Outdated
@@ -215,7 +215,10 @@ License: https://www.apache.org/licenses/LICENSE-2.0

This product includes code from Apache Iceberg.

* spec/rest-catalog-open-api.yaml
* spec/iceberg-rest-catalog-open-api.yaml
* spec/polaris-catalog-service.yaml
Copy link
Contributor

Choose a reason for hiding this comment

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

no, this is Polaris' own file, it is NOT from Apache Iceberg, 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.

Thanks for all the great catch here! It seems I have misunderstood the intended use of the CODE_COPIED_TO_POLARIS flag and the corresponding licensing requirements. My current understanding is that this flag should only be applied to files where all content is copied from another project. Could you please confirm if that’s correct?

Based on this understanding, here’s the current status:

  • iceberg-rest-catalog-open-api.yaml: identical to upstream released spec. Need CODE_COPIED_TO_POLARIS
  • polaris-catalog-apis/oauth-tokens-api.yaml: everything is copied from IRC spec's token endpoint definition. Need CODE_COPIED_TO_POLARIS
  • polaris-catalog-service.yaml - only the server and security definition are copied from IRC spec, while the rest are not. Do Not Need CODE_COPIED_TO_POLARIS
  • bundled-polaris-catalog-service.yaml - generated yaml that contains both IRC spec and polaris defined ones. Do Not Need CODE_COPIED_TO_POLARIS

Copy link
Contributor

Choose a reason for hiding this comment

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

My current understanding is that this flag should only be applied to files where all content is copied from another project. Could you please confirm if that’s correct?

That's my understanding too :)

Copy link
Contributor

Choose a reason for hiding this comment

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

polaris-catalog-service.yaml - only the server and security definition are copied from IRC spec, while the rest are not. Do Not Need CODE_COPIED_TO_POLARIS

I agree. Plus we have a general notice with Iceberg attribution. I think that's fine.

@jbonofre WDYT?

Make rest-catalog-open-api.yaml identical to 1.7.1 released version of rest-catalog-open-api.yaml

Commit added new files

add not implemented endpoint as comments

Add code copied to Polaris

make oauth-tokens-api standalone

fix COPIED code issue

rename iceberg upstream copied spec

add upstream version note

Fix lint

Fix LICENSE

Remove incorrect LICENSE mention

Fix style
@HonahX HonahX force-pushed the honahx_use_upstream_released_iceberg_spec_instead branch from c1be23b to d98d4c5 Compare February 26, 2025 08:03
@dimas-b
Copy link
Contributor

dimas-b commented Feb 26, 2025

@snazy @RussellSpitzer @jackye1995 @collado-mike : This PR LGTM, but since it's an API change - please also have a look :)

---
paths:
# The /v1/oauth/tokens endpoint is sourced from iceberg-rest-catalog-open-api.yaml
/v1/oauth/tokens:
Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry to miss the context, why do we copy this from iceberg-rest-catalog-open-api.yaml?

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 original related discussion is here: #906 (comment), #936 (comment).

Since the token endpoint is deprecated and will soon be removed from the upstream IRC spec, we want to extract it from the spec. This allows us to control its removal timeline, update the endpoint as needed, or continue supporting it temporarily for compatibility. Issue #12.

# under the License.
#

# CODE_COPIED_TO_POLARIS
Copy link
Contributor

@flyrain flyrain Feb 26, 2025

Choose a reason for hiding this comment

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

Should we also give a version like this? Given that future Iceberg rest spec may not even have it.

# CODE_COPIED_TO_POLARIS

# From Apache Iceberg Version: 1.7.1

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree that in the current form CODE_COPIED_TO_POLARIS is too vague.

I'd argue for dependency-specific labels, e.g. CODE_COPIED_FROM_ICEBERG: 1.7.1

Certainly not for this PR, but for follow-up change.. if people are in agreement :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the suggestions! I've added the comment but I will leave this thread open to continue the discussion on dependency-specific labels : )

@HonahX
Copy link
Contributor Author

HonahX commented Feb 26, 2025

Thanks everyone for reviewing! I've updated the PR. I saw currently Merging is blocked because

This branch must not contain merge commits

but I've cleaned up/rebased commits. Does it mean I have to close and re-open this one or open a new PR?

@flyrain flyrain enabled auto-merge (squash) February 26, 2025 18:46
@flyrain flyrain merged commit 4f7cf97 into apache:main Feb 26, 2025
5 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.

5 participants