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

Remove duplication (#2762) 

* Remove duplication

Signed-off-by: mooncake <xcoder@tenxcloud.com>

* Update admission_control_resource_quota.md
This commit is contained in:
Bily Zhang 2018-10-10 00:42:22 +08:00 committed by k8s-ci-robot
parent 6b4ac945c6
commit b30b6b7a34
4 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
contributors/design-proposals/scheduling/taint-toleration-dedicated.md
View File

@ -87,7 +87,7 @@ allowed to use that new dedicated node group.
```go
// The node this Taint is attached to has the effect "effect" on
// any pod that that does not tolerate the Taint.
// any pod that does not tolerate the Taint.
type Taint struct {
Key string `json:"key" patchStrategy:"merge" patchMergeKey:"key"`
Value string `json:"value,omitempty"`

4
contributors/design-proposals/storage/container-storage-interface.md
View File

@ -201,7 +201,7 @@ Once the following conditions are true, the external-attacher should call `Contr
Before starting the `ControllerPublishVolume` operation, the external-attacher should add these finalizers to these Kubernetes API objects:
* To the `VolumeAttachment` so that when the object is deleted, the external-attacher has an opportunity to detach the volume first. External attacher removes this finalizer once the volume is fully detached from the node.
* To the `PersistentVolume` referenced by `VolumeAttachment` so the the PV cannot be deleted while the volume is attached. External attacher needs information from the PV to perform detach operation. The attacher will remove the finalizer once all `VolumeAttachment` objects that refer to the PV are deleted, i.e. the volume is detached from all nodes.
* To the `PersistentVolume` referenced by `VolumeAttachment` so the PV cannot be deleted while the volume is attached. External attacher needs information from the PV to perform detach operation. The attacher will remove the finalizer once all `VolumeAttachment` objects that refer to the PV are deleted, i.e. the volume is detached from all nodes.
If the operation completes successfully, the external-attacher will:
@ -587,7 +587,7 @@ In order to upgrade drivers using the recommended driver deployment mechanism, t
#### Deleting Volumes
1. A user deletes a `PersistentVolumeClaim` object bound to a CSI volume.
2. The external-provisioner for the CSI driver sees the the `PersistentVolumeClaim` was deleted and triggers the retention policy:
2. The external-provisioner for the CSI driver sees the `PersistentVolumeClaim` was deleted and triggers the retention policy:
1. If the retention policy is `delete`
1. The external-provisioner triggers volume deletion by issuing a `DeleteVolume` call against the CSI volume plugin container.
2. Once the volume is successfully deleted, the external-provisioner deletes the corresponding `PersistentVolume` object.

2
contributors/design-proposals/storage/volume-snapshotting.md
View File

@ -196,7 +196,7 @@ Open questions:
* Do we call them snapshots or backups?
* From the SIG email: "The snapshot should not be suggested to be a backup in any documentation, because in practice is is necessary, but not sufficient, when conducting a backup of a stateful application."
* From the SIG email: "The snapshot should not be suggested to be a backup in any documentation, because in practice is necessary, but not sufficient, when conducting a backup of a stateful application."
* At what minimum granularity should snapshots be allowed?

2
contributors/design-proposals/storage/volume-topology-scheduling.md
View File

@ -1079,7 +1079,7 @@ scenarios to keep equivalence class cache up to date:
- on PV add/delete
When PVs are created or deleted, available PVs to choose from for volume
scheduling will change, we need to to invalidate CheckVolumeBinding
scheduling will change, we need to invalidate CheckVolumeBinding
predicate.
- on PV update