diff --git a/Documentation/CRDs/Cluster/ceph-cluster-crd.md b/Documentation/CRDs/Cluster/ceph-cluster-crd.md index 5182e959d..325ceddbc 100755 --- a/Documentation/CRDs/Cluster/ceph-cluster-crd.md +++ b/Documentation/CRDs/Cluster/ceph-cluster-crd.md @@ -48,8 +48,8 @@ If this value is empty, each pod will get an ephemeral directory to store their * `externalMgrPrometheusPort`: external prometheus manager module port. See [external cluster configuration](#external-cluster) for more details. * `rulesNamespace`: Namespace to deploy prometheusRule. If empty, namespace of the cluster will be used. Recommended: - * If you have a single Rook Ceph cluster, set the `rulesNamespace` to the same namespace as the cluster or keep it empty. - * If you have multiple Rook Ceph clusters in the same Kubernetes cluster, choose the same namespace to set `rulesNamespace` for all the clusters (ideally, namespace with prometheus deployed). Otherwise, you will get duplicate alerts with duplicate alert definitions. + * If you have a single Rook cluster, set the `rulesNamespace` to the same namespace as the cluster or keep it empty. + * If you have multiple Rook clusters in the same Kubernetes cluster, choose the same namespace to set `rulesNamespace` for all the clusters (ideally, namespace with prometheus deployed). Otherwise, you will get duplicate alerts with duplicate alert definitions. * `network`: For the network settings for the cluster, refer to the [network configuration settings](#network-configuration-settings) * `mon`: contains mon related options [mon settings](#mon-settings) For more details on the mons and when to choose a number other than `3`, see the [mon health doc](../../Storage-Configuration/Advanced/ceph-mon-health.md). @@ -231,7 +231,7 @@ Based on the configuration, the operator will do the following: \* Internal cluster traffic includes OSD heartbeats, data replication, and data recovery Only OSD pods will have both Public and Cluster networks attached. The rest of the Ceph component pods and CSI pods will only have the Public network attached. -Rook Ceph Operator will not have any networks attached as it proxies the required commands via a sidecar container in the mgr pod. +Rook Ceph operator will not have any networks attached as it proxies the required commands via a sidecar container in the mgr pod. In order to work, each selector value must match a `NetworkAttachmentDefinition` object name in Multus. @@ -303,7 +303,7 @@ Nodes are removed from Ceph as OSD hosts only (1) if the node is deleted from Ku (2) if the node has its taints or affinities modified in such a way that the node is no longer usable by Rook. Any changes to taints or affinities, intentional or unintentional, may affect the data reliability of the Ceph cluster. In order to help protect against this somewhat, deletion of -nodes by taint or affinity modifications must be "confirmed" by deleting the Rook-Ceph operator pod +nodes by taint or affinity modifications must be "confirmed" by deleting the Rook Ceph operator pod and allowing the operator deployment to restart the pod. For production clusters, we recommend that `useAllNodes` is set to `false` to prevent the Ceph @@ -578,7 +578,7 @@ The specific component keys will act as overrides to `all`. ### Health settings -Rook-Ceph will monitor the state of the CephCluster on various components by default. +The Rook Ceph operator will monitor the state of the CephCluster on various components by default. The following CRD settings are available: * `healthCheck`: main ceph cluster health monitoring section @@ -792,13 +792,13 @@ racks in the data center setup. ## Deleting a CephCluster During deletion of a CephCluster resource, Rook protects against accidental or premature destruction -of user data by blocking deletion if there are any other Rook-Ceph Custom Resources that reference +of user data by blocking deletion if there are any other Rook Ceph Custom Resources that reference the CephCluster being deleted. Rook will warn about which other resources are blocking deletion in three ways until all blocking resources are deleted: 1. An event will be registered on the CephCluster resource 1. A status condition will be added to the CephCluster resource -1. An error will be added to the Rook-Ceph Operator log +1. An error will be added to the Rook Ceph operator log ## Cleanup policy @@ -807,17 +807,17 @@ The policy settings indicate which data should be forcibly deleted and in what w The `cleanupPolicy` has several fields: * `confirmation`: Only an empty string and `yes-really-destroy-data` are valid values for this field. - If this setting is empty, the cleanupPolicy settings will be ignored and Rook will not cleanup any resources during cluster removal. + If this setting is empty, the `cleanupPolicy` settings will be ignored and Rook will not cleanup any resources during cluster removal. To reinstall the cluster, the admin would then be required to follow the [cleanup guide](../../Storage-Configuration/ceph-teardown.md) to delete the data on hosts. If this setting is `yes-really-destroy-data`, the operator will automatically delete the data on hosts. Because this cleanup policy is destructive, after the confirmation is set to `yes-really-destroy-data` Rook will stop configuring the cluster as if the cluster is about to be destroyed. * `sanitizeDisks`: sanitizeDisks represents advanced settings that can be used to delete data on drives. - * `method`: indicates if the entire disk should be sanitized or simply ceph's metadata. Possible choices are 'quick' (default) or 'complete' - * `dataSource`: indicate where to get random bytes from to write on the disk. Possible choices are 'zero' (default) or 'random'. + * `method`: indicates if the entire disk should be sanitized or simply ceph's metadata. Possible choices are `quick` (default) or `complete` + * `dataSource`: indicate where to get random bytes from to write on the disk. Possible choices are `zero` (default) or `random`. Using random sources will consume entropy from the system and will take much more time then the zero source * `iteration`: overwrite N times instead of the default (1). Takes an integer value -* `allowUninstallWithVolumes`: If set to true, then the cephCluster deletion doesn't wait for the PVCs to be deleted. Default is false. +* `allowUninstallWithVolumes`: If set to true, then the cephCluster deletion doesn't wait for the PVCs to be deleted. Default is `false`. To automate activation of the cleanup, you can use the following command. **WARNING: DATA WILL BE PERMANENTLY DELETED**: @@ -830,4 +830,4 @@ However, all new configuration by the operator will be blocked with this cleanup Rook waits for the deletion of PVs provisioned using the cephCluster before proceeding to delete the cephCluster. To force deletion of the cephCluster without waiting for the PVs to be deleted, you can -set the allowUninstallWithVolumes to true under spec.CleanupPolicy. +set the `allowUninstallWithVolumes` to true under `spec.CleanupPolicy`. diff --git a/Documentation/CRDs/Object-Storage/ceph-object-store-crd.md b/Documentation/CRDs/Object-Storage/ceph-object-store-crd.md index 59a8f67cd..f509af9ca 100644 --- a/Documentation/CRDs/Object-Storage/ceph-object-store-crd.md +++ b/Documentation/CRDs/Object-Storage/ceph-object-store-crd.md @@ -158,7 +158,7 @@ created anew. ## Health settings -Rook-Ceph will be default monitor the state of the object store endpoints. +Rook will be default monitor the state of the object store endpoints. The following CRD settings are available: * `healthCheck`: main object store health monitoring section @@ -197,7 +197,7 @@ The endpoint health check procedure is the following: 5. Verify object consistency 6. Update CR health status check -Rook-Ceph always keeps the bucket and the user for the health check, it just does a PUT and GET of an s3 object since creating a bucket is an expensive operation. +The Rook Ceph operator always keeps the bucket and the user for the health check, it just does a PUT and GET of an s3 object since creating a bucket is an expensive operation. ## Security settings @@ -259,4 +259,4 @@ Rook will warn about which buckets are blocking deletion in three ways: 1. An event will be registered on the CephObjectStore resource 1. A status condition will be added to the CephObjectStore resource -1. An error will be added to the Rook-Ceph Operator log +1. An error will be added to the Rook Ceph Operator log diff --git a/Documentation/Contributing/development-flow.md b/Documentation/Contributing/development-flow.md index cbab34ce4..004c7528e 100644 --- a/Documentation/Contributing/development-flow.md +++ b/Documentation/Contributing/development-flow.md @@ -35,7 +35,7 @@ cd rook ### Build -Building Rook-Ceph is simple. +Building Rook Ceph is simple. ```console make build diff --git a/Documentation/Storage-Configuration/Advanced/ceph-configuration.md b/Documentation/Storage-Configuration/Advanced/ceph-configuration.md index fa64f78d7..5f5496786 100644 --- a/Documentation/Storage-Configuration/Advanced/ceph-configuration.md +++ b/Documentation/Storage-Configuration/Advanced/ceph-configuration.md @@ -458,7 +458,7 @@ ceph osd tree ### To scale OSDs Vertically -Run the following script to auto-grow the size of OSDs on a PVC-based Rook-Ceph cluster whenever the OSDs have reached the storage near-full threshold. +Run the following script to auto-grow the size of OSDs on a PVC-based Rook cluster whenever the OSDs have reached the storage near-full threshold. ```console tests/scripts/auto-grow-storage.sh size --max maxSize --growth-rate percent @@ -474,7 +474,7 @@ For example, if you need to increase the size of OSD by 30% and max disk size is ### To scale OSDs Horizontally -Run the following script to auto-grow the number of OSDs on a PVC-based Rook-Ceph cluster whenever the OSDs have reached the storage near-full threshold. +Run the following script to auto-grow the number of OSDs on a PVC-based Rook cluster whenever the OSDs have reached the storage near-full threshold. ```console tests/scripts/auto-grow-storage.sh count --max maxCount --count rate diff --git a/Documentation/Storage-Configuration/Advanced/configuration.md b/Documentation/Storage-Configuration/Advanced/configuration.md index a061c2891..999d86293 100644 --- a/Documentation/Storage-Configuration/Advanced/configuration.md +++ b/Documentation/Storage-Configuration/Advanced/configuration.md @@ -53,7 +53,7 @@ on individual pools. ### Toolbox + Ceph CLI The most recommended way of configuring Ceph is to set Ceph's configuration directly. The first -method for doing so is to use Ceph's CLI from the Rook-Ceph toolbox pod. Using the toolbox pod is +method for doing so is to use Ceph's CLI from the Rook toolbox pod. Using the toolbox pod is detailed [here](../../Troubleshooting/ceph-toolbox.md). From the toolbox, the user can change Ceph configurations, enable manager modules, create users and pools, and much more. diff --git a/Documentation/Storage-Configuration/Object-Storage-RGW/object-storage.md b/Documentation/Storage-Configuration/Object-Storage-RGW/object-storage.md index 89db23216..55f491099 100644 --- a/Documentation/Storage-Configuration/Object-Storage-RGW/object-storage.md +++ b/Documentation/Storage-Configuration/Object-Storage-RGW/object-storage.md @@ -147,7 +147,7 @@ kubectl create -f storageclass-bucket-delete.yaml ``` Based on this storage class, an object client can now request a bucket by creating an Object Bucket Claim (OBC). -When the OBC is created, the Rook-Ceph bucket provisioner will create a new bucket. Notice that the OBC +When the OBC is created, the Rook bucket provisioner will create a new bucket. Notice that the OBC references the storage class that was created above. Save the following as `object-bucket-claim-delete.yaml` (the example is named as such due to the `Delete` reclaim policy): diff --git a/Documentation/Troubleshooting/ceph-common-issues.md b/Documentation/Troubleshooting/ceph-common-issues.md index c55672c37..795708327 100644 --- a/Documentation/Troubleshooting/ceph-common-issues.md +++ b/Documentation/Troubleshooting/ceph-common-issues.md @@ -667,7 +667,7 @@ as well as a second corrupted disk `/dev/sde` with one unexpected partition (`/d use `/dev/sdb` for data recovery and replication while the next OSDs are removed. 5. Now Repeat steps 1-4 for `/dev/sde` and `/dev/sde2`, and continue for any other corrupted disks. -If your Rook-Ceph cluster does not have any critical data stored in it, it may be simpler to +If your Rook cluster does not have any critical data stored in it, it may be simpler to uninstall Rook completely and redeploy with v1.6.8 or higher. ## Operator environment variables are ignored diff --git a/Documentation/Upgrade/health-verification.md b/Documentation/Upgrade/health-verification.md index 460775423..14ccba2a8 100644 --- a/Documentation/Upgrade/health-verification.md +++ b/Documentation/Upgrade/health-verification.md @@ -102,7 +102,7 @@ kubectl -n $ROOK_CLUSTER_NAMESPACE get pod -o jsonpath='{range .items[*]}{.metad The `rook-version` label exists on Ceph resources. For various resource controllers, a summary of the resource controllers can be gained with the commands below. These will report the -requested, updated, and currently available replicas for various Rook-Ceph resources in addition to +requested, updated, and currently available replicas for various Rook resources in addition to the version of Rook for resources managed by Rook. Note that the operator and toolbox deployments do not have a `rook-version` label set. diff --git a/Documentation/Upgrade/rook-upgrade.md b/Documentation/Upgrade/rook-upgrade.md index d1abdfe83..df0975815 100644 --- a/Documentation/Upgrade/rook-upgrade.md +++ b/Documentation/Upgrade/rook-upgrade.md @@ -45,7 +45,7 @@ those releases. ## Breaking changes in v1.9 -* Helm charts now define default resource requests and limits for Rook-Ceph Pods. If you use Helm, +* Helm charts now define default resource requests and limits for Rook Pods. If you use Helm, ensure you have defined an override for these in your `values.yaml` if you don't wish to use the recommended defaults. Setting resource requests and limits could mean that Kubernetes will not allow Pods to be scheduled in some cases. If sufficient resources are not available, you can @@ -100,7 +100,7 @@ kubectl apply -f common.yaml -f crds.yaml kubectl -n rook-ceph set image deploy/rook-ceph-operator rook-ceph-operator=rook/ceph:v1.9.3 ``` -As exemplified above, it is a good practice to update Rook-Ceph common resources from the example +As exemplified above, it is a good practice to update Rook common resources from the example manifests before any update. The common resources and CRDs might not be updated with every release, but K8s will only apply updates to the ones that changed. @@ -152,7 +152,7 @@ export ROOK_CLUSTER_NAMESPACE=rook-ceph !!! hint If you are upgrading via the Helm chart, the common resources and CRDs are automatically updated. -First apply updates to Rook-Ceph common resources. This includes modified privileges (RBAC) needed +First apply updates to Rook common resources. This includes modified privileges (RBAC) needed by the Operator. Also update the Custom Resource Definitions (CRDs). Get the latest common resources manifests that contain the latest changes.