-
Notifications
You must be signed in to change notification settings - Fork 112
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
[SHACK-145] Add handling for multi-target errors #98
Conversation
9cafe8f
to
0d8a568
Compare
# When running multiple jobs, exceptions are captured to the | ||
# job to avoid interrupting other jobs in process. This function | ||
# collects them and raises a MultiJobFailure if failure has occurred; | ||
# we do *not* differentiate between one failed jobs and multiple failed jobs |
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.
The question here is, did I say "one failed jobs" to underscore the point around not differentiating, or was it just a typo... :D
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.
Either way, you can't back down now!
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.
Looking good so far
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.
Some minor questions and issues I saw, it also looks like it needs some more test coverage. But otherwise coming along well!
# When running multiple jobs, exceptions are captured to the | ||
# job to avoid interrupting other jobs in process. This function | ||
# collects them and raises a MultiJobFailure if failure has occurred; | ||
# we do *not* differentiate between one failed jobs and multiple failed jobs |
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.
Either way, you can't back down now!
@@ -28,6 +28,10 @@ def default_location | |||
File.join(WS_BASE_PATH, "config.toml") | |||
end | |||
|
|||
def error_output_path | |||
File.join(File.dirname(log.location), "errors.txt") |
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.
Are we sure we want to have 3 different log files? I think I would rather have these errors show up in our normal log file
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.
I'm looking to provide a place where they can quickly look and see only the messages related to the failures that just occurred.
Relatedly, I'd been thinking it would be nice to give something like chef show errors
which does that for you.
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.
I like that idea! We could introduce chef errors show
and chef errors report
(with report sending a bug report to us)
@@ -33,13 +33,43 @@ def t | |||
DEFAULT_ERROR_NO = "CHEFINT001" | |||
|
|||
def self.show_error(e) | |||
# Name is misleading - it's unwrapping but also doing furtehr |
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.
further
@@ -33,13 +33,43 @@ def t | |||
DEFAULT_ERROR_NO = "CHEFINT001" | |||
|
|||
def self.show_error(e) |
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.
Lets just go ahead and change this to def self.unwrap_error(e)
then we can get rid of the comment below
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.
I moved the ugly bits into StandardErrorResollver. It's still ugly, but at least it's contained to one place more-or-less...
e.jobs.each do |j| | ||
# ErrorPrinter only instantiates with a WrappedError: | ||
wrapped = ChefWorkstation::WrappedError.new(j.exception, j.target_host) | ||
# This is silly, but necessary 'til we clean up (or do away with) |
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.
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.
+1
end | ||
end | ||
multispinner.auto_spin | ||
end | ||
|
||
def render_action(msg, prefix: "", &block) | ||
klass = Object.const_get("ChefWorkstation::UI::#{ChefWorkstation::Config.dev.spinner}") | ||
# TODO this should also accept a job. |
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.
Would this TODO mean accepting a job object instead of the &block
? I would like to see this TODO have more details, or we could just address it as part of this PR
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.
Yeah, it's to replace the block so we can use a consistent interface. I'd been on the fence about doing it in this PR; but it is actually pretty small and it does go together with these changes.
d9a822c
to
c0e3000
Compare
c0e3000
to
96e9225
Compare
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.
This makes sense and I really like the idea of adding a chef show errors
, thinking similar to journalctl style quick access to failures
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.
aad6479
3a8f5e1
to
aad6479
Compare
This wraps the actions for a multi-target command (converge in this case) in a Terminal::Job instance, which tracks its failure state. After all jobs are complete, this collects those that failed and sends them over to ErrorPrinter for formatting and capture to file, while a top level MULTI001 (basically: one or more jobs failed) error is shown to the user with the location of the errors file. Signed-off-by: Marc A. Paradise <marc.paradise@gmail.com>
Signed-off-by: Marc A. Paradise <marc.paradise@gmail.com>
aad6479
to
99404b7
Compare
This wraps the actions for a multi-target command
(converge in this case) in a Terminal::Job instance,
which tracks its failure state.
After all jobs are complete, this collects those that failed
and sends them over to ErrorPrinter for formatting and capture
to file, while a top level MULTI001 (basically: one or more jobs failed)
error is shown to the user with the location of the errors file.
Aside: renamed Terminal::Action to Terminal::Job to avoid confusion with ChefWorkstation::Action.
Signed-off-by: Marc A. Paradise marc.paradise@gmail.com