I am changing this from RFE to a bug and setting the proper flags.
This is a flaw in the design and can lead into data loss on customer setups.
(In reply to Marina from comment #10)
> I am changing this from RFE to a bug and setting the proper flags.
> This is a flaw in the design and can lead into data loss on customer setups.
Please share a sensible reproduction to this issue - deleting the OVF store isn't something anyone should do.
Until then, targeting to a more appropriate version than 4.0.z.
It's not only preventing to Detach/Deactivate if the OVFs updated. All the images must be in healthy condition before detaching, see BZ 1384321.
Allon, do I understand correctly that OVF store should be updated once detach(maintenance?) command is issued? If this is the flow, then I think the problem is that for some reason the update didn't happen before detaching and the information was lost.
I do not think this bug is about preventing SD detachment while performing the update, but detaching it without having the updated information pushed to the OVF store on the domain.
(In reply to Marina from comment #16)
> but detaching it without having the updated information pushed
> to the OVF store on the domain.
This depends on an RFE that currently isn't targeted for 4.2 - pushing out.
Yaniv L, if you disagree, let's discuss and see if this RFE should be brought into 4.2.
Eyal - what's the status here? The BZ is in post, but I see no patches attached to it.
*** Bug 1477147 has been marked as a duplicate of this bug. ***
Eyal, can we move this bug to VERIFIED based on
Moving to VERIFIED.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.