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

SSH multi-line-parser fails on slow connections #78

Open
Akrog opened this issue May 29, 2020 · 0 comments · May be fixed by #79
Open

SSH multi-line-parser fails on slow connections #78

Akrog opened this issue May 29, 2020 · 0 comments · May be fixed by #79

Comments

@Akrog
Copy link

Akrog commented May 29, 2020

On slow SSH connections both parsers, default and multi-line, fail because the responses are somewhat different than what they expect:

  • We don't get the initial stdin dump of the commands we've sent before the first prompt.
  • We get empty prompts with no command, as if we had entered an additional enter key.

Fixing the default parser would be more complicated, but the multi-line one should be able to support these cases.

Akrog added a commit to Akrog/python-3parclient that referenced this issue May 29, 2020
This patch improves the SSH multi line splitter parser to take into some
cases that were not covered as well as fix some of the tests.

Code fixes:

- On slow SSH connections we may not get the initial dump of stdin in
  the response, so looking for the "exit" command we sent will never
  find it and the parsing will fail.  We now look for the prompt and
  ignore whether we have the stdin data or not, since it's not really
  relevant.

- Sometimes we get empty prompts in the SSH response, which either break
  the current parsing or makes us return bad data.  We now remove all
  empty prompts.

Code improvements:

- We were always removing the last 2 lines from the response without
  actually checking if these 2 lines are the exit command and an empty
  line.  Now we search for the final exit command that we execute to
  determine the end of the valid output data.

- If the output data has any "\r" at the end of a line the parser
  returns them, which we shouldn't. They should be removed just like we
  remove the "\r\n" when splitting the lines.

Test fixes in HPE3ParClientMockSSHTestCase::test_strip_input_from_output:

- In a couple of places tests are passing [cmd, X, Y] to the parser
  expecting a failure, which we get, and we think everything is working
  as expected, but the failure is not for the reasons we want, so we are
  not testing anything.  By passing that data we are effectively passing
  [['foo', '-v'], X, Y] which will break the parser because that's
  "garbage".

- The data passed and expected in the success case can be misleading, as
  it doesn't include the exit prompt and doesn't expect the footer to be
  returned, but the footer should be returned and parsing a command that
  doesn't have the last exit command is not valid.

Closes hpe-storage#78
@Akrog Akrog linked a pull request May 29, 2020 that will close this issue
Akrog added a commit to Akrog/python-3parclient that referenced this issue May 29, 2020
This patch improves the SSH multi line splitter parser to take into
account some cases that were not covered as well as fix some of the tests.

Code fixes:

- On slow SSH connections we may not get the initial dump of stdin in
  the response, so looking for the "exit" command we sent will never
  find it and the parsing will fail.  We now look for the prompt and
  ignore whether we have the stdin data or not, since it's not really
  relevant.

- Sometimes we get empty prompts in the SSH response, which either break
  the current parsing or makes us return bad data.  We now remove all
  empty prompts.

Code improvements:

- We were always removing the last 2 lines from the response without
  actually checking if these 2 lines are the exit command and an empty
  line.  Now we search for the final exit command that we execute to
  determine the end of the valid output data.

- If the output data has any "\r" at the end of a line the parser
  returns them, which we shouldn't. They should be removed just like we
  remove the "\r\n" when splitting the lines.

Test fixes in HPE3ParClientMockSSHTestCase::test_strip_input_from_output:

- In a couple of places tests are passing [cmd, X, Y] to the parser
  expecting a failure, which we get, and we think everything is working
  as expected, but the failure is not for the reasons we want, so we are
  not testing anything.  By passing that data we are effectively passing
  [['foo', '-v'], X, Y] which will break the parser because that's
  "garbage".

- The data passed and expected in the success case can be misleading, as
  it doesn't include the exit prompt and doesn't expect the footer to be
  returned, but the footer should be returned and parsing a command that
  doesn't have the last exit command is not valid.

Closes hpe-storage#78
Akrog added a commit to Akrog/python-3parclient that referenced this issue May 29, 2020
This patch improves the SSH multi line splitter parser to take into
account some cases that were not covered as well as fix some of the tests.

Code fixes:

- On slow SSH connections we may not get the initial dump of stdin in
  the response, so looking for the "exit" command we sent will never
  find it and the parsing will fail.  We now look for the prompt and
  ignore whether we have the stdin data or not, since it's not really
  relevant.

- Sometimes we get empty prompts in the SSH response, which either break
  the current parsing or makes us return bad data.  We now remove all
  empty prompts.

Code improvements:

- We were always removing the last 2 lines from the response without
  actually checking if these 2 lines are the exit command and an empty
  line.  Now we search for the final exit command that we execute to
  determine the end of the valid output data.

- If the output data has any "\r" at the end of a line the parser
  returns them, which we shouldn't. They should be removed just like we
  remove the "\r\n" when splitting the lines.

Test fixes in HPE3ParClientMockSSHTestCase::test_strip_input_from_output:

- In a couple of places tests are passing [cmd, X, Y] to the parser
  expecting a failure, which we get, and we think everything is working
  as expected, but the failure is not for the reasons we want, so we are
  not testing anything.  By passing that data we are effectively passing
  [['foo', '-v'], X, Y] which will break the parser because that's
  "garbage".

- The data passed and expected in the success case can be misleading, as
  it doesn't include the exit prompt and doesn't expect the footer to be
  returned, but the footer should be returned and parsing a command that
  doesn't have the last exit command is not valid.

Closes hpe-storage#78
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 a pull request may close this issue.

1 participant