You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 messageAnd 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.The text was updated successfully, but these errors were encountered: