kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix a few grammar issues and typos (#28332) 

* Fix few grammar issues and typos in the blog page

> see the API documentation more information
Should be corrected to "documentation for more information" as the sentence is incorrect.

> may only compare two resource version for equality
Everywhere else in the paragraph "resource versions" are used, I believe this is just a typo.

> The get, list and watch
Missing comma after list to separate the elements

* Fix typos in blog post

> On rare occurences, a 
"occurrences" is misspelled

>  whole list, map or struct
3 elements are missing a comma seperator after map
 
>  there are no way 
are is a plural form while "no way" is a singular subject

> `MergePatch`, `StrategicMergePatch`, `JSONPatch` or `Update`
Missing comma after JSONPatch
This commit is contained in:
Squidtoon99 2021-06-08 21:11:47 -05:00 committed by GitHub
parent 6852192fc4
commit ddc67b8114
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
content/en/docs/reference/using-api/api-concepts.md
View File

@ -49,7 +49,7 @@ Some resource types will have one or more sub-resources, represented as sub path
* Cluster-scoped subresource: `GET /apis/GROUP/VERSION/RESOURCETYPE/NAME/SUBRESOURCE`
* Namespace-scoped subresource: `GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME/SUBRESOURCE`
The verbs supported for each subresource will differ depending on the object - see the API documentation more information. It is not possible to access sub-resources across multiple resources - generally a new virtual resource type would be used if that becomes necessary.
The verbs supported for each subresource will differ depending on the object - see the API documentation for more information. It is not possible to access sub-resources across multiple resources - generally a new virtual resource type would be used if that becomes necessary.
## Efficient detection of changes
@ -442,7 +442,7 @@ feature, see the section on
## Resource Versions
Resource versions are strings that identify the server's internal version of an object. Resource versions can be used by clients to determine when objects have changed, or to express data consistency requirements when getting, listing and watching resources. Resource versions must be treated as opaque by clients and passed unmodified back to the server. For example, clients must not assume resource versions are numeric, and may only compare two resource version for equality (i.e. must not compare resource versions for greater-than or less-than relationships).
Resource versions are strings that identify the server's internal version of an object. Resource versions can be used by clients to determine when objects have changed, or to express data consistency requirements when getting, listing and watching resources. Resource versions must be treated as opaque by clients and passed unmodified back to the server. For example, clients must not assume resource versions are numeric, and may only compare two resource versions for equality (i.e. must not compare resource versions for greater-than or less-than relationships).
### ResourceVersion in metadata
@ -454,7 +454,7 @@ Clients find resource versions in resources, including the resources in watch ev
### The ResourceVersion Parameter
The get, list and watch operations support the `resourceVersion` parameter.
The get, list, and watch operations support the `resourceVersion` parameter.
The exact meaning of this parameter differs depending on the operation and the value of `resourceVersion`.

8
content/en/docs/reference/using-api/server-side-apply.md
View File

@ -245,7 +245,7 @@ field tags.
### Compatibility across topology changes
On rare occurences, a CRD or built-in type author may want to change the
On rare occurrences, a CRD or built-in type author may want to change the
specific topology of a field in their resource without incrementing its
version. Changing the topology of types, by upgrading the cluster or
updating the CRD, has different consequences when updating existing
@ -253,7 +253,7 @@ objects. There are two categories of changes: when a field goes from
`map`/`set`/`granular` to `atomic` and the other way around.
When the `listType`, `mapType`, or `structType` changes from
`map`/`set`/`granular` to `atomic`, the whole list, map or struct of
`map`/`set`/`granular` to `atomic`, the whole list, map, or struct of
existing objects will end-up being owned by actors who owned an element
of these types. This means that any further change to these objects
would cause a conflict.
@ -310,7 +310,7 @@ simplify the update logic of your controller. The main differences with a
read-modify-write and/or patch are the following:
* the applied object must contain all the fields that the controller cares about.
* there are no way to remove fields that haven't been applied by the controller
* there is no way to remove fields that haven't been applied by the controller
before (controller can still send a PATCH/UPDATE for these use-cases).
* the object doesn't have to be read beforehand, `resourceVersion` doesn't have
to be specified.
@ -473,7 +473,7 @@ have an opinion about.
## Clearing ManagedFields
It is possible to strip all managedFields from an object by overwriting them
using `MergePatch`, `StrategicMergePatch`, `JSONPatch` or `Update`, so every
using `MergePatch`, `StrategicMergePatch`, `JSONPatch`, or `Update`, so every
non-apply operation. This can be done by overwriting the managedFields field
with an empty entry. Two examples are: