[logAnalyzer] Fix the issue of unmatched start and end mark #831
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
Previous PR #822 broke the log analyzer. This commit is to fix the issue introduced by PR #822. PR #822 is to replace the method of getting timestamp from ansible_date_time to the pipe plugin. Log analyzer needs a variable testname_unique to have timestamp in its value. Script run_command_with_log_analyzer.yml uses include_vars to include variables defined in vars/run_config_test_vars.yml. Ansible includes variables dynamically when 'include_vars' is used. Consequence is that the testname_unique variable defined in the vars/run_config_test_vars.yml is re-evaluated when it is referenced. This caused log analyzer to use inconsistent start and end mark. To fix this issue, a unique timestamp is always generated before include_vars. Then the timestamp is feed to the testname_unique defined in the vars file. This approach can guarantee consistent run id for each log analyzer execution. And the run id would also be different for different log analyzer execution. The other scripts changed in this commit have the similar issue. Signed-off-by: Xin Wang <xinw@mellanox.com>
yxieca
approved these changes
Mar 20, 2019
yxieca
pushed a commit
that referenced
this pull request
Mar 20, 2019
Previous PR #822 broke the log analyzer. This commit is to fix the issue introduced by PR #822. PR #822 is to replace the method of getting timestamp from ansible_date_time to the pipe plugin. Log analyzer needs a variable testname_unique to have timestamp in its value. Script run_command_with_log_analyzer.yml uses include_vars to include variables defined in vars/run_config_test_vars.yml. Ansible includes variables dynamically when 'include_vars' is used. Consequence is that the testname_unique variable defined in the vars/run_config_test_vars.yml is re-evaluated when it is referenced. This caused log analyzer to use inconsistent start and end mark. To fix this issue, a unique timestamp is always generated before include_vars. Then the timestamp is feed to the testname_unique defined in the vars file. This approach can guarantee consistent run id for each log analyzer execution. And the run id would also be different for different log analyzer execution. The other scripts changed in this commit have the similar issue. Signed-off-by: Xin Wang <xinw@mellanox.com>
1 task
lguohan
pushed a commit
that referenced
this pull request
Mar 28, 2019
…cted (#844) PR #831 does not fully fix the issue introduced by PR #822. Ansible's include_vars module could not override variable value previous defined by set_fact. Variables in vars/run_config_test_vars.yml may still have old value. The change is to avoid using include_vars. The variables defined in run_config_test_vars.yml are moved into script run_command_with_log_analyzer.yml. The vars files are deleted. The same change is made to other scripts using the same pattern. Signed-off-by: Xin Wang <xinw@mellanox.com>
yxieca
pushed a commit
that referenced
this pull request
Mar 28, 2019
…cted (#844) PR #831 does not fully fix the issue introduced by PR #822. Ansible's include_vars module could not override variable value previous defined by set_fact. Variables in vars/run_config_test_vars.yml may still have old value. The change is to avoid using include_vars. The variables defined in run_config_test_vars.yml are moved into script run_command_with_log_analyzer.yml. The vars files are deleted. The same change is made to other scripts using the same pattern. Signed-off-by: Xin Wang <xinw@mellanox.com>
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.
Description of PR
Summary:
Fixes # (issue)
Previous PR #822 broke the log analyzer. This commit is to fix the issue
introduced by PR #822.
PR #822 is to replace the method of getting timestamp from
ansible_date_time to the pipe plugin. Log analyzer needs a variable
testname_unique to have timestamp in its value.
Script run_command_with_log_analyzer.yml uses include_vars to include
variables defined in vars/run_config_test_vars.yml. Ansible includes
variables dynamically when 'include_vars' is used. Consequence is that
the testname_unique variable defined in the vars/run_config_test_vars.yml
is re-evaluated when it is referenced. This caused log analyzer to use
inconsistent start and end mark.
To fix this issue, a unique timestamp is always generated before
include_vars. Then the timestamp is feed to the testname_unique
defined in the vars file. This approach can guarantee consistent
run id for each log analyzer execution. And the run id would also
be different for different log analyzer execution.
The other scripts changed in this commit have the similar issue.
Type of change
Approach
How did you do it?
Ansible include_vars is dynamic. To avoid the pipe for variable testname_unique in vars file being repeatedly evaluated, a unique_timestamp variable is initialized before include_vars. And in vars file, replace the pipe plugin with the variable unique_timestamp just initialized.
How did you verify/test it?
Tested on Mellanox platform.
Any platform specific information?
No
Supported testbed topology if it's a new test case?
Documentation