Repository navigation
Compatiblity fix: Always use OpenAPIModelName() functions if they are avalable - #564
Conversation
398aeff to
ad5ab13
Compare
|
Looks like the CI failure is legitimate. Do the golden files need to be updated? |
Ah, yes, I added some comments last minute and they show up as description fields. Fixed. |
7088feb to
87d33b5
Compare
87d33b5 to
62a9a4e
Compare
62a9a4e to
2a895cc
Compare
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Jefftree, jpbetz The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Just came across this PR, as we're facing exactly this issue when upgrading the Kubernetes dependencies of our aggregated API server to 1.35 (github.com/gardener/gardener). I’ve used an
@jpbetz do you have any hints or examples where you got this working? I couldn't find this mixed setup in the sample-apiserver project. |
I discovered in k/k that #563 is not fully backward compatible. Before migrating sample-apiserver to use the new model names approach, it's openapi serving was broken.
The problem was once OpenAPIModelName() functions were generated for the core types, sample-apiserver's openapi had a mix of types with OpenAPIModelName() functions (the core types) and without (the sample-apiserver types).
So to be fully compatible, this PR detects OpenAPIModelName() functions and always uses them when available so that projects that import types from core or other projects continue to work even when not using
+k8s:openapi-model-packagefor their own types.