oVirt "destroy cluster" doesn't delete volumes created by oVirt CSI driver. In AWS EBS we "tag" volumes with the cluster ID so that the installer knows which volumes to delete. Check if we can use similar approach in oVirt.
If it is not possible to recognize volumes provisioned by the cluster on oVirt (e.g. by tags or labels), then 'openshift-install destroy cluster' should at least print a warning that volumes/snapshots are not deleted and admins should delete them manually. Please check with oVirt - maybe they have something else than tags and reassign to installer if it's really not possible to list the volumes.
@Benny and @Roy: could you help answering these questions, please? 1. Could you confirm that non-attached volumes created by oVirt CSI driver are NOT deleted when the cluster is destroyed? 2. If the answer is yes, could you confirm that it's NOT possible to add tags to volumes created by the driver? 3. If tagging volumes is not supported, is there any mechanism in oVirt that we could use to delete those volumes on cluster deletion? Like Jan posted above, if there's no way we can identify and delete those volumes on cluster deletion, we'll assign this bug to the installer team so that we emit a warning at least.
(In reply to Fabio Bertinatto from comment #2) > @Benny and @Roy: could you help answering these questions, please? > > 1. Could you confirm that non-attached volumes created by oVirt CSI driver > are NOT deleted when the cluster is destroyed? yes, confirmed > 2. If the answer is yes, could you confirm that it's NOT possible to add > tags to volumes created by the driver? quite sure its not supported. Michal any news about labels and/or tag support in RHV? > 3. If tagging volumes is not supported, is there any mechanism in oVirt that > we could use to delete those volumes on cluster deletion? > Need to think if can come up with something accurate and deterministic, like some constant naming scheme will use for disks to group them (disk.name = $clusterID/volumeID ?) > Like Jan posted above, if there's no way we can identify and delete those > volumes on cluster deletion, we'll assign this bug to the installer team so > that we emit a warning at least. Maybe leave this bug for exploring a solution and open one for the installer to create the WARN and remove the WARN if/when there will a way to destroy those.
(In reply to Roy Golan from comment #3) > > 2. If the answer is yes, could you confirm that it's NOT possible to add > > tags to volumes created by the driver? > > quite sure its not supported. > Michal any news about labels and/or tag support in RHV? nope. are those disks attached to any VM or are they all floating? > > 3. If tagging volumes is not supported, is there any mechanism in oVirt that > > we could use to delete those volumes on cluster deletion? > Need to think if can come up with something accurate and deterministic, like > some > constant naming scheme will use for disks to group them (disk.name = > $clusterID/volumeID ?) Name or Description fields sound feasible
(In reply to Michal Skrivanek from comment #4) > (In reply to Roy Golan from comment #3) > > > 2. If the answer is yes, could you confirm that it's NOT possible to add > > > tags to volumes created by the driver? > > > > quite sure its not supported. > > Michal any news about labels and/or tag support in RHV? > > nope. > > are those disks attached to any VM or are they all floating? > might be both cases I think, for example when you forcefully teardown a cluster that has running workloads. > > > 3. If tagging volumes is not supported, is there any mechanism in oVirt that > > > we could use to delete those volumes on cluster deletion? > > Need to think if can come up with something accurate and deterministic, like > > some > > constant naming scheme will use for disks to group them (disk.name = > > $clusterID/volumeID ?) > > Name or Description fields sound feasible
due to capacity constraints we will be revisiting this bug in the upcoming sprint
didn't get to it for 2 years, we don't plan any major changes in oVirt CSI driver functionality, closing