-
Notifications
You must be signed in to change notification settings - Fork 2
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
Execute parseable yaml files during runStage #130
Execute parseable yaml files during runStage #130
Conversation
Make default executor Graph method not completely error out when encountering an unparseable yaml file. Signed-off-by: Fredrik Lönnegren <fredrik.lonnegren@suse.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Not sure about this one 🤔 Side node: We really need to find a way to export state/logs from a node to |
Good point! I will probably need to test this with an upgrade as well, since the health-checker might detect this... My original problem was that when installing a new system and accidentally leaving a malformed yaml in
Agree on the export of logs! |
Just giving a bit of more context of what we are trying to solve here. Error managing in yip and its integration in elemental is not sophisticated. If yip fails, by default, we are not marking as failed the actual service invoking it. The reason for that is to not prevent to the system to boot. So even if there are errors in yip the boot process continues normally unless we set the If a malformed yaml in Also a long standing idea we never implemented was to distinguish error types and react differently accordingly. As of today yip is binary: error true or false. We can't easily get the type of error (internal of yip or caused by yaml execution, etc.). |
I'm mostly concerned about "it somehow doesn't work" bug reports because somewhere, some yaml failed to get parsed and there's no way (besides ssh-ing into the node) to know what's going on. Currently such a problem is very obvious, simply because the node wouldn't even boot. I agree that this is bad (you can't ssh into a non-booted node) and good (errors bubble up spectacuously 😆 ) at the same time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Retracting my approval, after a second though I think we should do it slightly different.
In this commit we add back the error when trying to load a corrupt yaml file, but we still execute the entire graph first, making the command fail with an error about which path failed to load, but not breaking the execution for other yaml files. Signed-off-by: Fredrik Lönnegren <fredrik.lonnegren@suse.com>
@kkaempf @davidcassany How do you feel about the new implementation? It will return the loading-error after executing the valid yaml-files. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work 👍
Make default executor Graph method not completely error out when
encountering an unparseable yaml file.
Signed-off-by: Fredrik Lönnegren fredrik.lonnegren@suse.com