MiddlewareErrors aren't trickled up the stack when 'exporting volumes'
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.
#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:
1. Make a volume named 'volume'.
2. cd /mnt/volume/ on the CLI.
3. Delete the volume.
1. The GUI should report that it couldn't remove the volume.
2. The volume shouldn't be unmounted/touched/etc.
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.
#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...