Description
Currently, com.suse.salt.netapi.utils.SaltErrorUtils will look for two classes of errors (FunctionNotAvailable, ModuleNotSupported). There are other classes that could be handled (I don't remember the circumstances for all of these, and some could be unique to running the salt CLI command):
TypeError encountered executing *
* Passed invalid arguments *
ERROR executing *
ERROR: *
The following keyword arguments are not valid *
Then there is the exception class The minion function caused an exception which is followed by a Traceback and exception message
And then there are 3 messages that indicate the func never even made it to a minion (again, some may be unique to the salt CLI):
Minion did not return
The master is not responding
No minions matched the target
I could volunteer to start adding some of these (those that are known to happen when using the salt-api server). However, the current design is not fun in terms of maintaining. It seems each new SaltError impl casues the SaltError fold method's signature to need to change, thus requiring all existing SaltError impls to change. I don't really understand the pattern, so I don't' have a suggested re-design of that, but would prefer something simpler before embarking on adding more error handling.