Project

General

Profile

Bug #1126

MiddlewareErrors aren't trickled up the stack when 'exporting volumes'

Added by Anonymous over 9 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Expected
Assignee:
-
Category:
GUI (new)
Target version:
-
Seen in:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

A number of scenarios when a volume / dataset are busy and are being removed have regressed again in the GUI. So now the GUI will once again claim that volume/dataset removal was successful when again, it's busted.

Ultimately, the problem is that [[MiddlewareErrors]] aren't trickled up the stack and dealt with appropriately in the volume deletion layer (or many other layers that call notifier), but once again.. this is an architectural issue that needs to be resolved on many different levels and needs to be death with and translated into something that dojango can grok properly so that commits are properly rolled back.

History

#1 Updated by Anonymous over 9 years ago

1. s/death/dealt/ ;) (dang autocorrect).
2. This applies to both UFS and ZFS.
3. This occurs on 8.0.3 and trunk @ r9310.
4. Forgot to include this in the ticket report:

Procedure:

1. Make a volume named 'volume'.
2. cd /mnt/volume/ on the CLI.
3. Delete the volume.

Expected result:

1. The GUI should report that it couldn't remove the volume.
2. The volume shouldn't be unmounted/touched/etc.

Actual result:

1. GUI reports that "volume" was successfully removed.

#2 Updated by Anonymous over 9 years ago

This is the problem (from storage.models):

            try:
                notifier().volume_export(self)
            except:
                pass

It shouldn't be swallowing all exceptions (this is true for 8.0.3 and trunk). Unfortunately the entire set of operations can't be 'rolled back' because [[FreeNAS]] has gone and stopped services, cascaded deletion operations, etc before this. However, I'm just going to remove the try-except because it violates POLA r1, as I now have to go back and clean up after something that claimed to complete successfully (we shouldn't expect our user base to be knowledgeable [[FreeBSD]] sysadmins). It's not really user friendly, but this change will make it fail more gracefully and ultimately is the lesser of two evils.

1. http://en.wikipedia.org/wiki/Principle_of_least_astonishment

#3 Updated by Anonymous over 9 years ago

I introduced some changes via r9317 and r9318 to deal with this issue, but this introduces other problems because the [[MountPoint]] object has been deleted from the database, but not the Volume object.

Working on a more complete solution in addition to the noted items above...

#4 Updated by Anonymous over 9 years ago

  • Status changed from Unscreened to Closed

Finally resolved via r9418.

Also available in: Atom PDF