From b30b6b7a34ced77bfaf533c8b86d62ee1697ebfa Mon Sep 17 00:00:00 2001 From: Bily Zhang Date: Wed, 10 Oct 2018 00:42:22 +0800 Subject: Remove duplication (#2762) * Remove duplication Signed-off-by: mooncake * Update admission_control_resource_quota.md --- .../design-proposals/scheduling/taint-toleration-dedicated.md | 2 +- contributors/design-proposals/storage/container-storage-interface.md | 4 ++-- contributors/design-proposals/storage/volume-snapshotting.md | 2 +- contributors/design-proposals/storage/volume-topology-scheduling.md | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/contributors/design-proposals/scheduling/taint-toleration-dedicated.md b/contributors/design-proposals/scheduling/taint-toleration-dedicated.md index e451f395..dc7a6483 100644 --- a/contributors/design-proposals/scheduling/taint-toleration-dedicated.md +++ b/contributors/design-proposals/scheduling/taint-toleration-dedicated.md @@ -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"` diff --git a/contributors/design-proposals/storage/container-storage-interface.md b/contributors/design-proposals/storage/container-storage-interface.md index 5e85623a..9a1b3d5e 100644 --- a/contributors/design-proposals/storage/container-storage-interface.md +++ b/contributors/design-proposals/storage/container-storage-interface.md @@ -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. diff --git a/contributors/design-proposals/storage/volume-snapshotting.md b/contributors/design-proposals/storage/volume-snapshotting.md index eeb71b44..df0aa1a7 100644 --- a/contributors/design-proposals/storage/volume-snapshotting.md +++ b/contributors/design-proposals/storage/volume-snapshotting.md @@ -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? diff --git a/contributors/design-proposals/storage/volume-topology-scheduling.md b/contributors/design-proposals/storage/volume-topology-scheduling.md index b9234afd..230398c7 100644 --- a/contributors/design-proposals/storage/volume-topology-scheduling.md +++ b/contributors/design-proposals/storage/volume-topology-scheduling.md @@ -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 -- cgit v1.2.3