diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 6b48abda7c..9a716b3608 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,4 +1,4 @@ -# Contributing guidelines +# Contributing Guidelines ## How to become a contributor and submit your own code @@ -21,6 +21,6 @@ Follow either of the two links above to access the appropriate CLA and instructi 1. Fork the desired repo, develop and test your code changes. 1. Submit a pull request. -### Adding dependencies +### Adding Dependencies If your patch depends on new packages, add those packages to [requirements.txt](requirements.txt) and [setup.py](setup.py). diff --git a/OWNERS b/OWNERS index c982a452a3..dd6cbaeb28 100644 --- a/OWNERS +++ b/OWNERS @@ -6,4 +6,3 @@ approvers: - lavalamp - yliaog - roycaihw - diff --git a/README.md b/README.md index ce8b87991f..199f7124fc 100644 --- a/README.md +++ b/README.md @@ -70,7 +70,6 @@ python -m examples.example1 (replace example1 with the example base filename) - ## Documentation All APIs and Models' documentation can be found at the [Generated client's README file](kubernetes/README.md) @@ -131,7 +130,6 @@ between client-python versions. | 9.0 | Kubernetes main repo, 1.13 branch | ✓ | | 10.0 Alpha/Beta | Kubernetes main repo, 1.14 branch | ✓ | - Key: * `✓` Changes in main Kubernetes repo are manually ([should be automated](https://github.com/kubernetes-client/python/issues/177)) published to client-python when they are available. @@ -151,11 +149,10 @@ Participation in the Kubernetes community is governed by the [CNCF Code of Condu ## Kubernetes Incubator -This is a [Kubernetes Incubator project](https://github.com/kubernetes/community/blob/master/incubator.md). +This is a [Kubernetes Incubator project](https://github.com/kubernetes/community/blob/master/incubator.md). * [SIG: sig-api-machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery) - ## Troubleshooting ### SSLError on macOS @@ -179,10 +176,11 @@ You'll need a version with OpenSSL version 1.0.0 or later. ### Hostname doesn't match -If you get an `ssl.CertificateError` complaining about hostname match, your installed packages does not meet version [requirements](requirements.txt). +If you get an `ssl.CertificateError` complaining about hostname match, your installed packages does not meet version [requirements](requirements.txt). Specifically check `ipaddress` and `urllib3` package versions to make sure they met requirements in [requirements.txt](requirements.txt) file. ### Why Exec/Attach calls doesn't work + Starting from 4.0 release, we do not support directly calling exec or attach calls. you should use stream module to call them. so instead of `resp = api.connect_get_namespaced_pod_exec(name, ...` you should call `resp = stream(api.connect_get_namespaced_pod_exec, name, ...`. See more at [exec example](examples/exec.py). diff --git a/devel/release.md b/devel/release.md index acfafa643f..75fe8986cb 100644 --- a/devel/release.md +++ b/devel/release.md @@ -1,20 +1,20 @@ # Release process -Release process of python client involve creating (or updating) a release -branch, update release tags, create distribution packages and upload them to -pip. +The release process of the python client involves creating (or updating) a release +branch, updating release tags, and creating distribution packages and uploading them to +pypi. ## Change logs -Make sure changes logs are up to date [here](https://github.com/kubernetes-client/python/blob/master/CHANGELOG.md). -If they are not, follow commits added after last release and update/commit +Make sure the change logs are up to date [here](https://github.com/kubernetes-client/python/blob/master/CHANGELOG.md). +If they are not, follow commits added after the last release and update/commit the change logs to master. Then based on the release, follow one of next two steps. ## Update pre-release branch -Release branch name should have release-x.x format. All minor and pre-releases -should be on the same branch. To update an existing branch with master(only for +The release branch name should have release-x.x format. All minor and pre-releases +should be on the same branch. To update an existing branch with master (only for latest pre-release): ```bash @@ -37,8 +37,8 @@ cherry pick first: scripts/cherry_pick_pull.sh ``` -Do not merge master into an stable releast branch. Run the script without -parameters and follow its instruction to create cherry pick PR and get the +Do not merge master into a stable release branch. Run the script without +parameters and follow its instructions to create a cherry pick PR. Get the PR merged then update your local branch: ```bash @@ -49,8 +49,9 @@ git rebase upstream/$RELEASE_BRANCH ``` ## Sanity check generated client -We need to make sure there is no API changes after running update client -scripts. Such changes should be committed to master branch first. Run this + +We need to make sure there are no API changes after running update client +scripts. Such changes should be committed to the master branch first. Run this command: ```bash @@ -58,17 +59,17 @@ scripts/update-client.sh ``` And make sure there is no API change (version number changes should be fine -as they will be updated in next step anyway). Do not commit any changes at -this step and go back to master branch if there is any API changes. +as they will be updated in the next step anyway). Do not commit any changes at +this step and go back to the master branch if there are any API changes. ## Update release tags -Release tags are in scripts/constants.py file. These are the constants you may +Release tags are in the "scripts/constants.py" file. These are the constants you may need to update: CLIENT_VERSION: Client version should follow x.y.zDn where x,y,z are version numbers (integers) and D is one of "a" for alpha or "b" for beta and n is the -pre-release number. For a final release, "Dn" part should be omitted. Examples: +pre-release number. For a final release, the "Dn" part should be omitted. Examples: 1.0.0a1, 2.0.1b2, 1.5.1. DEVELOPMENT_STATUS: Update it to one of the values of "Development Status" @@ -89,8 +90,9 @@ git push upstream $RELEASE_BRANCH ``` ## Make distribution packages + First make sure you are using a clean version of python. Use virtualenv and -pyenv packages, make sure you are using python 2.7.12. I would normally do this +pyenv packages. Make sure you are using python 2.7.12. I would normally do this on a clean machine: (install [pyenv](https://github.com/yyuu/pyenv#installation)) @@ -128,9 +130,9 @@ python setup.py bdist_wheel --universal ls dist/ ``` -You should see two files in dist folder. kubernetes\*.whl and kubernetes\*.tar.gz. +You should see two files in dist folder: "kubernetes\*.whl" and "kubernetes\*.tar.gz". -TODO: We need a dry-run option an some way to test package upload process to pypi. +TODO: We need a dry-run option and some way to test the package upload process to pypi. If everything looks good, run this command to upload packages to pypi: @@ -142,13 +144,13 @@ twine upload dist/* Create a gihub release by starting from [this page](https://github.com/kubernetes-client/python/releases). -Click Deaft new release button. Name the tag the same as CLIENT_VERSION. Change +Click the `Draft a new release button`. Name the tag the same as CLIENT_VERSION. Change the target branch to "release-x.y". If the release is a pre-release, check the `This is a pre-release` option. - ## Announcement -Send an announcement email to kubernetes-dev@googlegroups.com with the subject [ANNOUNCE] kubernetes python-client $VERSION is released + +Send an announcement email to kubernetes-dev@googlegroups.com with the subject: [ANNOUNCE] kubernetes python-client $VERSION is released ## Cleanup @@ -159,5 +161,4 @@ rm -rf .release TODO: Convert steps in this document to an (semi-) automated script. - ref: https://packaging.python.org/distributing/ diff --git a/devel/stats.md b/devel/stats.md index d374a1ed4a..db2ef1e247 100644 --- a/devel/stats.md +++ b/devel/stats.md @@ -23,4 +23,3 @@ LIMIT 20 More example queries can be found [here](https://gist.github.com/alex/4f100a9592b05e9b4d63) Reference: https://mail.python.org/pipermail/distutils-sig/2016-May/028986.html - diff --git a/devel/submodules.md b/devel/submodules.md index 0621b76fdd..68ca4eee0e 100644 --- a/devel/submodules.md +++ b/devel/submodules.md @@ -1,27 +1,29 @@ # Submodules + To comply with [client library structure requirement](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/csi-client-structure-proposal.md), -python client base utilities is moved into kubernetes-client/python-base repo. `git submodules` is being used to handle dependency to that repo. -This document will provide basic steps to get submodules work. +python client base utilities is moved into the [kubernetes-client/python-base](https://github.com/kubernetes-client/python-base) repo. `git submodules` is being used to handle dependency to that repo. +This document will provide basic steps to get submodules working. # Clone repo -To clone repo, you need to pass `recursive` parameter to make the clone also get submodules: + +To clone the repo, you need to pass the `recursive` parameter to make the clone also get submodules: ```bash git clone --recursive https://github.com/kubernetes-client/python.git ``` -if you already clone repo with no `--recursive` option, you can run this command to get submodules: +if you have already cloned the repo with no `--recursive` option, you can run this command to get submodules: ```bash git submodule update --init ``` # Update submodule -If you changed kubernetes-client/python-base and want to pull your changes into this repo run this command: + +If you changed [kubernetes-client/python-base](https://github.com/kubernetes-client/python-base) and want to pull your changes into this repo run this command: ```bash git submodule update --remote ``` Once updated, you should create a new PR to commit changes to the repository. -