Bug 1148679 - [Build 20190827] Broken yast command line tests for network in OpenQA
[Build 20190827] Broken yast command line tests for network in OpenQA
Status: VERIFIED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: YaST2
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Rodion Iafarov
Jiri Srain
https://openqa.opensuse.org/tests/101...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-08-29 07:06 UTC by Joaquín Rivera
Modified: 2020-09-30 07:08 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joaquín Rivera 2019-08-29 07:06:43 UTC
## Observation

openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-yast2_ui_devel@64bit fails in
[yast2_cmdline](https://openqa.opensuse.org/tests/1019461/modules/yast2_cmdline/steps/24)

After fixing some issues with missing package we can see again what is the status of the upstream test suites. There was recent work on https://github.com/yast/yast-network/pull/686 but they are failing probably for other reasons.

## Test suite description
Maintainer: zluo

yast2 upstream test suites.

https://progress.opensuse.org/issues/20206


## Reproducible

Fails since (at least) Build [20190728](https://openqa.opensuse.org/tests/995853)


## Expected result

Last good: (unknown) (or more recent)


## Further details

Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=DVD&machine=64bit&test=yast2_ui_devel&version=Tumbleweed)
Comment 1 David Diaz 2019-09-02 13:12:53 UTC
Joaquin, 

After taking a look at the available logs & assets in openQA I am not able to figure out what is failing. To understand how to follow debugging deeper, could you give me more information?

* What is the test trying to do?
* Which command is ending with a non-zero status?

Thanks in advance.
Comment 2 Joaquín Rivera 2019-09-03 05:36:29 UTC
It fails adding vlan here: https://github.com/yast/yast-network/blob/master/t/add-del.t#L30.
Example of successful run when interface exist for a different product (SLE-15-SP2):
https://openqa.suse.de/tests/3306681#step/yast2_cmdline/22
Comment 3 Michal Filka 2019-10-01 09:34:26 UTC
There were quite some changes in past weeks as we switched to completely new backend in yast2 network. Could you pls verify if the bug is still valid?
Comment 4 Joaquín Rivera 2019-10-01 13:20:12 UTC
I've just trigger new run and it still fails: https://openqa.opensuse.org/tests/1045425
Comment 5 Josef Reidinger 2019-10-03 12:03:20 UTC
Joaquin can you please retry it with yast2-network at least 4.2.16? I did there some fixes to CLI.

https://github.com/yast/yast-network/blob/master/package/yast2-network.changes#L11
Comment 6 Joaquín Rivera 2019-10-07 05:23:10 UTC
Similar issue with yast2-network 4.2.17-1.1: https://openqa.opensuse.org/tests/1049949#step/yast2_cmdline/24
Comment 7 Josef Reidinger 2019-10-07 06:26:38 UTC
(In reply to Joaquín Rivera from comment #6)
> Similar issue with yast2-network 4.2.17-1.1:
> https://openqa.opensuse.org/tests/1049949#step/yast2_cmdline/24

sorry, I made typo. In link it is correct. Version with fix is 4.2.19. So at least this version is needed. So if you can trigger it with at least that version ( should be probably now in staging )
Comment 8 Joaquín Rivera 2019-10-07 08:17:09 UTC
we are doing source install on this particular job, so even for this staging branch yast2-networt 4.2.19-3.1 is available: http://rivera-workstation.suse.cz/tests/162#step/yast2_cmdline/12 it is still using yast2-network 4.2.17: http://rivera-workstation.suse.cz/tests/162#step/yast2_cmdline/24. It could be that repos are not syncronized as we don't run this job in staging and I'm creating it only for the purpose of testing, so unless you think something is missing in source repo, we should wait for next build to see how it went.
Comment 9 Rodion Iafarov 2019-11-06 08:30:22 UTC
Scenario still fails with yast2-network 4.2.23-1.1.
Comment 10 Stefan Hundhammer 2019-12-03 11:18:15 UTC
Joaquin, please remember to reset the "needinfo" flag when you provided requested information; otherwise a bug will remain under the radar for a long time.
Comment 12 Josef Reidinger 2020-01-06 11:05:48 UTC
Rodion - reason why it fails is now clearly written in test ( I did some improvements ).

yast2-network CLI require to have working wicked. Which is not your case ( do not ask me for such limitation ) - so it failed with not OK wicked not running ( in fact wicked is dead as can be seen at https://openqa.opensuse.org/tests/1077392#step/yast2_cmdline/24

So I worry openqa test should ensure that wicked is running. Is it possible?
Comment 13 Rodion Iafarov 2020-01-08 10:03:51 UTC
(In reply to Josef Reidinger from comment #12)
> Rodion - reason why it fails is now clearly written in test ( I did some
> improvements ).
> 
> yast2-network CLI require to have working wicked. Which is not your case (
> do not ask me for such limitation ) - so it failed with not OK wicked not
> running ( in fact wicked is dead as can be seen at
> https://openqa.opensuse.org/tests/1077392#step/yast2_cmdline/24
> 
> So I worry openqa test should ensure that wicked is running. Is it possible?

Hey Josef! We can add such check. Other point is of course if then it makes sense to have this test executed on TW, as NM is default there. We will take care of this.
Comment 14 Rodion Iafarov 2020-01-08 10:24:12 UTC
I've filed https://progress.opensuse.org/issues/61901 to address this issue. As per Josef's hint, we will also add check for wicked being running to simplify investigation in case of failures.
Comment 15 Josef Reidinger 2020-01-27 08:48:33 UTC
OK, I am not sure to who reassign it as it is problem of test env and not yast ( well, yast is a kind of dummy here to allow only wicked, but same is in UI, which prevents operations till user switch to wicked ).
Rodion feel free to reassign whoever from openqa team will work on it.
Comment 16 Rodion Iafarov 2020-01-27 09:37:09 UTC
(In reply to Josef Reidinger from comment #15)
> OK, I am not sure to who reassign it as it is problem of test env and not
> yast ( well, yast is a kind of dummy here to allow only wicked, but same is
> in UI, which prevents operations till user switch to wicked ).
> Rodion feel free to reassign whoever from openqa team will work on it.

As we use progress for this ticker, I will resolve this one and we will address the issue in progress. Thanks!
Comment 17 Joaquín Rivera 2020-09-30 07:08:23 UTC
Addressed in progress.