Some useful/important error messages are discarded #72
Description
(This is a repost of issue iocage/iocage#1301, which is one of those bulk-closed when the original maintainer pulled back. From inspecting the code here, I believe the issue is still present.)
When a jail is created, iocage_lib/ioc_create.py catches a number of exceptions, and discards them by raising instead a single RuntimeError with a generic "Template {self.release} not found!", which does not necessarily describe the actual error. I ran into this because I was trying to create a jail with a reused jail name, which led to a nonsensical error message: user error on my part, of course, but it took me a day, and some code-hacking, to discover what the actual error was.
What I saw was
# iocage create -t servicetemplate ip4_addr=192.168.128.5/24 defaultrouter=192.168.128.1 interfaces=vnet0:jpriv vnet=on -n motherhen
error in ioc_create, CalledProcessError Command '['zfs', 'snapshot', '-r', 'tank/iocage/templates/servicetemplate@motherhen']' returned non-zero exit status 1.
Error in create.py: error Template: motherhen not found!
Template: servicetemplate not found!
Created Templates:
servicetemplate
This was despite me being able to see that I definitely did have a servicetemplate template.
The Error in create.py line is reporting the RuntimeError raised in iocage_lib/ioc_create.py:180, which has already discarded the underlying error. It doesn't even do raise RuntimeError(...) from err.
I can appreciate the motivation here – the code is guessing what the underlying error is, and reporting that guess, in order to be helpful to the user. But the guess is wrong, and that makes the helpful intention worse than useless.
I've attached a zip file containing two diffs, not because I'm suggesting these would be a sensible patch (or PR), but in order to indicate where the code might need some UI attention, on the part of someone more familiar with it than me. I expect there's more than one place where this pattern appears. The edits here are the ones I made which let me see the underlying zfs snapshot error, and thus immediately realise the mistake I'd made.
As a concrete suggestion, it might be worth considering adding such ‘raw’ error reporting to a --verbose option (which I appreciate doesn't currently exist) or possibly to the --debug option output (though personally, I tend to think of --debug output as being for developers and desperate users, rather than providing the useful extra hints that I'd expect --verbose to provide).