Merge pull request #17837 from jhoblitt/docs-fix-typos
docs: fix typos and grammar in documentation and design docs
This commit is contained in:
15 files changed
+30
-30
No files matched your search
@@ -55,7 +55,7 @@ The OSDs are spread across multiple nodes
|
||||
because the [`failureDomain`](ceph-block-pool-crd.md#spec) is set to `host`.
|
||||
Setting the `failureDomain` to `osd` is **not** a good idea for production data.
|
||||
The `erasureCoded` chunk settings require at least six OSDs of the specified
|
||||
deviceClass: four `dataChunks` + two `codingChunks`).
|
||||
deviceClass: four `dataChunks` + two `codingChunks`.
|
||||
|
||||
|
||||
```yaml
|
||||
@@ -89,7 +89,7 @@ replicated pools and at least four when using erasure coding. Specifically, an
|
||||
erasure-coded pool should specify `failureDomain: host` and the cluster should comprise at
|
||||
least `dataChunks+1` hosts. There are certain operational flexibility advantages to
|
||||
provisioning at least `dataChunks + codingChunks +1` hosts, including being able
|
||||
to full use the aggregate raw capacity when the failure domains are not
|
||||
to fully use the aggregate raw capacity when the failure domains are not
|
||||
all equal in CRUSH weight.
|
||||
|
||||
A very small cluster that cannot provision at least six nodes, at least at first, may
|
||||
|
||||
@@ -51,7 +51,7 @@ If this value is empty, each pod will get an ephemeral directory to store their
|
||||
* `externalMgrEndpoints`: external cluster manager endpoints
|
||||
* `externalMgrPrometheusPort`: external prometheus manager module port. See [external cluster configuration](./external-cluster/external-cluster.md) for more details.
|
||||
* `port`: The internal prometheus manager module port where the prometheus mgr module listens. The port may need to be configured when host networking is enabled.
|
||||
* `interval`: The interval for the prometheus module to to scrape targets.
|
||||
* `interval`: The interval for the prometheus module to scrape targets.
|
||||
* `exporter`: Ceph exporter metrics config.
|
||||
* `perfCountersPrioLimit`: Specifies which performance counters are exported. Corresponds to `--prio-limit` Ceph exporter flag. `0` - all counters are exported, default is `5`.
|
||||
* `statsPeriodSeconds`: Time to wait before sending requests again to exporter server (seconds). Corresponds to `--stats-period` Ceph exporter flag. Default is `5`.
|
||||
|
||||
@@ -33,7 +33,7 @@ To re-run the import steps with new options, the python script should be re-run
|
||||
|
||||
Starting with Rook v1.15, the script stores the configuration in the external-cluster-user-command configmap for easy future reference.
|
||||
|
||||
* arg: Exact arguments that were used for for processing the script.
|
||||
* arg: Exact arguments that were used for processing the script.
|
||||
Argument that are decided using the Priority: command-line-args has more priority than config.ini file values, and config.ini file values have more priority than default values.
|
||||
|
||||
### Example `external-cluster-user-command` ConfigMap:
|
||||
|
||||
@@ -70,11 +70,11 @@ communication. This eliminates latency from the software-defined pod network, bu
|
||||
host-level security isolation.
|
||||
|
||||
Ceph daemons will use any network available on the host for communication. To restrict Ceph to using
|
||||
only a specific specific host interfaces or networks, use `addressRanges` to select the network
|
||||
only specific host interfaces or networks, use `addressRanges` to select the network
|
||||
CIDRs Ceph will bind to on the host.
|
||||
|
||||
If the Ceph mons are expected to bind to a public network that is different from the IP address
|
||||
assign to the K8s node where the mon is running, the IP address for the mon can be set by
|
||||
assigned to the K8s node where the mon is running, the IP address for the mon can be set by
|
||||
adding an annotation to the node:
|
||||
|
||||
```yaml
|
||||
|
||||
@@ -202,7 +202,7 @@ The gateway settings correspond to the RGW daemon settings.
|
||||
|
||||
* `caBundleRef`: If specified, this is the name of the Kubernetes secret (type `opaque`) that
|
||||
contains additional custom ca-bundle to use. The secret must be in the same namespace as the Rook
|
||||
cluster. Rook will look in the secret provided at the `cabundle` key name. This bundle is used used by RGW to verify
|
||||
cluster. Rook will look in the secret provided at the `cabundle` key name. This bundle is used by RGW to verify
|
||||
external applications that RGW connects to. For example: LDAP servers, or a different RGW realm for multisite connections.
|
||||
This bundle is **not** used by the rook operator when connecting to the RGW. See the notes on `sslCertificateRef` on
|
||||
how to load the entire certificate chain into `cert` for use by the operator instead.
|
||||
|
||||
@@ -121,7 +121,7 @@ First, on your workload ensure that you have the appropriate packages installed
|
||||
|
||||
Without the appropriate package (or a from-scratch build of SQLite), you will be unable to load `libcephsqlite.so`.
|
||||
|
||||
After creating a `CephClient` similar to [`deploy/examples/sqlitevfs-client.yaml`](https://github.com/rook/rook/blob/master/deploy/examples/sqlitevfs-client.yaml) and retrieving it's credentials, you may set the following ENV variables:
|
||||
After creating a `CephClient` similar to [`deploy/examples/sqlitevfs-client.yaml`](https://github.com/rook/rook/blob/master/deploy/examples/sqlitevfs-client.yaml) and retrieving its credentials, you may set the following ENV variables:
|
||||
|
||||
```console
|
||||
export CEPH_CONF=/libsqliteceph/ceph.conf;
|
||||
|
||||
@@ -22,7 +22,7 @@ Architectures released are `amd64 / x86_64` and `arm64`.
|
||||
|
||||
To check if a Kubernetes cluster is ready for `Rook`, see the [prerequisites](Prerequisites/prerequisites.md).
|
||||
|
||||
To configure the Ceph storage cluster, at least one of these local storage options are required:
|
||||
To configure the Ceph storage cluster, at least one of these local storage options is required:
|
||||
|
||||
* Raw devices (no partitions or formatted filesystem)
|
||||
* Raw partitions (no formatted filesystem)
|
||||
|
||||
@@ -76,7 +76,7 @@ rbd unmap /dev/rbd0
|
||||
## Shared Filesystem Tools
|
||||
|
||||
After you have created a filesystem as described in the [Shared Filesystem](../Storage-Configuration/Shared-Filesystem-CephFS/filesystem-storage.md) topic, you can mount the filesystem from multiple pods.
|
||||
The the other topic you may have mounted the filesystem already in the registry pod. Now we will mount the same filesystem in the Direct Mount pod.
|
||||
The other topic you may have mounted the filesystem already in the registry pod. Now we will mount the same filesystem in the Direct Mount pod.
|
||||
This is just a simple way to validate the Ceph filesystem and is not recommended for production Kubernetes pods.
|
||||
|
||||
Follow [Direct Mount Pod](direct-tools.md#Start-the-Direct-Mount-Pod) to start a pod with the necessary mounts and then proceed with the following commands after connecting to the pod.
|
||||
|
||||
@@ -48,7 +48,7 @@ those releases.
|
||||
With this upgrade guide, there are a few notes to consider:
|
||||
|
||||
* **WARNING**: Upgrading a Rook cluster is not without risk. There may be unexpected issues or
|
||||
obstacles that damage the integrity and health the storage cluster, including data loss.
|
||||
obstacles that damage the integrity and health of the storage cluster, including data loss.
|
||||
* The Rook cluster's storage may be unavailable for short periods during the upgrade process for
|
||||
both Rook operator updates and for Ceph version updates.
|
||||
* Read this document in full before undertaking the cluster upgrade.
|
||||
|
||||
@@ -47,7 +47,7 @@ If any of the controllers in either phase reject the request, the entire request
|
||||
|
||||
|
||||
|
||||
We can use self-signed certificates approved by the Kubernetes Certificate Authority for development purposes.This can be done by following the steps given below.
|
||||
We can use self-signed certificates approved by the Kubernetes Certificate Authority for development purposes. This can be done by following the steps given below.
|
||||
|
||||
* Creating the private key and certs using openssl.
|
||||
|
||||
|
||||
@@ -73,7 +73,7 @@ This allows the NFS-Ganesha server cluster to be scalable and highly available.
|
||||
will mount the file into the SSSD sidecar.
|
||||
2. The file mode must be 0600.
|
||||
- Users only need one SSSD conf Volume per CephNFS that has this option path enabled.
|
||||
- Users must be able to provide additional files that are referenced in the the SSSD config file
|
||||
- Users must be able to provide additional files that are referenced in the SSSD config file
|
||||
|
||||
#### Example
|
||||
Below is an example NFS-Ganesha CRD, `nfs-ganesha.yaml`
|
||||
@@ -282,7 +282,7 @@ NFS_KRB5
|
||||
}
|
||||
```
|
||||
|
||||
Add the following line to to the config object (`conf-nfs.${nfs-name}`) to reference the new
|
||||
Add the following line to the config object (`conf-nfs.${nfs-name}`) to reference the new
|
||||
`kerberos` RADOS object. Remove this line from the config object if Kerberos is disabled.
|
||||
```
|
||||
%url "rados://.nfs/${nfs-name}/kerberos"
|
||||
|
||||
@@ -16,7 +16,7 @@ The Ceph COSI driver is deployed as a deployment with a [COSI sidecar container]
|
||||
|
||||
## Integration plan with Rook
|
||||
|
||||
The aim to support the v1alpha1 version of COSI in Rook v1.12. It will be extended to beta and release versions as appropriate. There will be one COSI Driver support from Rook. The driver will be started automatically with default settings when first Object Store gets created. The driver will be deleted when Rook Operator is uninstalled. The driver will be deployed in the same namespace as Rook operator. The user can provide additional setting via new `CephCOSIDriver` CRD which is owned by Rook.
|
||||
The aim is to support the v1alpha1 version of COSI in Rook v1.12. It will be extended to beta and release versions as appropriate. There will be one COSI Driver support from Rook. The driver will be started automatically with default settings when first Object Store gets created. The driver will be deleted when Rook Operator is uninstalled. The driver will be deployed in the same namespace as Rook operator. The user can provide additional settings via new `CephCOSIDriver` CRD which is owned by Rook.
|
||||
|
||||
### Pre-requisites
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ A Rook Ceph cluster. Ideally a ceph-object-realm and a ceph-object-zone-group re
|
||||
|
||||
The resource described in this design document represents the zone in the [Ceph Multisite data model](/design/ceph/object/ceph-multisite-overview.md).
|
||||
|
||||
### Creating an Ceph Object Zone
|
||||
### Creating a Ceph Object Zone
|
||||
|
||||
#### Config
|
||||
|
||||
@@ -18,7 +18,7 @@ In the config, the admin must configure the zone group the zone is in, and pools
|
||||
|
||||
The first zone created in a zone group is designated as the master zone in the Ceph cluster.
|
||||
|
||||
If endpoint(s) are not specified the endpoint will be set to the Kubernetes service DNS address and port used for the CephObjectStore. To override this, a user can specify custom endpoint(s). The endpoint(s) specified will be become the sole source of endpoints for the zone, replacing any service endpoints added by CephObjectStores.
|
||||
If endpoint(s) are not specified the endpoint will be set to the Kubernetes service DNS address and port used for the CephObjectStore. To override this, a user can specify custom endpoint(s). The endpoint(s) specified will become the sole source of endpoints for the zone, replacing any service endpoints added by CephObjectStores.
|
||||
|
||||
This example `ceph-object-zone.yaml`, names a zone `my-zone`.
|
||||
```yaml
|
||||
@@ -54,28 +54,28 @@ kubectl create -f ceph-object-zone.yaml
|
||||
|
||||
2. After these steps the admin should start up:
|
||||
- A [ceph-object-store](/design/ceph/object/ceph-object-store.md) referring to the newly started up ceph-object-zone resource.
|
||||
- A [ceph-object-zone-group](/design/ceph/object/ceph-object-zone-group.md), with the same name as the `zoneGroup` field, if it has not already been started up already.
|
||||
- A [ceph-object-realm](/design/ceph/object/ceph-object-realm.md), with the same name as the `realm` field in the ceph-object-zone-group config, if it has not already been started up already.
|
||||
- A [ceph-object-zone-group](/design/ceph/object/ceph-object-zone-group.md), with the same name as the `zoneGroup` field, if it has not already been started up.
|
||||
- A [ceph-object-realm](/design/ceph/object/ceph-object-realm.md), with the same name as the `realm` field in the ceph-object-zone-group config, if it has not already been started up.
|
||||
|
||||
The order in which these resources are created is not important.
|
||||
|
||||
3. Once the all of the resources in #2 are started up, the operator will create a zone on the Rook Ceph cluster and the ceph-object-zone resource will be running.
|
||||
3. Once all of the resources in #2 are started up, the operator will create a zone on the Rook Ceph cluster and the ceph-object-zone resource will be running.
|
||||
|
||||
#### Notes
|
||||
|
||||
1. The zone group named in the `zoneGroup` section must be the same as the ceph-object-zone-group resource the zone is a part of.
|
||||
2. When resource is deleted, zone are not deleted from the cluster. zone deletion must be done through toolboxes.
|
||||
2. When a resource is deleted, zones are not deleted from the cluster. Zone deletion must be done through toolboxes.
|
||||
3. Any number of ceph-object-stores can be part of a ceph-object-zone.
|
||||
|
||||
### Creating an ceph-object-zone when syncing from another Ceph Cluster
|
||||
### Creating a ceph-object-zone when syncing from another Ceph Cluster
|
||||
|
||||
When the storage admin is ready to sync data from another Ceph cluster with multisite set up (primary cluster) to a Rook Ceph cluster (pulling cluster), the pulling cluster will have a newly created in the zone group from the primary cluster.
|
||||
When the storage admin is ready to sync data from another Ceph cluster with multisite set up (primary cluster) to a Rook Ceph cluster (pulling cluster), the pulling cluster will have a newly created zone in the zone group from the primary cluster.
|
||||
|
||||
A [ceph-object-pull-realm](/design/ceph/object/ceph-object-pull-realm.md) resource must be created to pull the realm information from the primary cluster to the pulling cluster.
|
||||
|
||||
Once the ceph-object-pull-realm is configured a ceph-object-zone must be created.
|
||||
|
||||
After an ceph-object-store is configured to be in this ceph-object-zone, the all Ceph multisite resources will be running and data between the two clusters will start syncing.
|
||||
After a ceph-object-store is configured to be in this ceph-object-zone, all Ceph multisite resources will be running and data between the two clusters will start syncing.
|
||||
|
||||
## Deleting and Reconfiguring the Ceph Object Zone
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@
|
||||
## Non-Goals/Deferred Features:
|
||||
|
||||
Migration of OSDs with following configurations is deferred for now and will
|
||||
considered in the future:
|
||||
be considered in the future:
|
||||
- Hybrid OSDs where metadata (RocksDB+WAL) is placed on faster storage media
|
||||
and application data on slower media.
|
||||
- Setups with multiple OSDs per drive, though with recent Ceph releases the
|
||||
@@ -116,11 +116,11 @@ OSD replacement steps:
|
||||
1. If all PGs are `active+clean` but a previous OSD migration is not completed, do not proceed.
|
||||
1. If all PGs are `active+clean` and no migration is in progress, then select an OSD to be migrated.
|
||||
1. Delete the OSD deployment.
|
||||
1. Create an OSD prepare job with an environment variable indictating the OSD ID to be replaced.
|
||||
1. Create an OSD prepare job with an environment variable indicating the OSD ID to be replaced.
|
||||
1. The OSD prepare pod will destroy the OSD (`ceph osd destroy {id} --yes-i-really-mean-it`) and prepare it again using the same OSD ID. Refer [Destroy OSD](#destroy-osd) for details.
|
||||
1. Once the destroyed OSD pod is recreated, delete the configmap.
|
||||
1. If there is any error during the OSD migration, then preserve the OSD ID being replaced in the configmap for next reconcile.
|
||||
1. Reconcile the operator and perform as same steps until all the OSDs have migrated to the new backend.
|
||||
1. Reconcile the operator and perform the same steps until all the OSDs have migrated to the new backend.
|
||||
|
||||
|
||||
## Risks
|
||||
|
||||
@@ -29,7 +29,7 @@ The necessary system states for the rook-ceph can be portrayed as follows:
|
||||
|
||||
Reference: https://github.com/openshift/custom-resource-status/:
|
||||
|
||||
The `Status` of the Condition can be toggled between True or False according to the state of the cluster which it goes through. This can be shown to the user in the clusterCR with along with the information about the Conditions like the `Reason`, `Message` etc. Also a readable status, which basically states the final condition of the cluster along with the Message, which gives out some detail about the Condition like whether the Cluster is 'ReadytoUse' or if there is an Update available, we can update the MESSAGE as 'UpdateAvailable'. This could make it more understandable of the state of cluster to the user. Also, a Condition which states that the Cluster is undergoing an Upgrading can be added. Cluster Upgrade happens when there is a new version is available and changes the current Cluster CR. This will help the user to know the status of the Cluster Upgrade in progress.
|
||||
The `Status` of the Condition can be toggled between True or False according to the state of the cluster which it goes through. This can be shown to the user in the clusterCR along with the information about the Conditions like the `Reason`, `Message` etc. Also a readable status, which basically states the final condition of the cluster along with the Message, which gives out some detail about the Condition like whether the Cluster is 'ReadytoUse' or if there is an Update available, we can update the MESSAGE as 'UpdateAvailable'. This could make it more understandable of the state of the cluster to the user. Also, a Condition which states that the Cluster is undergoing an Upgrading can be added. Cluster Upgrade happens when there is a new version is available and changes the current Cluster CR. This will help the user to know the status of the Cluster Upgrade in progress.
|
||||
|
||||
NAME DATADIRHOSTPATH MONCOUNT AGE CONDITION MESSAGE HEALTH
|
||||
rook-ceph /var/lib/rook 3 114s Available ReadyToUse HEALTH_OK
|
||||
@@ -44,7 +44,7 @@ We can add Conditions simply in the Custom Resource struct as:
|
||||
CephStatus *CephStatus `json:"ceph,omitempty"`
|
||||
}
|
||||
|
||||
After that we can just make changes inside rook ceph codebase as necessary. The `setStatusCondition()` field will be fed with the `newCondition` variable which holds the entries for the new Conditions. The `FindStatusCondition` will return the Condition if it is having the same `ConditionType` as the `newCondition` otherwise, it will return `nil`. If `nil` is returned then `LastHeartbeatTime` and `LastTransitionTime` is updated and gets appended to the `Condition`. The `Condition.Status` gets updated if the value is different from the `existingCondition.Status`. Rest of the fields of the `Status.Condition` are also updated. The `FinalCondition` will be holding the final condition the cluster is in. This will be displayed into the readable status along with a message, which is an extra useful information for the users.
|
||||
After that we can just make changes inside rook ceph codebase as necessary. The `setStatusCondition()` field will be fed with the `newCondition` variable which holds the entries for the new Conditions. The `FindStatusCondition` will return the Condition if it is having the same `ConditionType` as the `newCondition` otherwise, it will return `nil`. If `nil` is returned then `LastHeartbeatTime` and `LastTransitionTime` are updated and gets appended to the `Condition`. The `Condition.Status` gets updated if the value is different from the `existingCondition.Status`. Rest of the fields of the `Status.Condition` are also updated. The `FinalCondition` will be holding the final condition the cluster is in. This will be displayed into the readable status along with a message, which is an extra useful information for the users.
|
||||
|
||||
|
||||
The definition of the type Conditions can have the following details:
|
||||
@@ -56,7 +56,7 @@ The definition of the type Conditions can have the following details:
|
||||
LastHeartbeatTime *unversioned.Time `json:"lastHeartbeatTime,omitempty" description:"last time we got an update on a given condition"`
|
||||
LastTransitionTime *unversioned.Time `json:"lastTransitionTime,omitempty" description:"last time the condition transition from one status to another"`
|
||||
|
||||
The fields `Reason`, `Message`, `LastHeartbeatTime`, `LastTransitionTime` are optional field. Though the use of `Reason` field is encouraged.
|
||||
The fields `Reason`, `Message`, `LastHeartbeatTime`, `LastTransitionTime` are optional fields. Though the use of `Reason` field is encouraged.
|
||||
|
||||
Condition Types field specifies the current state of the system. Condition status values may be `True`, `False`, or `Unknown`. The absence of a condition should be interpreted the same as Unknown. How controllers handle Unknown depends on the Condition in question.
|
||||
`Reason` is intended to be a one-word, CamelCase representation of the category of cause of the current status, and `Message` is intended to be a human-readable phrase or sentence, which may contain specific details of the individual occurrence. `Reason` is intended to be used in concise output, such as one-line kubectl get output, and in summarizing occurrences of causes, whereas `Message` is intended to be presented to users in detailed status explanations, such as `kubectl describe output`.
|
||||
|
||||
Reference in new issue
Block a user