From 49a35a93111f2ec4ae95f4c4670b8292fac08a67 Mon Sep 17 00:00:00 2001 From: subhamkrai Date: Mon, 30 May 2022 10:19:51 +0530 Subject: [PATCH] docs: update doc path according to new doc change we need to update the referred doc path according to our latest doc change. Signed-off-by: subhamkrai --- .github/ISSUE_TEMPLATE.md | 2 +- .github/ISSUE_TEMPLATE/bug_report.md | 2 +- .github/PULL_REQUEST_TEMPLATE.md | 6 +++--- CONTRIBUTING.md | 2 +- Documentation/CRDs/ceph-nfs-crd.md | 2 +- Documentation/Contributing/storage-providers.md | 2 +- .../Prerequisites/authenticated-registry.md | 2 +- Documentation/Troubleshooting/disaster-recovery.md | 2 +- INSTALL.md | 2 +- deploy/charts/rook-ceph-cluster/README.md | 2 +- deploy/charts/rook-ceph-cluster/templates/NOTES.txt | 2 +- deploy/charts/rook-ceph/README.md | 2 +- deploy/charts/rook-ceph/values.yaml | 2 +- deploy/examples/README.md | 2 +- deploy/examples/cluster-stretched-aws.yaml | 2 +- deploy/examples/cluster-stretched.yaml | 2 +- deploy/examples/cluster.yaml | 2 +- deploy/examples/osd-purge.yaml | 2 +- design/ceph/ceph-cluster-cleanup.md | 2 +- design/ceph/cluster-update.md | 2 +- design/ceph/dynamic-provision-filesystem.md | 2 +- design/ceph/filesystem.md | 2 +- design/ceph/object/bucketpolicy.md | 2 +- design/ceph/object/store.md | 4 ++-- design/ceph/object/zone.md | 8 ++++---- design/ceph/security-model.md | 2 +- design/ceph/upgrade.md | 8 ++++---- design/common/object-bucket.md | 4 ++-- 28 files changed, 38 insertions(+), 38 deletions(-) diff --git a/.github/ISSUE_TEMPLATE.md b/.github/ISSUE_TEMPLATE.md index 9328d27e2..2cbf22927 100644 --- a/.github/ISSUE_TEMPLATE.md +++ b/.github/ISSUE_TEMPLATE.md @@ -45,4 +45,4 @@ Read [GitHub documentation if you need help](https://help.github.com/en/articles * Storage backend version (e.g. for ceph do `ceph -v`): * Kubernetes version (use `kubectl version`): * Kubernetes cluster type (e.g. Tectonic, GKE, OpenShift): -* Storage backend status (e.g. for Ceph use `ceph health` in the [Rook Ceph toolbox](https://rook.io/docs/rook/latest/ceph-toolbox.html)): +* Storage backend status (e.g. for Ceph use `ceph health` in the [Rook Ceph toolbox](https://rook.io/docs/rook/latest/Troubleshooting/ceph-toolbox/#interactive-toolbox)): diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md index 932050141..5cbcf86e5 100644 --- a/.github/ISSUE_TEMPLATE/bug_report.md +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -36,4 +36,4 @@ Read [GitHub documentation if you need help](https://help.github.com/en/articles * Storage backend version (e.g. for ceph do `ceph -v`): * Kubernetes version (use `kubectl version`): * Kubernetes cluster type (e.g. Tectonic, GKE, OpenShift): -* Storage backend status (e.g. for Ceph use `ceph health` in the [Rook Ceph toolbox](https://rook.io/docs/rook/latest/ceph-toolbox.html)): +* Storage backend status (e.g. for Ceph use `ceph health` in the [Rook Ceph toolbox](https://rook.io/docs/rook/latest/Troubleshooting/ceph-toolbox/#interactive-toolbox)): diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index 7d5c4714e..c49a7da31 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -1,4 +1,4 @@ - @@ -9,9 +9,9 @@ Resolves # **Checklist:** -- [ ] **Commit Message Formatting**: Commit titles and messages follow guidelines in the [developer guide](https://rook.io/docs/rook/latest/development-flow.html#commit-structure). +- [ ] **Commit Message Formatting**: Commit titles and messages follow guidelines in the [developer guide](https://rook.io/docs/rook/latest/Contributing/development-flow/#commit-structure)). - [ ] **Skip Tests for Docs**: If this is only a documentation change, add the label `skip-ci` on the PR. -- [ ] Reviewed the developer guide on [Submitting a Pull Request](https://rook.io/docs/rook/latest/development-flow.html#submitting-a-pull-request) +- [ ] Reviewed the developer guide on [Submitting a Pull Request](https://rook.io/docs/rook/latest/Contributing/development-flow/#submitting-a-pull-request) - [ ] [Pending release notes](https://github.com/rook/rook/blob/master/PendingReleaseNotes.md) updated with breaking and/or notable changes for the next minor release. - [ ] Documentation has been updated, if necessary. - [ ] Unit tests have been added, if necessary. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 22049f047..fbe8d0c1f 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -55,7 +55,7 @@ This is a rough outline of what a contributor's workflow looks like: 1. Make sure all tests pass, and add any new tests as appropriate. 1. Submit a pull request to the original repository. -For detailed contribution instructions, refer to the [development flow](Documentation/development-flow.md). +For detailed contribution instructions, refer to the [development flow](Documentation/Contributing/development-flow.md). ## Coding Style diff --git a/Documentation/CRDs/ceph-nfs-crd.md b/Documentation/CRDs/ceph-nfs-crd.md index ccb499052..07e1fa40d 100644 --- a/Documentation/CRDs/ceph-nfs-crd.md +++ b/Documentation/CRDs/ceph-nfs-crd.md @@ -14,7 +14,7 @@ earlier protocols can inhibit responsiveness after a server restart. Due to a number of Ceph issues and changes, Rook officially only supports Ceph v16.2.7 or higher for CephNFS. If you are using an earlier version, upgrade your Ceph version following the advice given in Rook's - [v1.9 NFS docs](https://rook.github.io/docs/rook/v1.9/ceph-nfs-crd.html). + [v1.9 NFS docs](https://rook.github.io/docs/rook/latest/CRDs/ceph-nfs-crd/). ## Examples diff --git a/Documentation/Contributing/storage-providers.md b/Documentation/Contributing/storage-providers.md index 40894aa1e..311dc1599 100644 --- a/Documentation/Contributing/storage-providers.md +++ b/Documentation/Contributing/storage-providers.md @@ -49,7 +49,7 @@ Rook provides the following framework to assist storage providers in building an each storage provider has its own repo. * Helm charts are published to [charts.rook.io](https://charts.rook.io/release) * Documentation for the storage provider is to be written by the storage provider - members. The build process will publish the documentation to the [Rook website](https://rook.github.io/docs/rook/latest/). + members. The build process will publish the documentation to the [Rook website](https://rook.io/docs/rook/latest/). * All storage providers are added to the [Rook.io website](https://rook.io/) * A great Slack community is available where you can communicate amongst developers and users diff --git a/Documentation/Getting-Started/Prerequisites/authenticated-registry.md b/Documentation/Getting-Started/Prerequisites/authenticated-registry.md index f8265cbdb..503f9234d 100644 --- a/Documentation/Getting-Started/Prerequisites/authenticated-registry.md +++ b/Documentation/Getting-Started/Prerequisites/authenticated-registry.md @@ -11,7 +11,7 @@ The whole process is described in the [official kubernetes documentation](https: ## Example setup for a ceph cluster -To get you started, here's a quick rundown for the ceph example from the [quickstart guide](/Documentation/quickstart.md). +To get you started, here's a quick rundown for the ceph example from the [quickstart guide](../quickstart.md). First, we'll create the secret for our registry as described [here](https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) (the secret will be created in the `rook-ceph` namespace, make sure to change it if your Rook Ceph Operator/Cluster is in another namespace): diff --git a/Documentation/Troubleshooting/disaster-recovery.md b/Documentation/Troubleshooting/disaster-recovery.md index 796833165..925453b18 100644 --- a/Documentation/Troubleshooting/disaster-recovery.md +++ b/Documentation/Troubleshooting/disaster-recovery.md @@ -213,7 +213,7 @@ kubectl replace --force -f rook-ceph-mon-b-deployment.yaml !!! note Option `--force` will delete the deployment and create a new one -Start the rook [toolbox](/Documentation/ceph-toolbox.md) and verify the status of the cluster. +Start the rook [toolbox](ceph-toolbox.md) and verify the status of the cluster. ```console ceph -s diff --git a/INSTALL.md b/INSTALL.md index 69dff1432..59816864a 100644 --- a/INSTALL.md +++ b/INSTALL.md @@ -38,7 +38,7 @@ On every commit to PR and master the CI will build, run unit tests, and run inte If the build is for master or a release, the build will also be published to [dockerhub.com](https://cloud.docker.com/u/rook/repository/list). -> Note that if the pull request title follows Rook's [contribution guidelines](https://rook.io/docs/rook/latest/development-flow.html#commit-structure), the CI will automatically run the appropriate test scenario. For example if a pull request title is "ceph: add a feature", then the tests for the Ceph storage provider will run. Similarly, tests will only run for a single provider with the "cassandra:" and "nfs:" prefixes. +> Note that if the pull request title follows Rook's [contribution guidelines](https://rook.io/docs/rook/latest/Contributing/development-flow/#commit-structure), the CI will automatically run the appropriate test scenario. For example if a pull request title is "ceph: add a feature", then the tests for the Ceph storage provider will run. Similarly, tests will only run for a single provider with the "cassandra:" and "nfs:" prefixes. ## Building for other platforms diff --git a/deploy/charts/rook-ceph-cluster/README.md b/deploy/charts/rook-ceph-cluster/README.md index 8091753b8..fcca1ce8c 100644 --- a/deploy/charts/rook-ceph-cluster/README.md +++ b/deploy/charts/rook-ceph-cluster/README.md @@ -1 +1 @@ -See the [Helm Ceph Cluster](/Documentation/helm-ceph-cluster.md) documentation. +See the [Helm Ceph Cluster](/Documentation/Helm-Charts/ceph-cluster-chart.md) documentation. diff --git a/deploy/charts/rook-ceph-cluster/templates/NOTES.txt b/deploy/charts/rook-ceph-cluster/templates/NOTES.txt index 74f78811a..a3ffde062 100644 --- a/deploy/charts/rook-ceph-cluster/templates/NOTES.txt +++ b/deploy/charts/rook-ceph-cluster/templates/NOTES.txt @@ -1,7 +1,7 @@ The Ceph Cluster has been installed. Check its status by running: kubectl --namespace {{ .Release.Namespace }} get cephcluster -Visit https://rook.github.io/docs/rook/latest/ceph-cluster-crd.html for more information about the Ceph CRD. +Visit https://rook.io/docs/rook/latest/CRDs/ceph-cluster-crd/ for more information about the Ceph CRD. Important Notes: - You can only deploy a single cluster per namespace diff --git a/deploy/charts/rook-ceph/README.md b/deploy/charts/rook-ceph/README.md index 272e6ab55..184939122 100644 --- a/deploy/charts/rook-ceph/README.md +++ b/deploy/charts/rook-ceph/README.md @@ -1 +1 @@ -See the [Operator Helm Chart](/Documentation/helm-operator.md) documentation. +See the [Operator Helm Chart](/Documentation/Helm-Charts/operator-chart.md) documentation. diff --git a/deploy/charts/rook-ceph/values.yaml b/deploy/charts/rook-ceph/values.yaml index 6e61bd894..88b9da6ec 100644 --- a/deploy/charts/rook-ceph/values.yaml +++ b/deploy/charts/rook-ceph/values.yaml @@ -12,7 +12,7 @@ crds: # managed independently with deploy/examples/crds.yaml. # **WARNING** Only set during first deployment. If later disabled the cluster may be DESTROYED. # If the CRDs are deleted in this case, see the disaster recovery guide to restore them. - # https://rook.github.io/docs/rook/latest/ceph-disaster-recovery.html#restoring-crds-after-deletion + # https://rook.io/docs/rook/latest/Troubleshooting/disaster-recovery/#restoring-crds-after-deletion enabled: true resources: diff --git a/deploy/examples/README.md b/deploy/examples/README.md index e5a5c5e6d..d3b357031 100644 --- a/deploy/examples/README.md +++ b/deploy/examples/README.md @@ -1 +1 @@ -For documentation on running Rook in your Kubernetes cluster see the [Kubernetes Quickstart Guide](/Documentation/quickstart.md) +For documentation on running Rook in your Kubernetes cluster see the [Kubernetes Quickstart Guide](/Documentation/Getting-Started/quickstart.md) diff --git a/deploy/examples/cluster-stretched-aws.yaml b/deploy/examples/cluster-stretched-aws.yaml index 906d5ed33..d6d672172 100644 --- a/deploy/examples/cluster-stretched-aws.yaml +++ b/deploy/examples/cluster-stretched-aws.yaml @@ -22,7 +22,7 @@ spec: stretchCluster: # The ceph failure domain will be extracted from the label, which by default is the zone. The nodes running OSDs must have # this label in order for the OSDs to be configured in the correct topology. For topology labels, see - # https://rook.github.io/docs/rook/latest/ceph-cluster-crd.html#osd-topology. + # https://rook.io/docs/rook/latest/CRDs/ceph-cluster-crd/#osd-topology. failureDomainLabel: topology.kubernetes.io/zone # The sub failure domain is the secondary level at which the data will be placed to maintain data durability and availability. # The default is "host", which means that each OSD must be on a different node and you would need at least two nodes per zone. diff --git a/deploy/examples/cluster-stretched.yaml b/deploy/examples/cluster-stretched.yaml index 9df59a25c..0bc879a95 100644 --- a/deploy/examples/cluster-stretched.yaml +++ b/deploy/examples/cluster-stretched.yaml @@ -22,7 +22,7 @@ spec: stretchCluster: # The ceph failure domain will be extracted from the label, which by default is the zone. The nodes running OSDs must have # this label in order for the OSDs to be configured in the correct topology. For topology labels, see - # https://rook.github.io/docs/rook/latest/ceph-cluster-crd.html#osd-topology. + # https://rook.io/docs/rook/latest/CRDs/ceph-cluster-crd/#osd-topology. failureDomainLabel: topology.kubernetes.io/zone # The sub failure domain is the secondary level at which the data will be placed to maintain data durability and availability. # The default is "host", which means that each OSD must be on a different node and you would need at least two nodes per zone. diff --git a/deploy/examples/cluster.yaml b/deploy/examples/cluster.yaml index d9880b1a6..612502dcf 100644 --- a/deploy/examples/cluster.yaml +++ b/deploy/examples/cluster.yaml @@ -116,7 +116,7 @@ spec: # logCollector: # enabled: true # periodicity: 24h # SUFFIX may be 'h' for hours or 'd' for days. - # automate [data cleanup process](https://github.com/rook/rook/blob/master/Documentation/ceph-teardown.md#delete-the-data-on-hosts) in cluster destruction. + # automate [data cleanup process](https://github.com/rook/rook/blob/master/Documentation/Storage-Configuration/ceph-teardown.md#delete-the-data-on-hosts) in cluster destruction. cleanupPolicy: # Since cluster cleanup is destructive to data, confirmation is required. # To destroy all Rook data on hosts during uninstall, confirmation must be set to "yes-really-destroy-data". diff --git a/deploy/examples/osd-purge.yaml b/deploy/examples/osd-purge.yaml index 7359f3b77..dd854cd8c 100644 --- a/deploy/examples/osd-purge.yaml +++ b/deploy/examples/osd-purge.yaml @@ -1,5 +1,5 @@ ################################################################################################################# -# We need many operations to remove OSDs as written in Documentation/ceph-osd-mgmt.md. +# We need many operations to remove OSDs as written in Documentation/Storage-Configuration/Advanced/ceph-osd-mgmt.md. # This job can automate some of that operations: mark OSDs as `out`, purge these OSDs, # and delete the corresponding resources like OSD deployments, OSD prepare jobs, and PVCs. # diff --git a/design/ceph/ceph-cluster-cleanup.md b/design/ceph/ceph-cluster-cleanup.md index 281272bf8..b7b132979 100644 --- a/design/ceph/ceph-cluster-cleanup.md +++ b/design/ceph/ceph-cluster-cleanup.md @@ -11,7 +11,7 @@ If the user deletes a rook-ceph cluster and wants to start a new cluster on the - Delete the dataDirHostPath on each host. Otherwise, stale keys and other configs will remain from the previous cluster and the new mons will fail to start. - Clean the OSD disks from the previous cluster before starting a new one. -Read more about the manual clean up steps [here](https://github.com/rook/rook/blob/master/Documentation/ceph-teardown.md#delete-the-data-on-hosts) +Read more about the manual clean up steps [here](https://github.com/rook/rook/blob/master/Documentation/Storage-Configuration/ceph-teardown.md#delete-the-data-on-hosts) This implementation aims to automate both of these manual steps. diff --git a/design/ceph/cluster-update.md b/design/ceph/cluster-update.md index 350f22fc1..72c904b9b 100644 --- a/design/ceph/cluster-update.md +++ b/design/ceph/cluster-update.md @@ -1,7 +1,7 @@ # Cluster Updates ## Background -Currently, a Rook admin can declare how they want their cluster deployed by specifying values in the [Cluster CRD](../Documentation/ceph-cluster-crd.md). +Currently, a Rook admin can declare how they want their cluster deployed by specifying values in the [Cluster CRD](/Documentation/CRDs/ceph-cluster-crd.md). However, after a cluster has been initially declared and deployed, it is not currently possible to update the Cluster CRD and have those desired changes reflected in the actual cluster state. This document will describe a design for how cluster updating can be implemented, along with considerations, trade-offs, and a suggested scope of work. diff --git a/design/ceph/dynamic-provision-filesystem.md b/design/ceph/dynamic-provision-filesystem.md index 1d48bf46d..4dbfcc2fa 100644 --- a/design/ceph/dynamic-provision-filesystem.md +++ b/design/ceph/dynamic-provision-filesystem.md @@ -114,7 +114,7 @@ parameters: fsName: myFS # Name of the filesystem to use. ``` -The referenced filesystem, `myFS`, would have to be also created by the admin using a [Filesystem CRD](/Documentation/ceph-filesystem-crd.md). +The referenced filesystem, `myFS`, would have to be also created by the admin using a [Filesystem CRD](/Documentation//CRDs/Shared-Filesystem/ceph-filesystem-crd.md). The admin could also have created a more detailed StorageClass for more a durable filesystem as follows. Lets call it `rook-filesystem-gold`: diff --git a/design/ceph/filesystem.md b/design/ceph/filesystem.md index 57b405e64..34d13151e 100644 --- a/design/ceph/filesystem.md +++ b/design/ceph/filesystem.md @@ -52,7 +52,7 @@ The file system settings are exposed to Rook as a Custom Resource Definition (CR ### Pools -The pools are the backing data store for the file system and are created with specific names to be private to a file system. Pools can be configured with all of the settings that can be specified in the [Pool CRD](/Documentation/ceph-pool-crd.md). The underlying schema for pools defined by a pool CRD is the same as the schema under the `metadataPool` element and the `dataPools` elements of the file system CRD. +The pools are the backing data store for the file system and are created with specific names to be private to a file system. Pools can be configured with all of the settings that can be specified in the [Pool CRD](/Documentation/CRDs/Block-Storage/ceph-block-pool-crd.md). The underlying schema for pools defined by a pool CRD is the same as the schema under the `metadataPool` element and the `dataPools` elements of the file system CRD. ```yaml metadataPool: diff --git a/design/ceph/object/bucketpolicy.md b/design/ceph/object/bucketpolicy.md index 77ee75721..cd9a78a92 100644 --- a/design/ceph/object/bucketpolicy.md +++ b/design/ceph/object/bucketpolicy.md @@ -9,7 +9,7 @@ Adding bucket policy support for ceph object store ## Summary The bucket policy is the feature in which permissions for specific user can be set on s3 bucket. Read more about it from [ceph documentation](https://docs.ceph.com/docs/master/radosgw/bucketpolicy/) -Currently [ceph object store](/Documentation/ceph-object.md) can be consumed either via [OBC](/Documentation/ceph-object-bucket-claim.md) and [ceph object user](/Documentation/ceph-object-store-user-crd.md). As of now there is no direct way for ceph object user to access the OBC. The idea behind this feature to allow that functionality via Rook. Refer bucket policy examples from [here](https://docs.aws.amazon.com/AmazonS3/latest/dev/example-bucket-policies.html). Please note it is different from [IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html). +Currently [ceph object store](/Documentation/Storage-Configuration/Object-Storage-RGW/object-storage.md) can be consumed either via [OBC](/Documentation/Storage-Configuration/Object-Storage-RGW/ceph-object-bucket-claim.md) and [ceph object user](/Documentation/CRDs/Object-Storage/ceph-object-store-user-crd.md). As of now there is no direct way for ceph object user to access the OBC. The idea behind this feature to allow that functionality via Rook. Refer bucket policy examples from [here](https://docs.aws.amazon.com/AmazonS3/latest/dev/example-bucket-policies.html). Please note it is different from [IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html). ## Proposal details diff --git a/design/ceph/object/store.md b/design/ceph/object/store.md index 8bee7050b..311b1883b 100644 --- a/design/ceph/object/store.md +++ b/design/ceph/object/store.md @@ -4,7 +4,7 @@ An object store is a collection of resources and services that work together to serve HTTP requests to PUT and GET objects. Rook will automate the configuration of the Ceph resources and services that are necessary to start and maintain a highly available, durable, and performant object store. -The Ceph object store supports S3 and Swift APIs and a multitude of features such as replication of object stores between different zones. The Rook object store is designed to support all of these features, though will take some time to implement them. We welcome contributions! In the meantime, features that are not yet implemented can be configured by using the [Rook toolbox](/Documentation/ceph-toolbox.md) to run the `radosgw-admin` and other tools for advanced configuration. +The Ceph object store supports S3 and Swift APIs and a multitude of features such as replication of object stores between different zones. The Rook object store is designed to support all of these features, though will take some time to implement them. We welcome contributions! In the meantime, features that are not yet implemented can be configured by using the [Rook toolbox](/Documentation/Troubleshooting/ceph-toolbox.md) to run the `radosgw-admin` and other tools for advanced configuration. ### Prerequisites @@ -56,7 +56,7 @@ The object store settings are exposed to Rook as a Custom Resource Definition (C ### Pools -The pools are the backing data store for the object store and are created with specific names to be private to an object store. Pools can be configured with all of the settings that can be specified in the [Pool CRD](/Documentation/ceph-pool-crd.md). The underlying schema for pools defined by a pool CRD is the same as the schema under the `metadataPool` and `dataPool` elements of the object store CRD. All metadata pools are created with the same settings, while the data pool can be created with independent settings. The metadata pools must use replication, while the data pool can use replication or erasure coding. +The pools are the backing data store for the object store and are created with specific names to be private to an object store. Pools can be configured with all of the settings that can be specified in the [Pool CRD](/Documentation/CRDs/Block-Storage/ceph-block-pool-crd.md). The underlying schema for pools defined by a pool CRD is the same as the schema under the `metadataPool` and `dataPool` elements of the object store CRD. All metadata pools are created with the same settings, while the data pool can be created with independent settings. The metadata pools must use replication, while the data pool can use replication or erasure coding. If `preservePoolsOnDelete` is set to 'true' the pools used to support the object store will remain when the object store will be deleted. This is a security measure to avoid accidental loss of data. It is set to 'false' by default. If not specified is also deemed as 'false'. diff --git a/design/ceph/object/zone.md b/design/ceph/object/zone.md index 4bd59ad94..6e055512b 100644 --- a/design/ceph/object/zone.md +++ b/design/ceph/object/zone.md @@ -66,7 +66,7 @@ The order in which these resources are created is not important. 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. -A [ceph-object-pull-realm](/design/object/ceph-object-pull-realm.md) resource must be created to pull the realm information from the primary cluster to the pulling cluster. +A [ceph-object-pull-realm](/design/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. @@ -74,7 +74,7 @@ After an ceph-object-store is configured to be in this ceph-object-zone, the all ## Deleting and Reconfiguring the Ceph Object Zone -At the moment creating an ceph-object-zone resource only handles Day 1 initial configuration for the zone. +At the moment creating an ceph-object-zone resource only handles Day 1 initial configuration for the zone. Changes made to the resource's configuration or deletion of the resource are not reflected on the Ceph cluster. @@ -96,7 +96,7 @@ In the other scenario, there are more than one zones in a zone group. Care must be taken when changing which zone is the master zone. -Please read the following documentation before running the below commands: +Please read the following documentation before running the below commands: https://docs.ceph.com/docs/master/radosgw/multisite/#changing-the-metadata-master-zone @@ -151,7 +151,7 @@ spec: The pools are the backing data store for the object stores in the zone and are created with specific names to be private to a zone. As long as the `zone` config option is specified in the object-store's config, the object-store will use pools defined in the ceph-zone's configuration. -Pools can be configured with all of the settings that can be specified in the [Pool CRD](/Documentation/ceph-pool-crd.md). +Pools can be configured with all of the settings that can be specified in the [Pool CRD](/Documentation/CRDs/Block-Storage/ceph-block-pool-crd.md). The underlying schema for pools defined by a pool CRD is the same as the schema under the `metadataPool` and `dataPool` elements of the object store CRD. All metadata pools are created with the same settings, while the data pool can be created with independent settings. The metadata pools must use replication, while the data pool can use replication or erasure coding. diff --git a/design/ceph/security-model.md b/design/ceph/security-model.md index 7c5a5fe8e..b8472d720 100644 --- a/design/ceph/security-model.md +++ b/design/ceph/security-model.md @@ -250,7 +250,7 @@ subjects: namespace: rook-system ``` -Notably absent here are privileges to set other RBAC rules and create read cluster-wide secrets and other resources. Because the admin created the `rook-system` namespace and service account they are free to set policies on them using PSP or namespace quotas. Similar to the ones defined [here](https://github.com/rook/rook/blob/master/Documentation/kubernetes.md#rbac-for-podsecuritypolicies)). +Notably absent here are privileges to set other RBAC rules and create read cluster-wide secrets and other resources. Because the admin created the `rook-system` namespace and service account they are free to set policies on them using PSP or namespace quotas. Also note that while we use a `ClusterRole` for rook-system we only use a `RoleBinding` to grant it access to the `rook-system` namespace. It does not have cluster-wide privileges. diff --git a/design/ceph/upgrade.md b/design/ceph/upgrade.md index 961a8068e..aa9c3d0d8 100644 --- a/design/ceph/upgrade.md +++ b/design/ceph/upgrade.md @@ -19,7 +19,7 @@ The cluster should be maintained in a healthy state the entire time. ## **User Guide** Until automated upgrade support is available in Rook, we have authored a user guide that walks you through the steps to upgrade the software in a Rook cluster. Consideration is also provided in the guide for how to verify the cluster remains healthy during and after the upgrade process. -Please refer to the [Rook Upgrade User Guide](../Documentation/rook-upgrade.md) to learn more about the current Rook upgrade process. +Please refer to the [Rook Upgrade User Guide](/Documentation/Upgrade/rook-upgrade.md) to learn more about the current Rook upgrade process. ## **Detailed Design** The responsibility for performing and orchestrating an upgrade will be handled by an upgrade controller that runs as part of the Rook operator, in the same pod and process (similar to how the Rook volume provisioner is run). @@ -34,7 +34,7 @@ The upgrade controller should not begin an upgrade if the cluster is currently u ### **General Sequence** This section describes in a broad sense the general sequence of steps for upgrading a Rook cluster after a new Rook software version is released, e.g. `v0.6.1`. -Note that this sequence is modeled after the [Rook Upgrade User Guide](../Documentation/rook-upgrade.md), including the cluster health checks described in the [health verification section](../Documentation/rook-upgrade.md#health-verification). +Note that this sequence is modeled after the [Rook Upgrade User Guide](/Documentation/Upgrade/rook-upgrade.md), including the cluster health checks described in the [health verification section](/Documentation/Upgrade/rook-upgrade.md#health-verification). #### **Rook System Namespace** The Rook system namespace contains the single control plane for all Rook clusters in the environment. @@ -80,7 +80,7 @@ They are both managed by deployments, so the upgrade controller will update the 1. Cluster health and object/file functionality will be verified before the upgrade controller moves on to the next instances. ### **Upgrade Health Verification** -As mentioned previously, the manual health verification steps found in the [upgrade user guide](../Documentation/rook-upgrade.md#health-verification) will be used by the upgrade controller, in an automated fashion, to ensure the cluster is healthy before proceeding with the upgrade process. +As mentioned previously, the manual health verification steps found in the [upgrade user guide](/Documentation/Upgrade/rook-upgrade.md#health-verification) will be used by the upgrade controller, in an automated fashion, to ensure the cluster is healthy before proceeding with the upgrade process. This approach of upgrading one component, verifying health and stability, then upgrading the next component can be viewed as a form of [canary deployment](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments). Here is a quick summary of the standard health checks the upgrade controller should perform: @@ -160,7 +160,7 @@ Listed below are a few techniques for accessing debugging artifacts from pods th * All health check status and output it encountered ## **Next Steps** -We have demonstrated that Rook is upgradable with the manual process outlined in the [Rook Upgrade User Guide](../Documentation/rook-upgrade.md). +We have demonstrated that Rook is upgradable with the manual process outlined in the [Rook Upgrade User Guide](/Documentation/Upgrade/rook-upgrade.md). Fully automated upgrade support has been described within this design proposal, but will likely need to be implemented in an iterative process, with lessons learned along the way from pre-production field experience. The next step will be to implement the happy path where the upgrade controller automatically updates all Rook components in the [described sequence](#general-sequence) and stops immediately if any health checks fail and the cluster does not return to a healthy functional state. diff --git a/design/common/object-bucket.md b/design/common/object-bucket.md index e81cbefdf..c24f8b050 100644 --- a/design/common/object-bucket.md +++ b/design/common/object-bucket.md @@ -15,7 +15,7 @@ The secret contains bucket access keys. The configmap contains bucket endpoint i When the _ObjectBucketClaim_ is deleted all of the Kubernetes resources created by the Rook-Ceph provisioner are deleted, and provisioner specific artifacts, such as dynamic users and access policies are removed. And, depending on the _reclaimPolicy_ in the storage class referenced in the OBC, the bucket will be retained or deleted. -We welcome contributions! In the meantime, features that are not yet implemented may be configured by using the [Rook toolbox](/Documentation/ceph-toolbox.md) to run the `radosgw-admin` and other tools for advanced bucket policies. +We welcome contributions! In the meantime, features that are not yet implemented may be configured by using the [Rook toolbox](/Documentation/Troubleshooting/ceph-toolbox.md) to run the `radosgw-admin` and other tools for advanced bucket policies. ### Prerequisites @@ -80,7 +80,7 @@ The object store settings are exposed to Rook as a Custom Resource Definition (C ### Pools -The pools are the backing data store for the object store and are created with specific names to be private to an object store. Pools can be configured with all of the settings that can be specified in the [Pool CRD](/Documentation/ceph-pool-crd.md). The underlying schema for pools defined by a pool CRD is the same as the schema under the `metadataPool` and `dataPool` elements of the object store CRD. All metadata pools are created with the same settings, while the data pool can be created with independent settings. The metadata pools must use replication, while the data pool can use replication or erasure coding. +The pools are the backing data store for the object store and are created with specific names to be private to an object store. Pools can be configured with all of the settings that can be specified in the [Pool CRD](/Documentation/CRDs/Block-Storage/ceph-block-pool-crd.md). The underlying schema for pools defined by a pool CRD is the same as the schema under the `metadataPool` and `dataPool` elements of the object store CRD. All metadata pools are created with the same settings, while the data pool can be created with independent settings. The metadata pools must use replication, while the data pool can use replication or erasure coding. ```yaml metadataPool: