QA » openQA Project » openQA Tests

NFS - works fine on openqa.suse.de - https://openqa.suse.de/tests/646729
HTTPS - I am not sure if there is support in sles, there is no HTTPS option in installer (F4 menu) and iirc it did not work when I entered manually

HTTPS is covered in a separate ticket.

take a look into the parent task #9486, there is #15148 for https

okurz wrote:

@thehejik

• would the SMB testsuite in slenkins help us to test installation over SMB?

Unfortunately, I don't see any way how to (re)use SMB server SUT from SLEnkins samba testsuite as a source of test-image for any openQA job.

If I get it right a SMB test suite should setup a server and a client and check that the client can access files from the server. If that is the case with the existing test case can we use that server component to do an installation from it when we put installation media (e.g. SLES + some addons) on the server?

I got your point but I found it a bit difficult to implement because:

• SLEnkins suites are running on special ovs/tap workers in openQA, it means that regular job running on x86_64 worker will have no access to ovs/tap network and vice versa
• It will need some locking policy to be set, for example if a new image is available run SMB server test, copy new image on that server and then run job for SMB installation
• interoperability between normal needle based test and SLEnkins SUTs is not supported (not sure if possible)

On which architectures would that be possible for both server+client?

The current SLEnkins wrapper in openQA supports only x86_64 VMs and the same stands for slenkins-cloud. SLEnkins itself supports aarch64, x86_64, ppc64le, ppc64 and s390 architectures but only if you are running the test on bare-metal with help of kvm or on x86_64 in emulation mode (s390 supported only on SLE11 in emu).

We've set up a smb server on o.s.d. which can be accessed over the share 'install' and points to the /var/lib/openqa/factory/repo/ like our ftp server does.

first quick try on s390x succeeded

mgriessmeier wrote:

We've set up a smb server on o.s.d. which can be accessed over the share 'install' and points to the /var/lib/openqa/factory/repo/ like our ftp server does.

first quick try on s390x succeeded

Yeah, thats much better solution I think.

working testcases on o.s.d for s390x:

SLES: https://openqa.suse.de/tests/773865
SLES+HA: https://openqa.suse.de/tests/773864

https://gitlab.suse.de/openqa/scripts/merge_requests/67 merged.

I adapted the existing testsuite "smb+xfs" as it was used for s390x and enabled aarch64, x64_64 and ppc64le scenarios within the test development group. After they are shown to be stable we move them to "sles: functional"

So what are your plans on this? The tests in test development still show the same results (and keep wasting ressources). We could just remove them and assume the coverage on s390x is enough in general. Or just add some test settings? The test code can be cleaned up nevertheless to not do something "architecture" specific which it actually isn't.

okurz wrote:

So what are your plans on this? The tests in test development still show the same results (and keep wasting ressources). We could just remove them and assume the coverage on s390x is enough in general. Or just add some test settings? The test code can be cleaned up nevertheless to not do something "architecture" specific which it actually isn't.

Please remove your tests from Test Development group, it will not work and as you said it is just wasting resources. Right now we have a coverage for s390x from Mathias and x86_64 from me.

Imo it would be nice to have ppc64le and aarch64 SMB installation tests as well.

Agreed. misleading scenarios for smb+xfs@ppc64le and smb+xfs@x86_64 removed from test development group so that they won't get scheduled and provide a wrong impression.

@thehejik feel free to unassign the ticket from yourself when you don't plan to work on it in the next time.