-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
regenerate client code with latest k8s api #682
regenerate client code with latest k8s api #682
Conversation
Please see #584 (comment). The python 3.7 support issue was about the reserved keyword workaround. It's not related to Kubernetes API (openapi spec). We already have two GA releases that support Python 3.7 (v7.0.0 and v8.0.0). Please try the new versions out. I don't see strong reason for re-generating v6 client against Kubernetes release-1.10 spec. Closing /close |
@roycaihw: Closing this PR. In response to this:
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. |
More thoughts on this: Kubernetes supports three minor releases at the same time. Currently it's 1.10, 1.11 and 1.12. This python client repo follows similar policy and we currently support v6, v7 and v8. Kubernetes v1.13.0 is planned to be released in less a month (Dec. 3rd). After k8s 1.13 is released, 1.10 will not be supported, and we will start releasing python client v9 and dropping v6. At this point, given the short period of supporting 1.10, I'd suggest switching to more recent versions of Kubernetes, instead of releasing a python client v6.0.1 to support Python 3.7 [update] Also please take a look at #681 (comment). Please try 7.0.0 release to see if it works better with k8s 1.10 apiserver |
Yes. In order to get the fix for the reserved keyword it is necessary to do what I have done in this PR - do you disagree?
I would like to use python 3.7 with v6 because I want to use K8 1.10 which is supposed to be supported now.
I suggest that you merge my PR and support all the versions of K8s that are supposed to be supported. That sounds good in principle. We are using hosted Kubernetes with GCP and 1.11 has only been available for general use for less than a week, we need some time to ensure that we can move to 1.11 without problems. Do you have an actual reason not to merge this PR? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@eastlondoner Fair enough. This covers a gap in our support for Kubernetes 1.10 with Python 3.7.
Please add a section to the CHANGELOG noting what's changed in v6.1.0 (actually bumping minor version number is not enough, as we are introducing breaking change here):
- Breaking Change:
- ACTION REQUIRED Rename the currently being-used async parameter to async_req to support Python 3.7 because it's a reserved keyword in Python 3.7 feat: support for 3.7 (workaround) gen#67
NOTE that Python 3.7 was released after v6.0.0 release. Please DON'T upgrade your client to v6.1.0 if you do not use Python 3.7.
- ACTION REQUIRED Rename the currently being-used async parameter to async_req to support Python 3.7 because it's a reserved keyword in Python 3.7 feat: support for 3.7 (workaround) gen#67
- API Change:
- Add custom object status and scale api Add custom object status and scale api gen#72
Once we merge this PR we can start making Pypi distribution packages and Github release page.
/cc @yliaog
kubernetes/README.md
Outdated
``` | ||
(you may need to run `pip` with root permission: `sudo pip install git+https://github.com/kubernetes-client/python.git`) | ||
(you may need to run `pip` with root permission: `sudo pip install git+https://github.com/kubernetes-kubernetes.client/python.git`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please manually restore the commands in L20 and L22. I believe we have some misconfig of automation/swagger-codegen that writes the extra kubernetes.
@@ -79877,7 +79877,7 @@ | |||
"type": "string" | |||
}, | |||
"mountPropagation": { | |||
"description": "mountPropagation determines how mounts are propagated from the host to container and the other way around. When not set, MountPropagationHostToContainer is used. This field is beta in 1.10.", | |||
"description": "mountPropagation determines how mounts are propagated from the host to container and the other way around. When not set, MountPropagationNone is used. This field is beta in 1.10.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like there is no significant api change from openapi spec :)
Thanks @roycaihw. |
tox.ini
Outdated
commands = | ||
python -V | ||
{toxinidir}/scripts/kube-init.sh py.test -vvv -s [] | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m not sure we test Python 3.7 functional in our Travis CI even in the master branch. Also, I’m not sure if official support for Travis CI has been extended to Python 3.7. See the most recent Travis build.
Need confirmation from @roycaihw
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, well I guess this is future proof at least
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We haven't supported Python 3.7 in our travis-ci yet. Please see #584
Changes (tox.ini
and .travis.yml
) need to be checked into master branch in both python
and python-base
. I'm more comfortable with having separate PRs for those changes and this PR including necessary client re-generation. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Me too. I prefer to wait to see Travis CI support Python 3.7 and make sure the keywords are correct, and then check them into the master branch.
I realized that I missed mentioning the step to update version constant. Please regenerate the client with the following steps:
|
ce7715a
to
2e90425
Compare
2e90425
to
443894a
Compare
Done. |
/lgtm |
/lgtm |
/approve |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: eastlondoner, roycaihw If they are not already assigned, you can assign the PR to them by writing 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 |
Thanks :-D this helps us to upgrade our stack smoothly as we work towards 1.11 |
So that it is compatible with python 3.7