cleanup, formatting and styling of volumes concept #24077

kbhawkey · 2020-09-23T18:35:22Z

Updated styling of resources, fields, interfaces, drivers, plugins, field names.
Still questions about the styling and capitalization of "Pod", "pod", Pod. Is it possible for readers to switch between
the different formats in a sentence. What about "container" and "Container". Are there fuzzy areas where both formats could be used?
General cleanup. Some content is repeated for each volume type. Tried to make this content consistent.
Removed in-page table of contents. Table of contents is part of the page layout (right hand TOC).
Fixes issue Sidebar on Volumes page missing entries #24409 .
[Preview]

kbhawkey · 2020-09-23T18:44:13Z

Related to updating the style guide.
See issues #20862, #23527.

netlify · 2020-09-23T18:46:45Z

Deploy preview for kubernetes-io-master-staging ready!

Built with commit 3f5d599

https://deploy-preview-24077--kubernetes-io-master-staging.netlify.app

kbhawkey · 2020-09-23T19:02:18Z

Page preview:
https://deploy-preview-24077--kubernetes-io-master-staging.netlify.app/docs/concepts/storage/volumes/

tengqm

Thanks for this effort.

When reviewing the PR, I was feeling more and more impatient. It is boring, tedious task. Maybe you have the same feelings as well when revising this and then proposing this change.

Currently we got 3 options:

Pod, Container, secretRef, volume -- This capitalization is a strict requirement, whenever we refer to a resource type, its field names or command line flags etc. We'd better use coding style for them for visual differentiation.
Pod, Container, Secret, Deployment -- we still see these spelling styles everywhere.
pod, container, secret, deployment -- this is everywhere as well.

It would be a huge pain if an author/reviewer has to switch between three styles, no matter what kinds of guidelines we put there. Maybe we should drop one of these styles.

Option 1 is required for document accuracy, we have to keep it. Between option 2 and 3, I'd vote for option 2 because option 3 is obviously causing a lot of misunderstandings, e.g. "sharing a secret", "scale a deployment".

content/en/docs/concepts/storage/volumes.md

tengqm · 2020-09-24T00:58:23Z

content/en/docs/concepts/storage/volumes.md

+crashes, the files in the container are lost. The kubelet restarts the container
+but with a clean state. Second, when running containers together
+in a pod it is often necessary to share files between those containers. The
+Kubernetes volume abstraction solves both of these problems.


I agree to this change. "volume abstraction" is generic enough and cause no ambiguity in this context. Also we are not yet touching the Volume resource type in this paragragh.

tengqm · 2020-09-24T01:01:19Z

content/en/docs/concepts/storage/volumes.md

