QA (public) » openQA Project (public) » openQA Tests (public)

It was determined by the maintainer of the test, see https://suse.slack.com/archives/C02CANHLANP/p1652780831226729?thread_ts=1652779208.640379&cid=C02CANHLANP

Thanks for the context!

A note for qe-core: we might want to move this ticket to security, since the maintainer is in that squad. It is still on the core job group because security is not migrated yet.

Hello，

As discussed with Lili offline, we would suggest to file a new bug against the issue

https://openqa.suse.de/tests/8769149#step/usr_sbin_smbd/84

It passed on SLES15SP4 run http://openqa.suse.de/tests/8753087#step/usr_sbin_smbd/64

BR//Richard.

@mgrifalconi，

Sorry for the late reply since just back from a meeting.

I agree with you that this case is related to security test area. however we can't reproduce it with the latest SLES15SP4 openQA job. and I checked the latest o3 job, it passed as well https://openqa.opensuse.org/tests/2368888

So, I would suggest your team to file the bug against to dev team since it can only be seen with maintenance update. [As far as I know, QE security team will only fix the test code issues for QEM security test cases, but please correct me if I was wrong]

@llzhao, can you please provide the manual test steps here if possible?

BR//Richard.

I am on "Squad rotation" so Richard is my replacement.

More info helps you to debug:

1. Manual test cases: https://bugzilla.suse.com/tr_show_case.cgi?case_id=1728938
2. Some pkg's version

It was passed on last good build Build20220515-1 (15sp3): https://openqa.suse.de/tests/8763654#step/usr_sbin_smbd/8
The samba-* version is 4.15.4
The yast2-samba-client version is 4.3.5
The yast2-samba-server version is 4.3.4

It keeps failing on latest build and start fail at Build20220516-1
https://openqa.suse.de/tests/8769149#step/usr_sbin_smbd/26
The samba-* version is 4.15.7
The yast2-samba-client version is 4.3.5
The yast2-samba-server version is 4.3.4

It is passed on sle15sp4 and TW.

So it seems a product bug.

I fond Felix Niederwanger from Maintenance QE 1 (Vit Pelcak) already opened a bug to the fail.
https://bugzilla.suse.com/attachment.cgi?id=859175&action=edit
https://bugzilla.suse.com/show_bug.cgi?id=1199860

Also Paolo made a workaround (already merged) for test code: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/14976/files

@mgrifalconi we found Felix Niederwanger already filed a bug 3 days ago to track this fail.
https://bugzilla.suse.com/show_bug.cgi?id=1199860 before I and Richard revolved again.
Usually when we found a product issue we will search the bugzilla firstly to check if anybody already filed a one to avoid any duplication.

Also according to https://confluence.suse.com/pages/viewpage.action?spaceKey=openqa&title=QEM+openQA+review+guide
We suppose openQA reviewer should file the bug as we had suggested it seems to be a product bug.

llzhao wrote:

Also according to https://confluence.suse.com/pages/viewpage.action?spaceKey=openqa&title=QEM+openQA+review+guide
We suppose openQA reviewer should file the bug as we had suggested it seems to be a product bug.

Just to make sure that this is understood. As documented on https://confluence.suse.com/display/openqa/QEM+openQA+review+guide the idea is that each squad does the openQA review. Quoting the guide

When a test case fails, basic triage and steps as shown in Fig. 1 are done. Test dev squad is expected to make the decision what to do ASAP but is free to pick the best approach

meaning that the security squad conducts the review and ensures that no false-positive or non-critical test failures prevent further automatic acceptance of maintenance tests.

okurz wrote:

llzhao wrote:

Also according to https://confluence.suse.com/pages/viewpage.action?spaceKey=openqa&title=QEM+openQA+review+guide
We suppose openQA reviewer should file the bug as we had suggested it seems to be a product bug.

Just to make sure that this is understood. As documented on https://confluence.suse.com/display/openqa/QEM+openQA+review+guide the idea is that each squad does the openQA review. Quoting the guide

When a test case fails, basic triage and steps as shown in Fig. 1 are done. Test dev squad is expected to make the decision what to do ASAP but is free to pick the best approach

meaning that the security squad conducts the review and ensures that no false-positive or non-critical test failures prevent further automatic acceptance of maintenance tests.

Hi Oliver,
According to https://confluence.suse.com/pages/viewpage.action?spaceKey=qasle&title=openQA+QE+Maintenance+Review "Security QE" squad did not check the "Approvals" list as limited resources before and current.
See comments for more info,

User icon: llzhao
lili zhao
Feedback from QE Security:

The "Proposal 1. Squads will directly take care about stability of openQA test cases from QE Maintenance." can't be applied to security squad based on our current limited resource.
QE Security squad can help to support these actions atm:
1. Can support fixing poos while test cases (FIPS/apparmor/apparmor_profile/scap/selinux/lynis/389ds/swtpm/Secureboot) run fail in QE Maintenance job group and "QE Security" team is asked for helps from "QE Update Validation" team.

2. Can support code review while security related test cases are integrated into openQA Maintenance job group by "QE Update Validation" team.

3. Can offer technical supports while "QE Update Validation" team wants to enable Security test cases in QE Maintenance job group.



More feedback, after rechecked/reevaluated this page:

4.  Security QE would like not approve this proposal atm

Currently we are working on the high priority CC testing (Common Criteria Certification related) and after Sept we will work on both CC and sle15sp4. Besides there is no QEM FTE joined Security QE team after the LSG merge.  We are overloaded already. So we can not guarantee the promise in this proposal. Btw, we will apply a new FTE during FY2022 when the new FTE is available we would like to reevaluate this proposal. Currently we would like to continue supporting to fix/debug poo/failure but can not guarantee a high priority (same as before).

Vit Pelcak

So security squad will not review the openQA update job groups or similar things.
When we noticed the ping messages in "# eng-testing" we had taken actions as high priority and suggested it seems a product bug.

@okurz see above info :)