Bug 1548852

Summary:	[Docs][RFE][Admin] Engine allows forced removal of last master storage domain from Data Center
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Avital Pinnick <apinnick>
Component:	Documentation	Assignee:	Eli Marcus <emarcus>
Status:	CLOSED CURRENTRELEASE	QA Contact:	rhev-docs <rhev-docs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.2.0	CC:	aefrat, ahadas, ctomasko, emarcus, lsurette, mavital, mtessun, nsoffer, srevivo, sshmulev
Target Milestone:	ovirt-4.5.0	Keywords:	Documentation, FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	docscope 4.5
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-05-24 15:02:17 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1475893
Bug Blocks:

Description Avital Pinnick 2018-02-25 13:51:49 UTC

The Engine now allows forcibly removing the last master storage domain from the Data Center. The Data Center's status changes to "Uninitialized."

Comment 1 Lucy Bopf 2018-03-01 10:45:03 UTC

Maor, just looking at the development RFE, it seems like the use case for this was mainly (or only) site-to-site DR, which we've covered elsewhere. Is there any other use case we should document here?

Comment 2 Maor 2018-03-01 13:06:13 UTC

(In reply to Lucy Bopf from comment #1)
> Maor, just looking at the development RFE, it seems like the use case for
> this was mainly (or only) site-to-site DR, which we've covered elsewhere. Is
> there any other use case we should document here?

Just the regular scenario of import "dirty" storage domain, besides that I don't think so

Comment 3 Lucy Bopf 2018-03-29 01:50:33 UTC

(In reply to Maor from comment #2)
> (In reply to Lucy Bopf from comment #1)
> > Maor, just looking at the development RFE, it seems like the use case for
> > this was mainly (or only) site-to-site DR, which we've covered elsewhere. Is
> > there any other use case we should document here?
> 
> Just the regular scenario of import "dirty" storage domain, besides that I
> don't think so

Thanks, Maor. Can you elaborate a bit on the 'import "dirty" storage domain' scenario you mentioned, or point me to a source that describes it? It sounds like something we may have already supported and documented, and this RFE just adds an additional step, but I want to confirm.

Comment 4 Maor 2018-04-03 12:18:57 UTC

(In reply to Lucy Bopf from comment #3)
> (In reply to Maor from comment #2)
> > (In reply to Lucy Bopf from comment #1)
> > > Maor, just looking at the development RFE, it seems like the use case for
> > > this was mainly (or only) site-to-site DR, which we've covered elsewhere. Is
> > > there any other use case we should document here?
> > 
> > Just the regular scenario of import "dirty" storage domain, besides that I
> > don't think so
> 
> Thanks, Maor. Can you elaborate a bit on the 'import "dirty" storage domain'
> scenario you mentioned, or point me to a source that describes it? It sounds
> like something we may have already supported and documented, and this RFE
> just adds an additional step, but I want to confirm.

Sure, a "dirty" storage domain is a storage domain which its metadata indicats it is already attached to another data center.
Usually when a disaster occurs and the admin wants to recover its oVirt setup, the process was to import the old storage domains to the new engine, as part of the import/attach process, the storage domain had to be forced remove first from the old storage pool (by updating the SP_UUID field in the storage domain's metadata) and attach them back to the existing data center.

Now that we support force remove of master storage domain, the user should keep in mind that the SP_UUID field in the storage domain's metadata will be kept, and that when he will want to import that storage domain to another setup then a force remove operation should occur.

The force remove should be transparent to the user, so it is not a must to mention this, but since you asked about use cases, it is another example of the changed behavior.

Comment 6 Sandro Bonazzola 2019-01-28 09:40:07 UTC

This bug has not been marked as blocker for oVirt 4.3.0.
Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.

Comment 9 Sandro Bonazzola 2021-01-13 17:12:18 UTC

Didn't get into 4.4.3 and wasn't planned for 4.4.4. Resetting target milestone for being re-evaluated.

Comment 19 Sandro Bonazzola 2022-03-29 16:16:40 UTC

We are past 4.5.0 feature freeze, please re-target.

Comment 28 Eli Marcus 2022-05-24 15:02:17 UTC

updated and merged the PR