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

[SHACK-145] Add handling for multi-target errors #98

Merged
merged 2 commits into from
May 4, 2018

Conversation

marcparadise
Copy link
Member

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

@marcparadise marcparadise requested a review from a team April 30, 2018 19:52
@marcparadise marcparadise force-pushed the SHACK-145/multitarget/error-handling branch 2 times, most recently from 9cafe8f to 0d8a568 Compare April 30, 2018 20:05
# 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
Copy link
Member Author

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

Copy link
Contributor

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!

Copy link
Contributor

@jonsmorrow jonsmorrow left a 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

Copy link
Contributor

@tyler-ball tyler-ball left a 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
Copy link
Contributor

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")
Copy link
Contributor

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

Copy link
Member Author

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.

Copy link
Contributor

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
Copy link
Contributor

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)
Copy link
Contributor

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

Copy link
Member Author

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)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

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.
Copy link
Contributor

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

Copy link
Member Author

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.

@marcparadise marcparadise force-pushed the SHACK-145/multitarget/error-handling branch from d9a822c to c0e3000 Compare May 2, 2018 17:59
@marcparadise marcparadise changed the title Add handling for multi-target errors [SHACK-145] Add handling for multi-target errors May 2, 2018
@marcparadise marcparadise force-pushed the SHACK-145/multitarget/error-handling branch from c0e3000 to 96e9225 Compare May 2, 2018 18:01
cheeseplus
cheeseplus previously approved these changes May 4, 2018
Copy link

@cheeseplus cheeseplus left a 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

tyler-ball
tyler-ball previously approved these changes May 4, 2018
Copy link
Contributor

@tyler-ball tyler-ball left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tenor-144441147

jonsmorrow
jonsmorrow previously approved these changes May 4, 2018
@marcparadise marcparadise force-pushed the SHACK-145/multitarget/error-handling branch from 3a8f5e1 to aad6479 Compare May 4, 2018 15:50
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>
@marcparadise marcparadise force-pushed the SHACK-145/multitarget/error-handling branch from aad6479 to 99404b7 Compare May 4, 2018 15:53
@marcparadise marcparadise merged commit 7741db6 into master May 4, 2018
@chef-ci chef-ci deleted the SHACK-145/multitarget/error-handling branch May 4, 2018 15:57
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

Successfully merging this pull request may close these issues.

4 participants