Generate 8.0.0 snapshot client on master branch

[roycaihw]

... 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):

• Make admission webhooks conversion convert CONNECT body correctly kubernetes/kubernetes#66807
• Default extensions/v1beta1 Deployment's ProgressDeadlineSeconds to MaxInt32 kubernetes/kubernetes#66581

Also from what I see, we intended to add dryRun option 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.0 branch, update version constants, and generate a 8.0.0a1 client (no API change, only version numbers change)

/assign @yliaog

[k8s-ci-robot]

[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

Details

Needs approval from an approver in each of these files:

• OWNERS [roycaihw]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[yliaog]

k8s latest release is v1.12.0, why is here v1.12.1?

[roycaihw]

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.

[yliaog]

i think k8s only supports 3 versions, should we mark the older python client releases here as 'unsupported'?

[roycaihw]

Great point! I updated the matrix and also documented the support policy below.

[roycaihw]

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?

[yliaog]

have you addressed the concerns you raised in the PR description?

kubernetes/kubernetes#66807
kubernetes/kubernetes#66581
Also from what I see, we intended to add dryRun option 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.

[yliaog]

/lgtm