Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OCPBUGS-10640-13: 4.13 Added clarification point to disk partition BM… #73361

Merged
merged 1 commit into from
Mar 22, 2024
Merged

OCPBUGS-10640-13: 4.13 Added clarification point to disk partition BM… #73361

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 17 additions & 14 deletions modules/installation-user-infra-machines-advanced.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -67,31 +67,34 @@ The `--copy-network` option only copies networking configuration found under `/e
[id="installation-user-infra-machines-advanced_disk_{context}"]
== Disk partitioning

// This content is not modularized, so any updates to this "Disk partitioning" section should be checked against the module created for vSphere UPI parity in the module file named `installation-disk-partitioning.adoc` for consistency until such time as this large assembly can be modularized.
The disk partitions are created on {product-title} cluster nodes during the {op-system-first} installation. Each {op-system} node of a particular architecture uses the same partition layout, unless the default partitioning configuration is overridden.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The disk partitions are created on {product-title} cluster nodes during the {op-system-first} installation. Each {op-system} node of a particular architecture uses the same partition layout, unless the default partitioning configuration is overridden.
Disk partitions are created on {product-title} cluster nodes during the {op-system-first} installation. Each {op-system} node of a particular architecture uses the same partition layout, unless you override the default partitioning configuration.
  • Omit definite article. It doesn't look you're referring back to specific partitions here.
  • Avoid passive voice.


The disk partitions are created on {product-title} cluster nodes during the {op-system-first} installation. Each {op-system} node of a particular architecture uses the same partition layout, unless the default partitioning configuration is overridden. During the {op-system} installation, the size of the root file system is increased to use the remaining available space on the target device.
During the {op-system} installation, the size of the root file system is increased to use the remaining available space on the target device.

There are two cases where you might want to override the default partitioning when installing {op-system} on an {product-title} cluster node:

* Creating separate partitions: For greenfield installations on an empty
disk, you might want to add separate storage to a partition. This is
officially supported for mounting `/var` or a subdirectory of `/var`, such as `/var/lib/etcd`, on a separate partition, but not both.
+
[IMPORTANT]
====
For disk sizes larger than 100GB, and especially disk sizes larger than 1TB, create a separate `/var` partition. See "Creating a separate `/var` partition" and this link:https://access.redhat.com/solutions/5587281[Red Hat Knowledgebase article] for more information.
The use of a custom partition scheme on your node could result in {product-title} not monitoring or alerting on some node partitions. If you are overriding the default partitioning, see link:https://access.redhat.com/articles/4766521[Understanding OpenShift File System Monitoring (eviction conditions)] for more information about how {product-title} monitors your host file systems.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The use of a custom partition scheme on your node could result in {product-title} not monitoring or alerting on some node partitions. If you are overriding the default partitioning, see link:https://access.redhat.com/articles/4766521[Understanding OpenShift File System Monitoring (eviction conditions)] for more information about how {product-title} monitors your host file systems.
The use of a custom partition scheme on your node might result in {product-title} not monitoring or alerting on some node partitions. If you are overriding the default partitioning, see link:https://access.redhat.com/articles/4766521[Understanding OpenShift File System Monitoring (eviction conditions)] for more information about how {product-title} monitors your host file systems.

Per the ISG, don't use could "in the present tense to mean might or can".

====
+

{product-title} monitors the following two filesystem identifiers:

* `nodefs`, which is the filesystem that contains `/var/lib/kubelet`
* `imagefs`, which is the filesystem that contains `/var/lib/containers`

For the default partition scheme, `nodefs` and `imagefs` monitor the same root filesystem, `/`.

If you want to override the default partitioning when installing {op-system} on an {product-title} cluster node, you must create separate partitions.

[IMPORTANT]
====
Kubernetes supports only two file system partitions. If you add more than one partition to the original configuration, Kubernetes cannot monitor all of them.
For disk sizes larger than 100GB, and especially disk sizes larger than 1TB, create a separate `/var` partition. See "Creating a separate `/var` partition" and this link:https://access.redhat.com/solutions/5587281[Red Hat Knowledgebase article] for more information.
====

* Retaining existing partitions: For a brownfield installation where you are reinstalling {product-title} on an existing node and want to retain data partitions installed from your previous operating system, there are both boot arguments and options to `coreos-installer` that allow you to retain existing data partitions.
You might want to add a separate storage partition for your containers and container images. For example, by mounting `/var/lib/containers` in a separate partition, the kubelet separately monitor `/var/lib/containers` as the `imagefs` directory and the root file system as the `nodefs` directory.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
You might want to add a separate storage partition for your containers and container images. For example, by mounting `/var/lib/containers` in a separate partition, the kubelet separately monitor `/var/lib/containers` as the `imagefs` directory and the root file system as the `nodefs` directory.
[In situations such as...], you might want to add a separate storage partition for your containers and container images. For example, by mounting `/var/lib/containers` in a separate partition, the kubelet separately monitors `/var/lib/containers` as the `imagefs` directory and the root file system as the `nodefs` directory.
  • I'd suggest adding a clause at the beginning for this sentence to add clarification about when a user might want to add a separate storage partition. I think it'd be good for users to know when doing so would be useful.
  • Fix subject-verb disagreement typo.


[WARNING]
[IMPORTANT]
====
The use of custom partitions could result in those partitions not being monitored by {product-title} or alerted on. If you are overriding the default partitioning, see link:https://access.redhat.com/articles/4766521[Understanding OpenShift File System Monitoring (eviction conditions)] for more information about how {product-title} monitors your host file systems.
If you resized your disk size to host a larger file system, consider creating a separate `/var/lib/containers` partition. This is important for a disk formatted to `xfs`, where a high number of allocation groups might cause CPU time issues.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
If you resized your disk size to host a larger file system, consider creating a separate `/var/lib/containers` partition. This is important for a disk formatted to `xfs`, where a high number of allocation groups might cause CPU time issues.
If you have resized your disk size to host a larger file system, consider creating a separate `/var/lib/containers` partition. This is important for a disk formatted to `xfs`, where a high number of allocation groups might cause CPU time issues.
  • Adding a present participle indicates more clearly that you're talking about a present situation, imo. WDYT?
  • Per the ISG avoid ambiguous pronoun references; what does "This" refer to? Try to rephrase the last sentence to avoid a "this is" construction at all (see the ISG word usage guidance for "there is, there are" for an example.

====

[id="installation-user-infra-machines-advanced_vardisk_{context}"]
Expand Down