Generate 8.0.0 snapshot client on master branch #631
Conversation
against kubernetes 1.12.0 release
against kubernetes release-1.12 branch
k8s-ci-robot
added
the
cncf-cla: yes
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: roycaihw 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 |
k8s-ci-robot
added
approved
| @@ -3,8 +3,8 @@ No description provided (generated by Swagger Codegen https://github.com/swagger | |||
|
|
|||
| This Python package is automatically generated by the [Swagger Codegen](https://github.com/swagger-api/swagger-codegen) project: | |||
|
|
|||
| - API version: v1.11.3 | |||
| - Package version: 7.0.0-snapshot | |||
| - API version: v1.12.1 | |||
There was a problem hiding this comment.
k8s latest release is v1.12.0, why is here v1.12.1?
There was a problem hiding this comment.
Yes I also noticed this during client generation. The API version comes from the currently checked-in openapi spec on k/k release branch https://github.com/kubernetes/kubernetes/blob/release-1.12/api/openapi-spec/swagger.json
"swagger": "2.0",
"info": {
"title": "Kubernetes",
"version": "v1.12.1"
},
The other release branches have the same behavior. I suppose when a patch release is cut (e.g. 1.11.3), the generated openapi spec shows the version for next patch release (1.11.4) that is open for cherry-pick.
I think it's a problem in our client generation code. We should probably curl the released source code to get the openapi spec, instead of downloading from the release branch: https://github.com/kubernetes-client/gen/blob/4aa859fc518385886434d9169a8e383dd1fd16c2/openapi/preprocess_spec.py#L312-L315
We are also exposed to non-deterministic client generation-- currently the client is said to be generated against API version v1.12.1, but there might be new API change introduced later to 1.12.1 that we didn't catch. That being said, in general I don't expect major API change getting introduced to patch release.
| @@ -122,6 +123,7 @@ between client-python versions. | |||
| | 6.0 | Kubernetes main repo, 1.10 branch | ✓ | | |||
| | 7.0 Alpha/Beta | Kubernetes main repo, 1.11 branch | ✗ | | |||
| | 7.0 | Kubernetes main repo, 1.11 branch | ✓ | | |||
| | 8.0 Alpha/Beta | Kubernetes main repo, 1.12 branch | ✓ | | |||
|
|
|||
There was a problem hiding this comment.
i think k8s only supports 3 versions, should we mark the older python client releases here as 'unsupported'?
There was a problem hiding this comment.
Great point! I updated the matrix and also documented the support policy below.
roycaihw
force-pushed
the
generate-8.0.0-snapshot
branch
3 times, most recently
from
7e0eb64 to
684a24e
Compare
|
Verified the two API changes in the first comment aren't client-facing. Also tracked the dry-run openapi spec issue in kubernetes/kubernetes#69304. To properly support dry-run feature in this client, we need to cherrypick the doc fix to 1.12 in Kubernetes, and re-generate the client. I'm not certain if the fix will make it in 1.12.1 (which is when we target the 8.0.0b1 release). If we want to re-generate the client to support the dry-run feature, we probably need to do a 8.0.1(b1/GA) release later. @yliaog WDYT? |
|
have you addressed the concerns you raised in the PR description? kubernetes/kubernetes#66807 |
roycaihw
force-pushed
the
generate-8.0.0-snapshot
branch
2 times, most recently
from
39660af to
510509d
Compare
generated from kubernetes 1.12.0
roycaihw
force-pushed
the
generate-8.0.0-snapshot
branch
from
510509d to
e91700f
Compare
|
/lgtm |
k8s-ci-robot
added
the
lgtm
... against Kubernetes 1.12.0 openapi spec. Also update README and CHANGELOG about new feature, bug fix and API change.
Some upstream API changes that I'm not sure if they are client-facing (I guess minor):
Also from what I see, we intended to add
dryRunoption to CREATE/UPDATE/PATCH/DELETE verbs, but only DELETE has the dryRun option documented and generated. I will investigate if it's a upstream openapi spec documentation problem.The next step is to fork master branch into
release-8.0branch, update version constants, and generate a 8.0.0a1 client (no API change, only version numbers change)/assign @yliaog