Bug 1849532 - OCS 4.5-Update uninstall chapter in the deployment guide for both Internal and External Mode
Summary: OCS 4.5-Update uninstall chapter in the deployment guide for both Internal an...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat OpenShift Container Storage
Classification: Red Hat Storage
Component: documentation
Version: 4.5
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: OCS 4.5.0
Assignee: Agil Antony
QA Contact: Neha Berry
URL:
Whiteboard:
: 1870648 (view as bug list)
Depends On: 1860431
Blocks: 1826391
TreeView+ depends on / blocked
 
Reported: 2020-06-22 07:06 UTC by Raghavendra Talur
Modified: 2023-09-14 06:02 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-20 15:21:56 UTC
Embargoed:


Attachments (Terms of Use)

Description Raghavendra Talur 2020-06-22 07:06:27 UTC
Description of problem (please be detailed as possible and provide log
snippests):
OCS 4.5 improves the uninstall experience and simplifies some of the tasks.

Version of all relevant components (if applicable):
4.5

1. At the very minimum, the deletion of the storage classes is now automatic. 
2. The node labels and the taints are also removed when the StorageCluster is removed.
3. Rook deletes the datadir on the hosts if a confirmation is provided in the config of StorageCluster.


More changes, if any, will be provided here in the bug.

Comment 6 Sébastien Han 2020-07-23 11:57:47 UTC
Yes, the cleanup policy in 4.5 does a metadata wipe on the drives, which means they can be re-used to install a cluster but not all the data have been removed. It's quick wipe.

Comment 7 Neha Berry 2020-07-23 12:21:36 UTC
(In reply to leseb from comment #6)
> Yes, the cleanup policy in 4.5 does a metadata wipe on the drives, which
> means they can be re-used to install a cluster but not all the data have
> been removed. It's quick wipe.

Is the cleanup policy you mentioned part of this ?

"""""

The StorageCluster should have the label set
 
cleanup.ocs.openshift.io="yes-really-destroy-data". 

If this label is set on the StorageCluster before the deletion request, then rook deletes the datadir automatically.

"""

Comment 8 Neha Berry 2020-07-23 13:23:39 UTC
Thank You Talur for the steps. 

Some comments & queries: 

> 1. Insert as step 1:
> =======================================================================================================
> “Add the label “cleanup.ocs.openshift.io=yes-really-destroy-data” to the StorageCluster.
> ``` oc label -n openshift-storage storagecluster --all cleanup.ocs.openshift.io=yes-really-destroy-data

1a). For LSO deployments, Will this script only wipe those disks which were used for OSDs and leave the rest as it is ?
1b)  The MON uses /var/lib/rook, so +1 that it will delete the DataDirHostPath content


> 2. Current Step: #5:  Delete the StorageCluster object.



2a) Step #5:  Since StorageCluster deletion deletes the SC and Label, don't we need to remove the explicit steps 10 and 11 ?

   Current Step 10 and 11:
    >Delete the storage classes with an openshift-storage provisioner listed in step 1.
    > Unlabel the storage nodes.



2b) If the StorageClass gets deleted before deletion of namespace(current Step #6) - we may hit this issue - need to test to confirm
 
   AFAIU the noobaa-db PVC deletion will get stuck in the absence of the SC, resulting in the namespace stuck in Terminating state(due to leftover resource). But will test and confirm



>3 Current Step 9: Wipe the disks for each of the local volumes listed in step 4 so that they can be reused

Do we need to skip this if we added the new Step#1 to use the "cleanup.ocs" label in StorageCLuster ?Will it not wipe the disks automatically on StorageCluster deletion ?


___________________________________________________________________________________________________________

> 4. Current Step #4

 List and note the backing local volume objects. If no results found, then skip step 8 & 9.

Include command to list the OCS nodes

AI: Move 9 i) to 4 and add a note in 9ii to use the nodes from Step 4

Current 9. i)List the storage nodes.

oc get nodes -l cluster.ocs.openshift.io/openshift-storage=

Comment 13 Jose A. Rivera 2020-08-05 16:29:10 UTC
Adding bug 1860431 as a blocker for this BZ, since the code for that merging will affect the documentation for uninstallation.

The following BZs were targeted for OCS 4.5, and have been moved to OCS 4.6 with the understanding that the documentation will be updated with workarounds:
* Bug 1860418 - OCS 4.5 Uninstall: Deleting StorageCluster leaves Noobaa-db PV in Released state(secret not found)
* Bug 1860670 - OCS 4.5 Uninstall External: Openshift-storage namespace in Terminating state as CephObjectStoreUser had finalizers remaining

Talur, please update this BZ with the required workarounds for UI and CLI.

Comment 17 Neha Berry 2020-08-18 11:30:09 UTC
Me and Sidhant verified the content in the https://docs.google.com/document/d/1BYMZFdyhXC8FMEe3lKlonKkUDmeDM_JsQ1uzLAP-Gns/edit# and it looks good to us.

Please share the preview link for final review.

thanks for all the help.

Comment 21 Ashish Singh 2020-08-20 14:51:15 UTC
*** Bug 1870648 has been marked as a duplicate of this bug. ***

Comment 27 Neha Berry 2020-08-27 15:22:55 UTC
One minor change

Replace "If you have created any PVCs as a part of configuring the monitoring stack" with "If you have created  PVCs as  part of configuring the monitoring stack"

Comment 28 Neha Berry 2020-08-27 17:59:08 UTC
(In reply to Neha Berry from comment #27)
> One minor change
> 
> Replace "If you have created any PVCs as a part of configuring the
> monitoring stack" with "If you have created  PVCs as  part of configuring
> the monitoring stack"

The gdoc is correct but the preview doc also needs the same change. Please ignore the extra spaces in the above comment

Step 2: 
"If you have created PVCs as part of configuring the monitoring stack"  -

Comment 33 Red Hat Bugzilla 2023-09-14 06:02:30 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days


Note You need to log in before you can comment on or make changes to this bug.