From b12bde0845e35de76731cf213177a3b5e5eb418a Mon Sep 17 00:00:00 2001 From: Andrew Allbright Date: Sun, 23 Feb 2020 06:54:47 -0500 Subject: [PATCH] Update Some Instances of "i.e." Latin Abbreviation (#19183) * Update 'i.e.' to 'in other words' * Update instance of 'in other words' to 'that is...' * Rollback i.e. updates --- content/en/docs/concepts/configuration/assign-pod-node.md | 2 +- .../en/docs/concepts/workloads/controllers/ttlafterfinished.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/concepts/configuration/assign-pod-node.md b/content/en/docs/concepts/configuration/assign-pod-node.md index 9a51a1d294..2c5becff54 100644 --- a/content/en/docs/concepts/configuration/assign-pod-node.md +++ b/content/en/docs/concepts/configuration/assign-pod-node.md @@ -186,7 +186,7 @@ not recommend using them in clusters larger than several hundred nodes. {{< /note >}} {{< note >}} -Pod anti-affinity requires nodes to be consistently labelled, i.e. every node in the cluster must have an appropriate label matching `topologyKey`. If some or all nodes are missing the specified `topologyKey` label, it can lead to unintended behavior. +Pod anti-affinity requires nodes to be consistently labelled, in other words every node in the cluster must have an appropriate label matching `topologyKey`. If some or all nodes are missing the specified `topologyKey` label, it can lead to unintended behavior. {{< /note >}} As with node affinity, there are currently two types of pod affinity and anti-affinity, called `requiredDuringSchedulingIgnoredDuringExecution` and diff --git a/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md index 5547a977eb..c5b88198f4 100644 --- a/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -36,7 +36,7 @@ up finished Jobs (either `Complete` or `Failed`) automatically by specifying the [example](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically). The TTL controller will assume that a resource is eligible to be cleaned up TTL seconds after the resource has finished, in other words, when the TTL has expired. When the -TTL controller cleans up a resource, it will delete it cascadingly, i.e. delete +TTL controller cleans up a resource, it will delete it cascadingly, that is to say it will delete its dependent objects together with it. Note that when the resource is deleted, its lifecycle guarantees, such as finalizers, will be honored.