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

Resolve peer address before assigning it's IP to member #1634

Merged
merged 1 commit into from Jan 13, 2017

Conversation

Projects
None yet
7 participants
@elliott-davis
Member

elliott-davis commented Jan 13, 2017

The previous behavour of a peer binding would not resolve a dns entry before trying to unwrap a string. This caused a thread panic that would kill the supervisor.
The new behavour will try and resolve the ip's for dns entries and die if it is unable to do so.

@thesentinels

This comment has been minimized.

Show comment
Hide comment
@thesentinels

thesentinels Jan 13, 2017

Contributor

Thanks for the pull request! Here is what will happen next:

  1. Your PR will be reviewed by the maintainers
  2. If everything looks good, one of them will approve it, and your PR will be merged.

Thank you for contributing!

Contributor

thesentinels commented Jan 13, 2017

Thanks for the pull request! Here is what will happen next:

  1. Your PR will be reviewed by the maintainers
  2. If everything looks good, one of them will approve it, and your PR will be merged.

Thank you for contributing!

Resolve peer address before assigning it's IP to member
The previous behavour of a peer binding would not resolve a dns entry before trying to unwrap a string. This caused a thread panic that would kill the supervisor.
The new behavour will try and resolve the ip's for dns entries and die if it is unable to do so.

Signed-off-by: Elliott Davis <edavis@chef.io>
@chefsalim

Looks good to me :)

@mwrock

This comment has been minimized.

Show comment
Hide comment
@mwrock

mwrock Jan 13, 2017

Contributor

Awesome like a possom!

Rerunning travis and appveyor whose breaks look unrelated.

Contributor

mwrock commented Jan 13, 2017

Awesome like a possom!

Rerunning travis and appveyor whose breaks look unrelated.

@mwrock

This comment has been minimized.

Show comment
Hide comment
@mwrock

mwrock Jan 13, 2017

Contributor

@thesentinels approve

Contributor

mwrock commented Jan 13, 2017

@thesentinels approve

@thesentinels

This comment has been minimized.

Show comment
Hide comment
@thesentinels

thesentinels Jan 13, 2017

Contributor

🤘 I am testing your branch against master before merging it. We do this to ensure that the master branch is never failing tests.

Contributor

thesentinels commented Jan 13, 2017

🤘 I am testing your branch against master before merging it. We do this to ensure that the master branch is never failing tests.

@thesentinels

This comment has been minimized.

Show comment
Hide comment
@thesentinels
Contributor

thesentinels commented Jan 13, 2017

:neckbeard: Travis CI has started testing this PR.

@thesentinels

This comment has been minimized.

Show comment
Hide comment
@thesentinels

thesentinels Jan 13, 2017

Contributor

💖 Travis CI reports this PR passed.

It always makes me feel nice when humans approve of one anothers work. I'm merging this PR now.

I just want you and the contributor to answer me one question:

gif-keyboard-3280869874741411265

Contributor

thesentinels commented Jan 13, 2017

💖 Travis CI reports this PR passed.

It always makes me feel nice when humans approve of one anothers work. I'm merging this PR now.

I just want you and the contributor to answer me one question:

gif-keyboard-3280869874741411265

@thesentinels thesentinels merged commit cf84ee3 into master Jan 13, 2017

3 checks passed

DCO This commit has a DCO Signed-off-by line
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@thesentinels thesentinels deleted the resolve_peer_host branch Jan 13, 2017

@adamhjk

This fixes the issue, which is great - but the meta-problem was that we panicked on bad input, and this keeps that trend. Before we merge this, we should add an Error class for it, and return that rather than panicking the thread.

@@ -87,7 +87,10 @@ impl Manager {
None));
outputln!("Butterfly Member ID {}", server.member_id());
for peer_addr in gconfig().gossip_peer() {
let addr: SocketAddr = peer_addr.parse().unwrap();
let addrs: Vec<SocketAddr> = peer_addr.to_socket_addrs()
.expect("Unable to resolve domain")

This comment has been minimized.

@adamhjk

adamhjk Jan 13, 2017

Contributor

This function returns a Result - we should add an error for failure to resolve, and return an error, so that the tooling can handle things like pretty printing the error.

@adamhjk

adamhjk Jan 13, 2017

Contributor

This function returns a Result - we should add an error for failure to resolve, and return an error, so that the tooling can handle things like pretty printing the error.

This comment has been minimized.

@mwrock

mwrock Jan 13, 2017

Contributor

Doesn't the expect mostly take care of this? It conveys how the input failed and if it does fail, I don't see harm in the panic as long as its made clear to the user why.

@mwrock

mwrock Jan 13, 2017

Contributor

Doesn't the expect mostly take care of this? It conveys how the input failed and if it does fail, I don't see harm in the panic as long as its made clear to the user why.

This comment has been minimized.

@adamhjk

adamhjk Jan 14, 2017

Contributor

The application knows how to exit cleanly with an error message, with pretty colors and details about precisely where the error was generated in the source. Panic makes sure you can't do that.

Also, this gives optionality to the caller - if you wanted to panic, you easily can.

@adamhjk

adamhjk Jan 14, 2017

Contributor

The application knows how to exit cleanly with an error message, with pretty colors and details about precisely where the error was generated in the source. Panic makes sure you can't do that.

Also, this gives optionality to the caller - if you wanted to panic, you easily can.

@fnichol fnichol added Bug labels Jan 19, 2017

@eeyun eeyun added A-supervisor C-bug and removed Supervisor labels Jun 6, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment