QA » openQA Project » openQA Tests

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 :

1. detect in before_test if tcpdump is installed
2. 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

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.

asmorodskyi wrote:

127 - is actually "command not found" .

Indeed

1. detect in before_test if tcpdump is installed
2. 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

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 ?

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

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 ?