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

use a stricter comparison so knife ssh only fails if --exit-on-error #6582

Merged
merged 3 commits into from
Jan 29, 2018
Merged

use a stricter comparison so knife ssh only fails if --exit-on-error #6582

merged 3 commits into from
Jan 29, 2018

Conversation

sarkis
Copy link
Contributor

@sarkis sarkis commented Nov 11, 2017

Description

This is required due to config[:on_error] being set here:

config[:on_error] ||= :skip
. This conditional will allow ssh_commands that return non-zero status to be executed on entire pool of servers returned by the knife query when --exit-on-error is NOT specified.

Issues Resolved

#6581

Check List

@sarkis sarkis requested a review from a team November 11, 2017 03:31
@sarkis sarkis changed the title use a stricter comparison here so knife ssh only fails if use a stricter comparison so knife ssh only fails if --exit-on-error Nov 11, 2017
--exit-on-error

Signed-off-by: Sarkis Varozian <svarozian@gmail.com>
@coderanger
Copy link
Contributor

That whole option seems like something is very wrong. It's declared as a boolean type but in some places we expect a symbol. And the proc on it doesn't actually check the key value which means it doesn't actually matter if you set the option or not.

@sarkis
Copy link
Contributor Author

sarkis commented Nov 11, 2017

@coderanger thanks for taking a look -
I think the way it's meant to be used where --exit-on-error is set (true) or not (false) - we should keep this as a boolean. I simplified this a bit - not sure the proc is necessary as you mentioned in the previous comment. Let me know what you think of this approach when you have a moment.

I did test and make sure this new way of doing it is working right.. the one thing I didn't test is if it encounters an ssh connection error - trying to get that tested now.

Signed-off-by: Sarkis Varozian <svarozian@gmail.com>
@sarkis
Copy link
Contributor Author

sarkis commented Nov 11, 2017

I was able to successfully test all edge cases I could think of here - including testing ssh connection issues to one of the servers returned in the knife ssh query.

@lamont-granquist
Copy link
Contributor

were we trying too hard to be backcompat at some point and only half converted it from boolean to a multi-valued symbol?

@stevendanna
Copy link
Contributor

@lamont-granquist The other way around. It started as multi-value config that was really only used when calling this plugin from other plugins like this:

https://github.com/chef/chef/blob/master/lib/chef/knife/bootstrap.rb#L451

I'm in favor of moving it to a boolean if we don't think anyone else is using it. If we do move it to a boolean, lets fixup the usage in bootstrap above as well.

Signed-off-by: Sarkis Varozian <svarozian@gmail.com>
@sarkis
Copy link
Contributor Author

sarkis commented Nov 13, 2017

Since this was set to :raise in bootstrap - i wanted to leave the same behavior which after moving to boolean would be the same as set to true. Hopefully, I didn't misinterpret this ... as far as I can tell that covers all instances of ssh.confg[:on_error] in this repo - let me know if a PR may be required elsewhere...

@mal
Copy link
Contributor

mal commented Dec 12, 2017

Constantly running into this and having to remember to add || true to my commands 🙁 Tested out this patch and can confirm it fixes the basic knife ssh use case. Thanks for the patch, it'd be really good to see it in the next stable 👍

Copy link
Contributor

@thommay thommay left a comment

Choose a reason for hiding this comment

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

tenor-91742340

@thommay thommay merged commit 213477f into chef:master Jan 29, 2018
@thommay
Copy link
Contributor

thommay commented Jan 29, 2018

@sarkis thanks for your contribution!

@lock
Copy link

lock bot commented Apr 14, 2018

This thread has been automatically locked because it has not had recent activity. Please open a new issue for related bugs and link to relevant comments in this thread.

@lock lock bot locked and limited conversation to collaborators Apr 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants