Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhance error reporting #310

Open
JimSermersheim opened this issue Aug 2, 2023 · 0 comments
Open

Enhance error reporting #310

JimSermersheim opened this issue Aug 2, 2023 · 0 comments

Comments

@JimSermersheim
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant