action #58664
closed[kernel][wicked] Needs to improve handling of situation when tcpdump is not installed
0%
Description
Observation¶
tcpdump commands fails
# ## START: t01_gre_tunnel_legacy
# tcpdump -s0 -U -w /tmp/tcpdumpt01_gre_tunnel_legacy.pcap >& /dev/null & export CHECK_TCPDUMP_PID=$!; echo ZUt9d-$?-
[1] 4252
ZUt9d-0-
[1]+ Exit 127 tcpdump -s0 -U -w /tmp/tcpdumpt01_gre_tunnel_legacy.pcap &> /dev/null
https://openqa.suse.de/tests/3518286#step/t01_gre_tunnel_legacy/89
Test suite description¶
Maintainer: asmorodskyi@suse.de jalausuch@suse.com cfamullaconrad@suse.de
Reproducible¶
Fails since (at least) Build 20191022
Expected result¶
Last good: None in QAM jobs, but it works on QA jobs.
Example of expected result: https://openqa.suse.de/tests/3507684
Further details¶
Updated by asmorodskyi over 4 years ago
- Subject changed from [kernel][wicked] Bug when running tcpdump command to [kernel][wicked] Needs to improve handling of situation when tcpdump is not installed
Updated by asmorodskyi over 4 years ago
127 - is actually "command not found" . which means behavior in this certain job is about when there is no tcpdump executable in system . As for me looks as expected behavior . To make it "perfect" I would probably change current flow to :
- detect in before_test if tcpdump is installed
- in case it is not :
- show single "red square" in before_test notifying that there is no tcpdump so there will be no dumps
- set some global variable making tcpdump related logic just to be skipped during pre_ / post_ run logic execution
Updated by okurz over 4 years ago
please reserve red squares for actual failed expectations which need human intervention to prevent it in the future. A single red square is of course a minor issue compared to a failing job however it is still something that should be eventually fixed and prevented.
Updated by jlausuch over 4 years ago
- Status changed from Workable to In Progress
- Target version changed from 454 to 445
Updated by jlausuch over 4 years ago
asmorodskyi wrote:
127 - is actually "command not found" .
Indeed
- detect in before_test if tcpdump is installed
- in case it is not :
- show single "red square" in before_test notifying that there is no tcpdump so there will be no dumps
- set some global variable making tcpdump related logic just to be skipped during pre_ / post_ run logic execution
I would not over-complicate things. We have a list of packages to install, I just added tcpdump. If it's installed, nothing will happen. If it's not, it will be installed.
Please review https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/8776
Updated by asmorodskyi over 4 years ago
okurz wrote:
please reserve red squares for actual failed expectations which need human intervention to prevent it in the future. A single red square is of course a minor issue compared to a failing job however it is still something that should be eventually fixed and prevented.
sorry but I fail to understand what you actually suggesting to do in case there is no tcpdump installed . Fail whole job ? Just ignore it totally by not producing even red square ?
Updated by jlausuch over 4 years ago
- Status changed from In Progress to Feedback
Updated by okurz over 4 years ago
asmorodskyi wrote:
I fail to understand what you actually suggesting to do in case there is no tcpdump installed . Fail whole job ? Just ignore it totally by not producing even red square ?
Fail whole job as the first and easy step. Next step is to fix the failure, e.g. by ensuring tcpdump is installed – as jlausuch does, alternatively by an approach as you suggested. This certainly depends if you want to test if tcpdump is preinstalled. I would assume that for the scope of QA Kernel & Network team you shouldn't care about that and just ensure tcpdump is installed before use, e.g. command -v tcpdump || zypper -n in tcpdump
Updated by asmorodskyi over 4 years ago
okurz wrote:
asmorodskyi wrote:
I fail to understand what you actually suggesting to do in case there is no tcpdump installed . Fail whole job ? Just ignore it totally by not producing even red square ?
Fail whole job as the first and easy step. Next step is to fix the failure, e.g. by ensuring tcpdump is installed – as jlausuch does, alternatively by an approach as you suggested. This certainly depends if you want to test if tcpdump is preinstalled. I would assume that for the scope of QA Kernel & Network team you shouldn't care about that and just ensure tcpdump is installed before use, e.g.
command -v tcpdump || zypper -n in tcpdump
disagree . wicked test case suppose to get failed state only if there is problem with wicked . As you can see from job which was reason of this ticket even when there is no tcpdump at all we have fully functional test case giving sane status about feature , why I should drop this behavior ?
Updated by jlausuch over 4 years ago
- Status changed from Feedback to Resolved
If we see those red squares giving error because the package is not installed, it's worth to fix it (with low-mid prio) as we did, but in this case we shouldn't mark the test as failed. Tcpdump is just an addition to provide more logs for further troubleshooting, but not mandatory feature from the wicked functional point of view.
Anyway, we will need to deal with this again (not only for tcpdump) when we get rid of before_test and move everything to autoyast profile.
I provided a quick fix and now everything is green.
https://openqa.suse.de/tests/3535309#
Updated by pcervinka over 3 years ago
- Target version changed from 457 to QE Kernel Done