doc: add upgrade steps for external cluster
curently if user want to utilise the new flags with upgrade user dont have the ability for it Add the steps so user can make use of it closes: https://github.com/rook/rook/issues/14368 Signed-off-by: parth-gr <partharora1010@gmail.com>
This commit is contained in:
parth-gr committed
1 parent
0837c15b86
commit
8e72748be2
1 file changed
+54
-19
@@ -121,25 +121,6 @@ The storageclass is used to create a volume in the pool matching the topology wh
|
||||
|
||||
For more details, see the [Topology-Based Provisioning](topology-for-external-mode.md)
|
||||
|
||||
### Upgrade Example
|
||||
|
||||
1. If consumer cluster doesn't have restricted caps, this will upgrade all the default csi-users (non-restricted):
|
||||
|
||||
```console
|
||||
python3 create-external-cluster-resources.py --upgrade
|
||||
```
|
||||
|
||||
2. If the consumer cluster has restricted caps:
|
||||
Restricted users created using `--restricted-auth-permission` flag need to pass mandatory flags: '`--rbd-data-pool-name`(if it is a rbd user), `--k8s-cluster-name` and `--run-as-user`' flags while upgrading, in case of cephfs users if you have passed `--cephfs-filesystem-name` flag while creating csi-users then while upgrading it will be mandatory too. In this example the user would be `client.csi-rbd-node-rookstorage-replicapool` (following the pattern `csi-user-clusterName-poolName`)
|
||||
|
||||
```console
|
||||
python3 create-external-cluster-resources.py --upgrade --rbd-data-pool-name replicapool --k8s-cluster-name rookstorage --run-as-user client.csi-rbd-node-rookstorage-replicapool
|
||||
```
|
||||
|
||||
!!! note
|
||||
An existing non-restricted user cannot be converted to a restricted user by upgrading.
|
||||
The upgrade flag should only be used to append new permissions to users. It shouldn't be used for changing a csi user already applied permissions. For example, you shouldn't change the pool(s) a user has access to.
|
||||
|
||||
### Admin privileges
|
||||
|
||||
If in case the cluster needs the admin keyring to configure, update the admin key `rook-ceph-mon` secret with client.admin keyring
|
||||
@@ -305,3 +286,57 @@ you can export the settings from this cluster with the following steps.
|
||||
|
||||
!!! important
|
||||
For other clusters to connect to storage in this cluster, Rook must be configured with a networking configuration that is accessible from other clusters. Most commonly this is done by enabling host networking in the CephCluster CR so the Ceph daemons will be addressable by their host IPs.
|
||||
|
||||
## Upgrades
|
||||
|
||||
Upgrading the cluster would be different for restricted caps and non-restricted caps,
|
||||
|
||||
1. If consumer cluster doesn't have restricted caps, this will upgrade all the default CSI users (non-restricted)
|
||||
|
||||
```console
|
||||
python3 create-external-cluster-resources.py --upgrade
|
||||
```
|
||||
|
||||
2. If the consumer cluster has restricted caps
|
||||
|
||||
Restricted users created using `--restricted-auth-permission` flag need to pass mandatory flags: '`--rbd-data-pool-name`(if it is a rbd user), `--k8s-cluster-name` and `--run-as-user`' flags while upgrading, in case of cephfs users if you have passed `--cephfs-filesystem-name` flag while creating CSI users then while upgrading it will be mandatory too. In this example the user would be `client.csi-rbd-node-rookstorage-replicapool` (following the pattern `csi-user-clusterName-poolName`)
|
||||
|
||||
```console
|
||||
python3 create-external-cluster-resources.py --upgrade --rbd-data-pool-name replicapool --k8s-cluster-name rookstorage --run-as-user client.csi-rbd-node-rookstorage-replicapool
|
||||
```
|
||||
|
||||
!!! note
|
||||
1) An existing non-restricted user cannot be converted to a restricted user by upgrading.
|
||||
2) The upgrade flag should only be used to append new permissions to users. It shouldn't be used for changing a CSI user already applied permissions. For example, be careful not to change pools(s) that a user has access to.
|
||||
|
||||
### Upgrade cluster to utilize new feature
|
||||
|
||||
Some Rook upgrades may require re-running the import steps, or may introduce new external cluster features that can be most easily enabled by re-running the import steps.
|
||||
|
||||
To re-run the import steps with new options, the python script should be re-run using the same configuration options that were used for past invocations, plus the configurations that are being added or modified.
|
||||
|
||||
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. Argument that are decided using the Priority: command-line-args > config.ini file values > default values.
|
||||
|
||||
#### Example `external-cluster-user-command` ConfigMap:
|
||||
|
||||
1. Get the last-applied config, if its available
|
||||
|
||||
```console
|
||||
$ kubectl get configmap -namespace rook-ceph external-cluster-user-command --output jsonpath='{.data.args}'
|
||||
```
|
||||
|
||||
2. Copy the output to config.ini
|
||||
|
||||
3. Make any desired modifications and additions to `config.ini``
|
||||
|
||||
4. Run the python script again using the [config file](#config-file)
|
||||
|
||||
5. [Copy the bash output](#2-copy-the-bash-output)
|
||||
|
||||
6. Run the steps under [import-the-source-data](#import-the-source-data)
|
||||
|
||||
!!! warning
|
||||
If the last-applied config is unavailable, run the current version of the script again using previously-applied config and CLI flags.
|
||||
Failure to reuse the same configuration options when re-invoking the python script can result in unexpected changes when re-running the import script.
|
||||
Reference in new issue
Block a user