Improve SSH multi line splitter parser #79
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Akrog
force-pushed
the
improve-multi-line-parser
branch
from
ded3f66
to
0ccf025
Compare
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
force-pushed
the
improve-multi-line-parser
branch
from
0ccf025
to
efd383c
Compare
|
lgtm |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR brings some improvements to the SSH multi line splitter parser to take into consideration some cases that happen when the connection is very slow as well as fix some of its 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 #78