/sig api-machinery

/good-first-issue

@dims:
This request has been marked as suitable for new contributors.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

/assign

/cc @roycaihw
assigning to not lose visibility, let's see if someone picks it up

Hi!
Did I understand the bug correctly?
For example 'NodeProxyOptions' is mentioned in swagger.json as "kind" but their rust generator complains, because 'NodeProxyOptions' is not mentioned in the definitions-section of swagger.json. Correct?

I have not yet found out how the OpenAPI generator code (vendor/k8s.io/kube-openapi/pkg/generators/ ?)
) decides which definitions go into swagger.json and which ones do not.

Pointers in the right direction are highly appreciated.

Trying to break down https://github.com/Arnavion/k8s-openapi/blob/master/k8s-openapi-codegen/src/fixups/upstream_bugs.rs

connect_options_gvk:

Path operation annotated with a "x-kubernetes-group-version-kind" that references a type that doesn't exist in the schema. E.g.

curl https://raw.githubusercontent.com/kubernetes/kubernetes/v1.19.2/api/openapi-spec/swagger.json | jq '.paths["/api/v1/nodes/{name}/proxy"]["delete"]'

kube-apiserver installs x-kubernetes-group-version-kind here. @Git-Jiro You can find the generated schema for NodeProxyOptions by running:

$ make gen_openapi
$ grep "NodeProxyOptions" pkg/generated/openapi/zz_generated.openapi.go
		"k8s.io/api/core/v1.NodeProxyOptions":                                                                         schema_k8sio_api_core_v1_NodeProxyOptions(ref),
func schema_k8sio_api_core_v1_NodeProxyOptions(ref common.ReferenceCallback) common.OpenAPIDefinition {
				Description: "NodeProxyOptions is the query options to a Node's proxy call.",

kube-openapi won't include the schema in the definitions if it's not used (not consumed/produced by any operation, nor referred by other used definition).

Possible ways to fix:

1. Including the schema in the definition. Does any of those operations (e.g. DELETE "/api/v1/nodes/{name}/proxy") consumes/produces NodeProxyOptions? If so, we should fix the route installer to reflect that.
2. Changing x-kubernetes-group-version-kind to the parent kind (what Rust client does). I forgot what x-kubernetes-group-version-kind are used for: https://github.com/kubernetes/kubernetes/tree/v1.19.2/api/openapi-spec#vendor-extensions. Perhaps something like NodeProxyOptions (which is a (query?) parameter for a non-persisting subresource) doesn't make sense here. @dims Do you remember?

Hi!
The nice thing about the Rust issue is that they also referenced the PR that introduced the change they try to fix: #66807

Maybe this helps in deciding how to properly address this issue?

Hi!
After reading this part of the documentation: https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls, my current theory is that PR #66807 contained changes that were not necessary to make PR #66807 work, but those changes broke the API spec.
Could this be the case here?

Does any of those operations (e.g. DELETE "/api/v1/nodes/{name}/proxy") consumes/produces NodeProxyOptions?

Reading getRequestOptions, these proxy options are query parameters only (not body parameters), so they are not consumed. It's unlikely for them to be produced as well.

they also referenced the PR that introduced the change they try to fix: #66807

@Git-Jiro Thanks. I didn't notice the linked PRs. Reading #66807 (comment), I think the change was necessary for admission webhooks, but unintentionally changed the spec. The webhook controller needs the proxy option kinds, while the spec should still use the parent kinds.

This issue contains several bugs. Please feel free to open a separate issue to summarize&track this specific bug.