Host resource ping method should return stdout

[justincmoy]

Prior to this PR, the ping method would return the following for nc (stderr output):

> echo | nc -v -w 1 127.0.0.1 1900 1>/dev/null
Ncat: Version 6.40 ( http://nmap.org/ncat )
Ncat: Connected to 127.0.0.1:1900.
Ncat: Connection reset by peer.

After this PR, the ping method would return the following for nc (stdout output):

> echo | nc -v -w 1 127.0.0.1 1900 2>/dev/null
DOWN

[adamleff]

@justincmoy I'm 👎 on this as-written because the STDERR from netcat is actually quite useful in troubleshooting, and the STDOUT isn't nearly as useful, especially since many far-end targets will not respond with any data when you send an empty message.

Can you explain the reason for this proposed change?

[justincmoy]

@adamleff Sure thing. We have an haproxy agent-check that connects to an xinetd daemon, similar to this blog post: https://icicimov.github.io/blog/server/HAProxy-dynamically-adjust-server-weight-using-external-agent/

We would like to write an inspec test that verifies connecting to our specified xinetd port returns expected output.

Edit:
Would it make sense to have these methods return an additional key corresponding to the stdout? And then a public method that can access it?

[adamleff]

Thanks for sharing your use case. It makes the case for exposing both sets of content.

I'd like to avoid using stdout and stderr as the method names since we may change the implementation in the future and an end-user shouldn't need to know how we gathered the data. And if we want to provide both sets of output to the user, output isn't specific enough anymore.

What if we call the stderr output connection_output and the stdout output socket_output and have method names that match that?

[justincmoy]

👍 I'll update this PR accordingly

[adamleff]

@justincmoy this looks great, thank you. :)

[chris-rock]

why not call it straight stdout and stderr

[justincmoy]

This came up in an earlier comment. It's to hide the implementation details from the end user.

[chris-rock]

Got ya. Thank you, I misread this

[adamleff]

As stated in #1927 (comment). Netcat's stdout and stderr is what we're using now, but if we iterate on this in the future and find a tool that doesn't use stdout/stderr the same way, then we're training the user on a specific implementation.

There are two bits of data being exposed: output about the connection setup, and the output from the socket itself after the connection is established.

I proposed connection_output and socket_output accordingly, and I think the _output piece is important so someone doesn't believe these can be manipulated -- it's simply the output of the connection attempt. I'm totally fine with removing _output if it helps calm any concerns.

[adamleff]

@justincmoy after an internal discussion, would you mind changing the method names and the hash keys to remove the _output from them?

connection_output => connection
socket_output => socket

[chris-rock]

Thank you @justincmoy and @adamleff