+image and volumes. The [Docker image](https://docs.docker.com/userguide/dockerimages/)
+is at the root of the filesystem hierarchy. Volumes mount at the specified paths within
+the image. Volumes can not mount onto other volumes or have hard links to
+other volumes. Each container in the pod must independently specify where to


Maybe we should say "Each Container in the Pod must ...` because we are talking about the resource again.

Do you think this is referring to the Kubernetes Container resource or containers in general?

I'd write container lowercase. Even if this is primarily describing a field inside a Pod spec, container is lowercased there as well.

I agree that this is sentence is confusing. I've gone over this a few times.
I will update and capitalize as a resource because the sentence is describing how to "specify" the Container and Pod objects.
I also agree that the name of the field is called container but if this styling is used I would update the sentence to identify the "field to set".

content/en/docs/concepts/storage/volumes.md

tengqm · 2020-09-24T01:06:26Z

content/en/docs/concepts/storage/volumes.md

      fsType: ext4
 ```

-#### CSI Migration
+#### CSIMigrationAWS


I don't agree to this change, although CSIMigrationAWS is the name of a feature gate. Using camel case in (sub)titles looks weird to me. The title should be a phrase or sub-sentence IMHO.
If the intent is to make sure each (sub)title has a unique anchor, we may want to put #### CSI Migration {#csi-migration-aws} instead.

Yes, I agree with you. I need to look at the the text that follows and make sure the feature gate name
is referenced (feature gate page). There should be unique headings for each section.

I changed the headings. Let me know what you think. Thanks.

How are the headings now?

content/en/docs/concepts/storage/volumes.md

tengqm · 2020-09-24T01:28:53Z

content/en/docs/concepts/storage/volumes.md

 It mounts a directory and writes the requested data in plain text files.

 {{< note >}}
-A Container using Downward API as a [subPath](#using-subpath) volume mount will not
+A container using Downward API as a [`subPath`](#using-subpath) volume mount will not
 receive Downward API updates.


"Downward API" should be "downward".
If we use "Downward API", we may need to provide a glossary for it?

Yes, this needs more cleanup.

I changed this. Not sure if correct.
downwardAPI is a field and DownwardAPIVolumeSource is a resource.

tengqm · 2020-09-24T01:30:48Z

content/en/docs/concepts/storage/volumes.md

 any reason, the data in the `emptyDir` is deleted forever.

 {{< note >}}
-A Container crashing does *NOT* remove a Pod from a node, so the data in an `emptyDir` volume is safe across Container crashes.
+A Container crashing does *NOT* remove a Pod from a node, so the data in an `emptyDir` volume is safe across container crashes.


Suggested change

A Container crashing does *NOT* remove a Pod from a node, so the data in an `emptyDir` volume is safe across container crashes.

A container crashing does *NOT* remove a pod from a node, so the data in an `emptyDir` volume is safe across container crashes.

content/en/docs/concepts/storage/volumes.md

tengqm · 2020-09-24T01:32:03Z

content/en/docs/concepts/storage/volumes.md

@@ -398,8 +394,8 @@ See the [Flocker example](https://github.com/kubernetes/examples/tree/{{< param
 ### gcePersistentDisk {#gcepersistentdisk}

 A `gcePersistentDisk` volume mounts a Google Compute Engine (GCE)
-[Persistent Disk](https://cloud.google.com/compute/docs/disks) into your Pod.  Unlike
-`emptyDir`, which is erased when a Pod is removed, the contents of a PD are
+[persistent disk](https://cloud.google.com/compute/docs/disks)(PD) into your Pod.


kbhawkey · 2020-09-27T19:42:12Z

content/en/docs/concepts/storage/volumes.md

+[EBS volume](https://aws.amazon.com/ebs/) into your pod. Unlike
+`emptyDir`, which is erased when a pod is removed, the contents of an EBS
+volume are preserved and the volume is merely unmounted. This means that an
+EBS volume can be pre-populated with data, and that data can be transferred between pods.


Changed "handed off" to transferred. Is this an accurate change?

This is mainly about letting a replacement Pod pick up where a previous Pod left off, but you could use it for other patterns (eg a Job that does some work and then triggers a single-pod Deployment that will use the same EBS volume).

Yes. My goal is to come up with a replacement phrase for "handed off".

shared? or used?

OK. I will change to "shared". This phrase is used throughout the page.

kbhawkey · 2020-09-27T19:59:34Z

/cc @kubernetes/sig-storage-pr-reviews

wabernat · 2020-10-02T22:22:03Z

@tengqm :

Between option 2 and 3, I'd vote for option 2 because option 3 is obviously causing a lot of misunderstandings,
e.g. "sharing a secret", "scale a deployment".

If the project persists in capitalizing words in apparent contravention to conventional English usage, there will continue to be confusion and misunderstanding on this point.

Fundamentally, we are trying to solve with typography what would be better addressed with plain language. As discussed in issue #20862, there is a short list of Pascal-cased terms (Pod, Container, Secret, etc.) that are very difficult to interpret as being proper vs. common nouns. This makes it very difficult for editors such as myself, who are not experts in Kubernetes, to make the distinction between a correctly capitalized resource name and an erroneously capitalized common noun. This problem will not go away by requesting people to capitalize by default.

The only reliable solution to the capitalization problem for single-word Pascal-cased resources is to identify the resource in running text, which is expressly forbidden in the Kubernetes style guide . To make the distinction clear, writers must be allowed to identify resource names as resource names by declaring the resource's type in running text. I can easily tell the difference between a Container resource vs. any old container if the word "resource" (or object) is permitted after the word "Container." Precluded from having this important context, I cannot tell a Container from a container or a Pod from a pod. Until ground down or driven mad, most editors will flag such uses for clarification (wasting time) or simply "correct" the problem, thus eliminating the desired distinction.

kbhawkey · 2020-10-03T00:01:18Z

Hi @wabernatScality . Thanks for your feedback.
In summary, you are suggesting that if a resource name is included in text that the noun "resource" or "object" must always follow the resource name. For example:
Create a Secret resource.
Create a Pod object.

Not:
Create a PersistentVolumeClaim.
Set the environment variables in the ConfigMap.
The Secret has two fields.

I think there is ambiguity writing "pod" versus "Pod": "pod" representing general usage (what are the common examples?) and "Pod" representing state of an object (creating, running, lifecycle, destroying, has containers, has spec, status ...).

wabernat · 2020-10-03T00:37:24Z

I am proposing that the style guide not enjoin writers in its examples from adding a resource identifier after a proper-named resource, particularly when the proper name is a single-word Pascal-cased name. Because PersistentVolumeClaim, for example, is unambiguously in Pascal case, there's no need to follow it with an identifying noun, and the existing rule makes some sense. However, when the object is a Pascal-cased word with no unusual capitalization inside the word (e.g., "Pod," "Job," "Secret," etc.) following the Pascal-cased word with the resource type becomes an essential aid to the reader and the editor to disambiguate the term.

In precis, I am proposing: a) lifting the style guide's explicit prohibition on identifying named resources by type, and b) suggesting that writers actively use such identifiers when documenting "ambiguously Pascal-cased" single-word resources to make it clear that the capitalization is for a named resource.

kbhawkey · 2020-10-03T01:12:13Z

Pod, Job, Container, ReplicaSet, Node, PersistentVolumeClaim, Event, Secret, Ingress, Volume, Deployment, ... are some of the k8s resources.
I think using lowercase and uppercase of terms such as "node", "pod", "volume" (in a single page) can be problematic for authors and readers and possibly more difficult to interpret for localization teams.

wabernat · 2020-10-03T21:03:56Z

I addressed the issue of localization with Tim in issue #20862. Clear English should not be an issue for translators. The problem I have with monolithically capitalizing resource terms without sensitivity to context is that it substitutes one confusion for another and does not bring your readers clarity. I would not describe a Container of nuts in the desk at my Job that I keep Secret from my boss, because those are not Kubernetes resources. Your writing needs to admit of the possibility of proper and common nouns for unique and non-unique objects. The reason I'm asking you to consider this change is so that as an editor I can spot the difference between, for example, a cron job and a Job resource, or a Secret object and a secret key. Capitalization alone does not enable either me or a lay reader to distinguish these items if they are not followed by an explicit descriptor.

sftim

This is a big page to tackle, so 🎉 kudos 🎉 for cracking on here @kbhawkey

There's a bit of a discrepancy between CSI (the English abbreviation for “Container Storage Interface”) vs csi (the volume type for using a CSI driver in a Pod). It's a similar story with FlexVolume vs flexVolume.

That's something I recommend fixing.

I've also added over sixty bits of inline feedback that are quite a bit less important, some explicitly marked as nits. I'm absolutely fine with moving this PR forward without dealing with those less-vital details; I mentioned what I spotted and added my thoughts anyway in case that's useful.

content/en/docs/concepts/storage/volumes.md

sftim · 2020-10-03T22:10:46Z

content/en/docs/concepts/storage/volumes.md

 drivers, but the functionality is very limited for now (e.g. as of Docker 1.7
-only one volume driver is allowed per Container and there is no way to pass
+only one volume driver is allowed per container and there is no way to pass
 parameters to volumes).


This also feels out of date. Fine to fix that in a different PR - this PR is focused on formatting fixes.

Yes, I wanted to remove this but left in place. Hope someone from Storage would agree to remove or update.

content/en/docs/concepts/storage/volumes.md

sftim · 2020-10-03T23:11:31Z

content/en/docs/concepts/storage/volumes.md


-Pods interact with FlexVolume drivers through the `flexvolume` in-tree plugin.
-More details can be found [here](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md).
+Pods interact with `FlexVolume` drivers through the `flexvolume` in-tree plugin.


Suggested change

Pods interact with `FlexVolume` drivers through the `flexvolume` in-tree plugin.

Pods interact with FlexVolume drivers through the `flexVolume` in-tree volume type.

sftim · 2020-10-03T23:12:32Z

content/en/docs/concepts/storage/volumes.md

-   volume mounts anything there, the Container with `HostToContainer` mount
-   propagation will see it.
+  Similarly, if any Pod with `Bidirectional` mount propagation to the same
+  volume mounts anything there, the `Container` with `HostToContainer` mount


I'd write:

Suggested change

volume mounts anything there, the `Container` with `HostToContainer` mount

volume mounts anything there, the container with `HostToContainer` mount

or: container

sftim · 2020-10-03T23:13:45Z

content/en/docs/concepts/storage/volumes.md


-   A typical use case for this mode is a Pod with a FlexVolume or CSI driver or
-   a Pod that needs to mount something on the host using a `hostPath` volume.
+  A typical use case for this mode is a Pod with a `FlexVolume` or `CSI` driver or


I'd put:

Suggested change

A typical use case for this mode is a Pod with a `FlexVolume` or `CSI` driver or

A typical use case for this mode is a Pod using a `flexVolume` or `csi` volume, or

sftim · 2020-10-03T23:14:17Z

content/en/docs/concepts/storage/volumes.md

+  {{< caution >}}
+  `Bidirectional` mount propagation can be dangerous. It can damage
+  the host operating system and therefore it is allowed only in privileged
+  containers. Familiarity with Linux kernel behavior is strongly recommended.
+  In addition, any volume mounts created by containers in pods must be destroyed
+  (unmounted) by the containers on termination.
+  {{< /caution >}}


This might merit a {{< warning >}}. (OK to save that tweak for a later PR).

sftim · 2020-10-03T23:19:52Z

In terms of what capitalization style to apply: follow the style guide if you can't decide. If you can decide then let's go with that, feel free to add a note to reviewers if you think it might not be obvious why you've selected an approach.

Whilst that style guide is very much a living document, this PR is not the place to discuss revisions to the style guide.

wabernat · 2020-10-04T17:25:05Z

I apologize for the thread-jack.

bradtopol · 2020-10-06T23:01:23Z

/assign @sftim

sftim · 2020-10-07T11:44:03Z

LGTM
Not sure if this needs tech review - @kbhawkey, if you believe it does not then I will be happy to add /lgtm as well.

sftim · 2020-10-07T18:13:07Z

Also relevant to issue #4503

kbhawkey · 2020-10-07T18:17:48Z

LGTM
Not sure if this needs tech review - @kbhawkey, if you believe it does not then I will be happy to add /lgtm as well.

Possibly. I will ping Sig Storage.
/cc @kubernetes/sig-storage-pr-reviews

I'd like to start a conversation about the style guide and capitalization, based on the conversation in https://github.com/kubernetes/website/pull/24077/files, Specifically, [this comment](kubernetes#24077 (comment)) from @wabernatScality . Currently, the style guide explicitly prohibits usage of "object" -- such as "Pod object" or "PodList object" Judicious use of "object" could improve clarity. It's a hint to the reader that the distinction of being an API object is important. Right now, the guidelines are overly reliant on capitalization to allow readers to make that distinction. Capitalization is a weak way to signal information to the reader. This information may be lost entirely due to assistive technology, differences in visual abilities, or translation. I look forward to the feedback :)

msau42 · 2020-10-23T01:14:51Z

content/en/docs/concepts/storage/volumes.md

+drivers, but the functionality is somewhat limited.
+
+Kubernetes supports many types of volumes. A {{< glossary_tooltip term_id="pod" text="Pod" >}}
+can use any number of volume types simultaneously. The lifetime of a Kubernetes volume


The note about volume lifetime is not correct. Ephemeral volume types have a lifetime of a pod, but persistent volumes have a lifetime beyond the pod.

Hi @msau42 .
Thanks for the feedback. Initially, I created this PR to clean up the formatting and styling
of the page content. I was also experimenting with adapting some new docs style guidelines.
I went a bit further by modifying some of the text (grammar, readability), but
did not delve too deeply into the content. I'll look again at the page and see if I can make more content changes
otherwise, I can log an issue to review the page in more detail. How does that sound?

Let me see if I can updated correctly.

Do you think it is still relevant to include the paragraph about Docker volumes (as a comparison)?

I think leaving content updates to a future pr is fine. I think the Docker volumes comparison may need to be updated as well. The biggest difference I think that's relevant is Docker volumes write data to the host and do not persist if the pod is restarted on a different node.

msau42 · 2020-10-23T01:16:54Z

content/en/docs/concepts/storage/volumes.md

-We welcome additional contributions.
+## Types of Volumes {#volume-types}
+
+Kubernetes supports several types of volumes.


is there another place we can see the TOC? I think it's convenient to have a condensed list of all the plugins up front and be able to skip to the relevant detailed section depending on what you're interested in

Yes, the TOC for the page (which gets automatically generated from the headings)
is located in the right hand side of the page. The in-page table of contents should contain
each plugin. Is this change okay?

yes thanks for explaining!

msau42 · 2020-10-23T01:17:37Z

content/en/docs/concepts/storage/volumes.md

+[EBS volume](https://aws.amazon.com/ebs/) into your pod. Unlike
+`emptyDir`, which is erased when a pod is removed, the contents of an EBS
+volume are preserved and the volume is merely unmounted. This means that an
+EBS volume can be pre-populated with data, and that data can be transferred between pods.


shared? or used?

msau42 · 2020-10-23T01:18:45Z

content/en/docs/concepts/storage/volumes.md

+An `awsElasticBlockStore` volume mounts an Amazon Web Services (AWS)
+[EBS volume](https://aws.amazon.com/ebs/) into your pod. Unlike
+`emptyDir`, which is erased when a pod is removed, the contents of an EBS
+volume are preserved and the volume is merely unmounted. This means that an


maybe instead of preserved, use persisted, to reflect our persistentvolumes concept

OK. I will change. I did not attempt to change the description for each plugin.

msau42 · 2020-10-23T01:20:36Z

content/en/docs/concepts/storage/volumes.md


 {{< feature-state for_k8s_version="v1.17" state="beta" >}}

-The CSI Migration feature for awsElasticBlockStore, when enabled, shims all plugin operations
+The `CSIMigration` feature for `awsElasticBlockStore`, when enabled, shims all plugin operations


do you think "shims" is a clear word to describe this? or would something like "route" or "redirects" be more descriptive?

No, not really. I think the docs could be improved here.

I updated the use of "shim" in the page. PTAL.

msau42 · 2020-10-23T01:23:16Z

content/en/docs/concepts/storage/volumes.md

 {{< feature-state for_k8s_version="v1.17" state="alpha" >}}

-To turn off the awsElasticBlockStore storage plugin from being loaded by controller manager and kubelet, you need to set this feature flag to true. This requires `ebs.csi.aws.com` Container Storage Interface (CSI) driver being installed on all worker nodes.
+To disable the `awsElasticBlockStore` storage plugin from being loaded by the controller manager
+and the kubelet, set the `CSIMigrationAWSComplete` flag to `true`. This feature requires the `ebs.csi.aws.com` Container Storage Interface (CSI) driver installed on all worker nodes.

 ### azureDisk {#azuredisk}


the doc seems to be inconsistent about which volume types are persistent and which are ephemeral. Would it be more clear if we broke up this list of volume types into two sections, ephemeral and persistent?

content/en/docs/concepts/storage/volumes.md

msau42 · 2020-10-23T01:33:22Z

content/en/docs/concepts/storage/volumes.md

-For more information on how to develop a CSI driver, refer to the [kubernetes-csi
-documentation](https://kubernetes-csi.github.io/docs/)
+For more information on how to develop a CSI driver, refer to the
+[kubernetes-csi documentation](https://kubernetes-csi.github.io/docs/)

 #### Migrating to CSI drivers from in-tree plugins

 {{< feature-state for_k8s_version="v1.14" state="alpha" >}}


this has been beta since 1.17

OK. I will update.

sftim · 2020-10-26T17:08:38Z

For the content changes, I'd be happy (and prefer) to put corrections into a separate PR. If there are no regressions then this should be OK to merge.

sftim · 2020-10-26T17:09:34Z

@kbhawkey it sounds as if (once rebased) this is basically good-to-go.

kbhawkey · 2020-10-26T18:07:04Z

@kbhawkey it sounds as if (once rebased) this is basically good-to-go.
Yes, it is close. I'd rather wait to hear back from @msau.

msau42 · 2020-10-26T22:28:48Z

/lgtm

Thanks for working on this!

k8s-ci-robot · 2020-10-26T22:29:02Z

LGTM label has been added.

Git tree hash: a31348a6d26d06dd7d2460e89ad68d09a0ac0823

sftim · 2020-10-26T22:29:50Z

/approve

Nice one @kbhawkey

k8s-ci-robot · 2020-10-26T22:30:08Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sftim

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~content/en/OWNERS~~ [sftim]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Sep 23, 2020

k8s-ci-robot requested review from jsafrane and saad-ali September 23, 2020 18:35

k8s-ci-robot added the sig/docs Categorizes an issue or PR as relevant to SIG Docs. label Sep 23, 2020

kbhawkey force-pushed the kb-cleanup-eval-style branch from 75bade6 to 1deb0a3 Compare September 23, 2020 21:22

kbhawkey changed the title ~~testing styling of resources, plugins, drivers~~ [wip]testing styling of resources, plugins, drivers Sep 23, 2020

k8s-ci-robot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Sep 23, 2020

tengqm reviewed Sep 24, 2020

View reviewed changes

kbhawkey force-pushed the kb-cleanup-eval-style branch from 1deb0a3 to 12353df Compare September 24, 2020 19:43

k8s-ci-robot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Sep 24, 2020

kbhawkey force-pushed the kb-cleanup-eval-style branch 2 times, most recently from a3becc5 to ae178a4 Compare September 27, 2020 19:36

kbhawkey commented Sep 27, 2020

View reviewed changes

kbhawkey changed the title ~~[wip]testing styling of resources, plugins, drivers~~ cleanup, formatting and styling of volumes concept Sep 27, 2020

k8s-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Sep 27, 2020

k8s-ci-robot added the sig/storage Categorizes an issue or PR as relevant to SIG Storage. label Sep 27, 2020

sftim reviewed Oct 3, 2020

View reviewed changes

k8s-ci-robot assigned sftim Oct 6, 2020

kbhawkey mentioned this pull request Oct 7, 2020

Sidebar on Volumes page missing entries #24409

Closed

kbhawkey mentioned this pull request Oct 15, 2020

Reorganize Volumes Page for Readability #24574

Closed

geoffcline mentioned this pull request Oct 19, 2020

revise style guidelines for capitalization #24645

Merged

msau42 reviewed Oct 23, 2020

View reviewed changes

k8s-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 23, 2020

testing styling of resources, plugins, drivers

3f5d599

kbhawkey force-pushed the kb-cleanup-eval-style branch from 5bd7c73 to 3f5d599 Compare October 26, 2020 18:06

k8s-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 26, 2020

kbhawkey mentioned this pull request Oct 26, 2020

Create two umbrella sections (persistent, ephemeral) for volume concept page #24726

Closed

k8s-ci-robot assigned msau42 Oct 26, 2020

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Oct 26, 2020

k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 26, 2020

k8s-ci-robot merged commit baf9e18 into kubernetes:master Oct 26, 2020

kbhawkey deleted the kb-cleanup-eval-style branch October 27, 2020 17:37

kbhawkey mentioned this pull request Oct 29, 2020

fix CSIMigration feature state #24779

Merged

sftim mentioned this pull request Oct 31, 2020

Migration task steps woven into volume concept page #22521

Closed

	A Container crashing does NOT remove a Pod from a node, so the data in an `emptyDir` volume is safe across container crashes.
	A container crashing does NOT remove a pod from a node, so the data in an `emptyDir` volume is safe across container crashes.

	Pods interact with `FlexVolume` drivers through the `flexvolume` in-tree plugin.
	Pods interact with FlexVolume drivers through the `flexVolume` in-tree volume type.

	volume mounts anything there, the `Container` with `HostToContainer` mount
	volume mounts anything there, the container with `HostToContainer` mount

	A typical use case for this mode is a Pod with a `FlexVolume` or `CSI` driver or
	A typical use case for this mode is a Pod using a `flexVolume` or `csi` volume, or

cleanup, formatting and styling of volumes concept #24077

cleanup, formatting and styling of volumes concept #24077

Conversation

kbhawkey commented Sep 23, 2020 • edited Loading

kbhawkey commented Sep 23, 2020

netlify bot commented Sep 23, 2020 • edited Loading

kbhawkey commented Sep 23, 2020

tengqm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kbhawkey Sep 27, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kbhawkey commented Sep 27, 2020

wabernat commented Oct 2, 2020

kbhawkey commented Oct 3, 2020 • edited Loading

wabernat commented Oct 3, 2020

kbhawkey commented Oct 3, 2020

wabernat commented Oct 3, 2020

sftim left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sftim commented Oct 3, 2020

wabernat commented Oct 4, 2020

bradtopol commented Oct 6, 2020

sftim commented Oct 7, 2020

sftim commented Oct 7, 2020

kbhawkey commented Oct 7, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sftim commented Oct 26, 2020

sftim commented Oct 26, 2020

kbhawkey commented Oct 26, 2020

msau42 commented Oct 26, 2020

k8s-ci-robot commented Oct 26, 2020

sftim commented Oct 26, 2020

k8s-ci-robot commented Oct 26, 2020

kbhawkey commented Sep 23, 2020 •

edited

Loading

netlify bot commented Sep 23, 2020 •

edited

Loading

kbhawkey Sep 27, 2020 •

edited

Loading

kbhawkey commented Oct 3, 2020 •

edited

Loading