kubernetes-client/python
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Misc typo fixes

Browse Source 
Signed-off-by: Abhijeet Kasurde <akasurde@redhat.com>
This commit is contained in:
Abhijeet Kasurde 2021-12-17 12:23:37 +05:30
parent 24e6e8f00a
commit 50b921247a
7 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
README.md
View File

@ -92,7 +92,7 @@ supported versions of Kubernetes clusters.
- [client 20.y.z](https://pypi.org/project/kubernetes/20.13.0/): Kubernetes 1.19 or below (+-), Kubernetes 1.20 (✓), Kubernetes 1.21 or above (+-)
- [client 21.y.z](https://pypi.org/project/kubernetes/21.7.0/): Kubernetes 1.20 or below (+-), Kubernetes 1.21 (✓), Kubernetes 1.22 or above (+-)
> See [here](#homogenizing-the-kubernetes-python-client-versions) for an explaination of why there is no v13-v16 release.
> See [here](#homogenizing-the-kubernetes-python-client-versions) for an explanation of why there is no v13-v16 release.
Key:
@ -138,7 +138,7 @@ between client-python versions.
| 21.0 Alpha/Beta | Kubernetes main repo, 1.21 branch | ✗ |
| 21.0 | Kubernetes main repo, 1.21 branch | ✓ |
> See [here](#homogenizing-the-kubernetes-python-client-versions) for an explaination of why there is no v13-v16 release.
> See [here](#homogenizing-the-kubernetes-python-client-versions) for an explanation of why there is no v13-v16 release.
Key:
@ -155,7 +155,7 @@ Note: There would be no maintenance for alpha/beta releases except the latest on
The client releases v12 and before following a versioning schema where the major version was 4 integer positions behind the Kubernetes minor on which the client is based on. For example, v12.0.0 is based on Kubernetes v1.16, v11.0.0 is based on Kubernetes v1.15 and so on.
This created a lot of confusion tracking two different version numbers for each client release. It was decided to homogenize the version scheme starting from the Kubernetes Python client based on Kubernetes v1.17. The versioning scheme of the client from this release would be vY.Z.P where Y and Z are the Kubernetes minor and patch release numbers from Kubernets v1.Y.Z and P is the client specific patch release numbers to accomodate changes and fixes done specifically to the client. For more details, refer [this issue](https://github.com/kubernetes-client/python/issues/1244).
This created a lot of confusion tracking two different version numbers for each client release. It was decided to homogenize the version scheme starting from the Kubernetes Python client based on Kubernetes v1.17. The versioning scheme of the client from this release would be vY.Z.P where Y and Z are the Kubernetes minor and patch release numbers from Kubernets v1.Y.Z and P is the client specific patch release numbers to accommodate changes and fixes done specifically to the client. For more details, refer [this issue](https://github.com/kubernetes-client/python/issues/1244).
## Community, Support, Discussion

2
examples/deployment_crud.py
View File

@ -40,7 +40,7 @@ def create_deployment_object():
),
)
# Create and configurate a spec section
# Create and configure a spec section
template = client.V1PodTemplateSpec(
metadata=client.V1ObjectMeta(labels={"app": "nginx"}),
spec=client.V1PodSpec(containers=[container]),

6
examples/dynamic-client/namespaced_custom_resource.py
View File

@ -17,7 +17,7 @@ This example demonstrates the following:
- Creation of a custom resource definition (CRD) using dynamic-client
- Creation of namespaced custom resources (CR) using the above CRD
- List, patch (update), delete the custom resources
- Delete the custom resource defintion (CRD)
- Delete the custom resource definition (CRD)
"""
from kubernetes import config, dynamic
@ -125,14 +125,14 @@ def main():
},
}
crd_creation_respone = crd_api.create(crd_manifest)
crd_creation_response = crd_api.create(crd_manifest)
print(
"\n[INFO] custom resource definition `ingressroutes.apps.example.com` created\n"
)
print("%s\t\t%s" % ("SCOPE", "NAME"))
print(
"%s\t%s\n"
% (crd_creation_respone.spec.scope, crd_creation_respone.metadata.name)
% (crd_creation_response.spec.scope, crd_creation_response.metadata.name)
)
# Fetching the "ingressroutes" CRD api

2
examples/job_crud.py
View File

@ -32,7 +32,7 @@ def create_job_object():
name="pi",
image="perl",
command=["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"])
# Create and configurate a spec section
# Create and configure a spec section
template = client.V1PodTemplateSpec(
metadata=client.V1ObjectMeta(labels={"app": "pi"}),
spec=client.V1PodSpec(restart_policy="Never", containers=[container]))

2
examples/notebooks/create_secret.ipynb
View File

@ -246,7 +246,7 @@
"source": [
"### View secret being used within the pod\n",
"\n",
"Wait for alteast 10 seconds to ensure pod is running before executing this section."
"Wait for atleast 10 seconds to ensure pod is running before executing this section."
]
},
{

2
examples/notebooks/intro_notebook.ipynb
View File

@ -30,7 +30,7 @@
"- **`delete_xxxx`** : delete a resource. This performs operations similar to **`kubectl delete`**.\n",
"\n",
"\n",
"For Futher information see the Documentation for API Endpoints section in https://github.com/kubernetes-client/python/blob/master/kubernetes/README.md"
"For Further information see the Documentation for API Endpoints section in https://github.com/kubernetes-client/python/blob/master/kubernetes/README.md"
]
},
{

8
scripts/apply-hotfixes.sh
View File

@ -31,7 +31,7 @@ fi
git cherry-pick -n 88397bcc5b3b348a41dbf641367756b86552d362
if [ $? -eq 0 ]
then
echo Succesfully patched changes for custom client behavior
echo Successfully patched changes for custom client behavior
else
echo Failed to patch changes for custom client behavior
git restore --staged .
@ -44,7 +44,7 @@ fi
git cherry-pick -n 56ab983036bcb5c78eee91483c1e610da69216d1
if [ $? -eq 0 ]
then
echo Succesfully patched changes for enabling from kubernetes import apis
echo Successfully patched changes for enabling from kubernetes import apis
else
echo Failed to patch changes for enabling from kubernetes import apis
git restore --staged .
@ -57,7 +57,7 @@ fi;
git cherry-pick -n 13dffb897617f87aaaee247095107d7011e002d5
if [ $? -eq 0 ]
then
echo Succesfully patched changes for Client Context Manager
echo Successfully patched changes for Client Context Manager
else
echo Failed to patch changes for Client Context Manager
git restore --staged .
@ -70,7 +70,7 @@ fi;
git cherry-pick -n 95a893cd1c34de11a4e3893dd1dfde4a0ca30bdc
if [ $? -eq 0 ]
then
echo Succesfully patched changes for no_proxy support
echo Successfully patched changes for no_proxy support
else
echo Failed to patch changes for no_proxy support
git restore --staged .