-
Notifications
You must be signed in to change notification settings - Fork 12
✨ Use OpenAPI schema to handle publishing non-CRD based resources #29
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
Conversation
On-behalf-of: @SAP [email protected]
On-behalf-of: @SAP [email protected]
On-behalf-of: @SAP [email protected]
On-behalf-of: @SAP [email protected]
embik
left a comment
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.
/approve
|
LGTM label has been added. Git tree hash: 0faf363fcf6f5605ad7037bc46c39e6d6b04a5ba
|
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: embik The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Summary
Not all Kube environments use CRDs to create APIs. Some, like Gardener, use apiextensions and aggregation to make new APIs available.
This PR extends the sync agent to be able to handle these. After
trying for 2 dayslearning new things for 2 days I noticed that kcp's crd-puller can already do everything we need, so I just integrated it into our discovery mechanism.I tested this against a Gardener environment and provided a basic integration test using core/v1 (as an instance of any non-CRD API group).
Related issue(s)
Fixes #27
Release Notes