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

CustomObjectsApi.deleteCollectionNamespacedCustomObject does not support several OpenAPI query parameters #1778

Open
rotty3000 opened this issue Jul 9, 2024 · 7 comments
Assignees
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines.

Comments

@rotty3000
Copy link

Describe the bug
The OpenAPI specification generated for CRDs declares verb delete on the path /apis/{group}/{version}/namespaces/{namespace}/{plural}.

However, the CustomObjectsApi.deleteCollectionNamespacedCustomObject does not support several of those query parameters; allowWatchBookmarks, continue, fieldSelector, labelSelector, limit, resourceVersion, resourceVersionMatch, timeoutSeconds & watch

** Client Version **
0.20.0 (although the same is still true in HEAD of the master branch)

** Server Version **
e.g. 1.19.1

To Reproduce
Use the API!

Expected behavior
The missing parameters could be classified into groups:

  • filtering: fieldSelector, labelSelector, limit, resourceVersion, resourceVersionMatch
  • watching: allowWatchBookmarks, continue, timeoutSeconds, watch

Supporting the filtering parameters would be the minimal fix that I would expect.

@brendandburns
Copy link
Contributor

That code is generated from the spec here:

https://github.com/kubernetes-client/gen/blob/master/openapi/custom_objects_spec.json

If you update that spec, we can regenerate the code and those fields should be added.

@rotty3000
Copy link
Author

Did you notice that for some reason the method in question didn't receive the labelSelector parameter? https://github.com/kubernetes-client/gen/blob/2658f902d35aed7fcf1823b442eb87b44d812ac1/openapi/custom_objects_spec.json#L513

Or maybe was this added since the last time the JavaScript client was last built?

@rotty3000
Copy link
Author

:(

I guess I don't understand why client API doesn't match up with the OpenAPI provided by the API server:

]$ k version
Client Version: v1.30.2
Server Version: v1.22.13+k3s1
]$ kubectl apply -f crds/
customresourcedefinition.apiextensions.k8s.io/liferayextensionprovisions.k8s.liferay.com created
]$ k proxy --port=8080&
]$ curl -s http://localhost:8080/openapi/v2 | jq  '.paths | to_entries[] | select(.key == "/apis/k8s.liferay.com/v1alpha1/namespaces/{namespace}/liferayextensionprovisions") | .value.delete.parameters'

result (descriptions redacted for brevity):

[
  {
    "uniqueItems": true,
    "type": "boolean",
    "description": "...",
    "name": "allowWatchBookmarks",
    "in": "query"
  },
  {
    "uniqueItems": true,
    "type": "string",
    "description": "...",
    "name": "continue",
    "in": "query"
  },
  {
    "uniqueItems": true,
    "type": "string",
    "description": "...",
    "name": "fieldSelector",
    "in": "query"
  },
  {
    "uniqueItems": true,
    "type": "string",
    "description": "...",
    "name": "labelSelector",
    "in": "query"
  },
  {
    "uniqueItems": true,
    "type": "integer",
    "description": "...",
    "name": "limit",
    "in": "query"
  },
  {
    "uniqueItems": true,
    "type": "string",
    "description": "...",
    "name": "resourceVersion",
    "in": "query"
  },
  {
    "uniqueItems": true,
    "type": "string",
    "description": "...",
    "name": "resourceVersionMatch",
    "in": "query"
  },
  {
    "uniqueItems": true,
    "type": "integer",
    "description": "...",
    "name": "timeoutSeconds",
    "in": "query"
  },
  {
    "uniqueItems": true,
    "type": "boolean",
    "description": "...",
    "name": "watch",
    "in": "query"
  }
]

@brendandburns
Copy link
Contributor

@rotty3000 the custom object API is not dynamically generated from the OpenAPI spec for your CRD, it is statically generated from that static openAPI spec, which is intended to be generic for all CRDs.

If you want to generate a client from your CRDs OpenAPI Spec, you need to do something like the instructions for Java here:

https://github.com/kubernetes-client/java/blob/master/docs/generate-model-from-third-party-resources.md

The steps needed haven't been streamlined or documented for Javascript, but it shouldn't be too hard to adapt those instructions for javascript.

For the label selector, yes, the current javascript code generation has been complicated by the fact that we are migrating to a new code generator, while also trying to support an older code generator. We need to cherry-pick the PR with the labelSelector into the request based generator which is running at an older commit, similar to here:

https://github.com/kubernetes-client/javascript/blob/master/.github/workflows/generate-javascript.yml#L35

We'd be happy to take a PR for that also.

@rotty3000
Copy link
Author

@rotty3000 the custom object API is not dynamically generated from the OpenAPI spec for your CRD, it is statically generated from that static openAPI spec, which is intended to be generic for all CRDs.

This isn't news to me. I'm just shocked by how out of sync it seems to be. I wish I could find some time, I'd love to help improve things.

Thanks for your feedback.

@brendandburns
Copy link
Contributor

wrt to being out of sync, there's nothing automatic to keep it in sync, so it requires people to notice and have the cycles to write a PR. It seems these parameters aren't being used much as you are the first to notice ;)

I'll tag this issue as a good first issue, in case someone else has cycles.

@brendandburns brendandburns added the good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. label Jul 12, 2024
@ArpanSolanki29
Copy link
Contributor

/assign

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines.
Projects
None yet
Development

No branches or pull requests

3 participants