UNKNOWN_BASE_TYPE in documentation for patch_* methods

[rihardsk]

Link to the issue (please include a link to the specific documentation or example):
https://github.com/kubernetes-client/python/blob/master/kubernetes/docs/AppsV1Api.md#patch_namespaced_deployment_scale and other patch_* methods.

Description of the issue (please include outputs or screenshots if possible):
The type for the method's body parameter is UNKNOWN_BASE_TYPE. It's not clear to me what to pass to the method (i'm guessing V1Scale in this instance).

[xiaomaimuchanyiyiba]

It's not clear to me too

[yuri-stepanov]

JFYI, I have tried to V1Scale, but it doesnt work apparently, so I just passing {"spec": {"replicas": 3}. Seems to do the trick.

[roycaihw]

cc @tomplus

/assign

[roycaihw]

There was no UNKNOWN_BASE_TYPE in 10.0 client (Kubernetes 1.14). This looks like a regression introduced by either openapi-generator or Kubernetes 1.15.

[tomplus]

It looks like openapi-generator insert it when the spec doesn't define the content-type:

https://github.com/OpenAPITools/openapi-generator/blob/c882338ef134e9c00a02fed2d2792b7eda36ea95/modules/openapi-generator/src/main/java/org/openapitools/codegen/DefaultCodegen.java#L4981-L4987

In v10 we have NULL which is also incorrect:

https://github.com/kubernetes-client/python/blob/release-10.0/kubernetes/docs/AppsV1Api.md#patch_namespaced_deployment_scale

The content-type in patch_ methods depends on the requester (ref: #959) and we have to agree that our auto-generated docs don't work well and need to be re-written (ref: #601).

[logicbomb421]

Running into this problem myself. Will the documentation be regenerated soon, or is there different documentation I can look at? Pretty new to interacting with the API directly, so not having documentation on what the body of a request should look like is somewhat tough.

[avbanks]

If anyone runs in to this issue a good way to find out what api object is needed is to edit the resource in question with kubectl edit -v 9

ex : if we wanted to patch the annotations in a pod run:

kubectl edit pod vault-test -v 9
then edit the annotation add test: test
now note the line "Request Body: Request Body: {"metadata":{"annotations":{"test":test}}}"

This tells you what the body of the patch needs to be for the particular patch you're requesting (in the example case we're annotating metadata).

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[hantmac]

Running into this problem, confusing too. 😭

[nrmitchi]

I ran into this as well last, but I think I've gotten it for the most part figured out.

The way that this is now displayed in the docs (UNKNOWN_BASE_TYPE) is implying that there is a given object type that should be there.

I believe that the body of all of these request types is just meant to be an arbitrary dict, containing the same information that would be present by patch-ing a resource with kubectl: Ie,

kubectl patch deployment <name> -p "{\"spec\":{\"template\":{\"metadata\":{\"labels\":{\"date\":\"`date +'%s'`\"}}}}}"

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.