Project

General

Profile

action #25248

coordination #23798: [qe-core][sles][functional][epic] Add systemd test suite execution to openQA

coordination #25244: [epic][functional][u]systemd testsuite executed on development time for systemd department

[tools][functional][systemd][u] openQA-workers for systemd department

Added by SLindoMansilla about 4 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
Infrastructure
Target version:
SUSE QA - Milestone 21
Start date:
2017-09-13
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Acceptance criteria

  • AC1: At least one systemd team member knows how to configure remote workers.
  • AC2: The systemd team has remote workers configured for:
    • x86_64
    • aarch64
    • ppc
    • s390x

Related issues

Related to openQA Tests - action #25246: [tools][functional][u][systemd][medium]openQA-webui for systemd virtual teamResolved2017-09-13

Related to openQA Tests - action #36754: [qe-core][functional][systemd][medium] test fails in systemd_testsuite - needs further investigationResolved2018-06-04

History

#1 Updated by SLindoMansilla about 4 years ago

It has to be decided yet if they should have dedicated hardware for that or they should used shared workers like the Yast team.

#2 Updated by okurz about 4 years ago

  • Category set to Infrastructure

#3 Updated by okurz about 4 years ago

  • Subject changed from openQA-workers for systemd department to [sle][functional]openQA-workers for systemd department

#4 Updated by okurz about 4 years ago

  • Subject changed from [sle][functional]openQA-workers for systemd department to [tools][systemd]openQA-workers for systemd department

#5 Updated by okurz almost 4 years ago

  • Target version set to Milestone 14

#6 Updated by okurz almost 4 years ago

  • Due date set to 2018-03-13

#7 Updated by okurz over 3 years ago

  • Due date changed from 2018-03-13 to 2018-04-24
  • Target version changed from Milestone 14 to Milestone 15

M14 is too full. Better we focus more on fixing.

#8 Updated by mgriessmeier over 3 years ago

  • Subject changed from [tools][systemd]openQA-workers for systemd department to [tools][systemd][u] openQA-workers for systemd department

#9 Updated by okurz over 3 years ago

  • Subject changed from [tools][systemd][u] openQA-workers for systemd department to [tools][functional][systemd][u] openQA-workers for systemd department

#10 Updated by okurz over 3 years ago

  • Due date changed from 2018-04-24 to 2018-05-08

Because we are not moving anywhere with these tickets let's work on the webui server as a prerequisite in #25246 first.

#11 Updated by okurz over 3 years ago

  • Target version changed from Milestone 15 to Milestone 16

#12 Updated by mgriessmeier over 3 years ago

  • Related to action #25246: [tools][functional][u][systemd][medium]openQA-webui for systemd virtual team added

#13 Updated by mgriessmeier over 3 years ago

  • Description updated (diff)
  • Assignee set to SLindoMansilla

To be done:

  • Decide if we help them to set it up themselves or if we set the workers up for them
  • Try to motivate the systemd department to drive this

Sergio will contact them to clarify machine resources

#14 Updated by SLindoMansilla over 3 years ago

  • systemd team has a webui: http://emerson.suse.de
  • they don't have any worker machine for aarch64, ppc64le nor s390x.
  • at the moment http://emerson.suse.de is also used as a x86_64 worker for qemu backend, but it is a too week machine that cannot handle the webui and x86_64 workers for the team.
  • tblume has access to a s390x machine, but he needs it for debugging. Maybe we could find a way that he can use it for both, debugging and as openQA-worker-SUT.
  • tblume will take care of looking for aarch64 and ppc64le and x86_64 machines in orthos. After that, we should help them know how to configure those machines as SUT for remote workers.

#15 Updated by SLindoMansilla over 3 years ago

  • Description updated (diff)
  • Status changed from New to Feedback
  • Assignee deleted (SLindoMansilla)
  • Priority changed from Normal to Low

At the moment tsaupe has to look for machines (aarch64, ppc64le, s390x, x86_64) for his team. We have to wait for him. This task is not yet workable.

#16 Updated by okurz over 3 years ago

  • Assignee set to tsaupe

Hi tsaupe, as stated by SLindoMansilla in #25248#note-15 we are waiting for you to "look for machines". This is why I will assign this ticket to you assuming you will respond back when you either have found machine ressources useable for openQA workers or a question how we can help you.

#17 Updated by tsaupe over 3 years ago

okurz wrote:

Hi tsaupe, as stated by SLindoMansilla in #25248#note-15 we are waiting for you to "look for machines". This is why I will assign this ticket to you assuming you will respond back when you either have found machine ressources useable for openQA workers or a question how we can help you.

I've got machines for x86_64 and ppc64le.
I've installed SLES12SP3 but need to postpone further processing, because I'm currently vacation backup for systemd and have to process high priority bugs.
I expect to continue processing next week.

#18 Updated by mgriessmeier over 3 years ago

  • Due date changed from 2018-05-08 to 2018-06-05

#19 Updated by mgriessmeier over 3 years ago

  • Due date changed from 2018-06-05 to 2018-06-19
  • Target version changed from Milestone 16 to Milestone 17

@Thomas any update? :)
Need help with something?

#20 Updated by tsaupe over 3 years ago

mgriessmeier wrote:

@Thomas any update? :)
Need help with something?

Actually, the machines are up and running.
We could start the worker setup.
I'm just very busy with bugs and need a timeslot.
Also I'm currently using the ppc machine for reproducing bug 1092896.
Is it still possible to use the machine as reproducer after the openqa worker setup?

#21 Updated by SLindoMansilla over 3 years ago

Hi Thomas,

Well, as long as there is no re-installation of the OS, it is possible.
Can you describe what you do to reproduce bugs there?

#22 Updated by tsaupe over 3 years ago

SLindoMansilla wrote:

Hi Thomas,

Well, as long as there is no re-installation of the OS, it is possible.
Can you describe what you do to reproduce bugs there?

I'm downloading the test image from the test run that was reported to fail and run it in virt-manager on my machine.
I can then install the testsuite and start the test manually inside this vm.
That turned out to be very convenient for debugging.

Also, when systemd is updated to a newer version, there are usually more tests added.
That means I need to adapt the testsuite package and thus need one machine for each architecture where I can start it.
I'm currently trying to get another machine for aarch64, so that I can adapt the testsuite (see latest entry in bug 1092896).

However, I don't need those machines permanently for development, so I guess the openQA setup could co-exist with my development system there.

#23 Updated by okurz over 3 years ago

Yes, you can definitely run VMs using libvirtd+virt-manager in parallel to openQA workers on that machine.

#24 Updated by tsaupe over 3 years ago

okurz wrote:

Yes, you can definitely run VMs using libvirtd+virt-manager in parallel to openQA workers on that machine.

Ok, so let's make an appointment for the openQA setup on my ppc64le, and x86_64 VM.
If it suits you, next week Monday or Tuesday would be fine.
For the time, I don't have preferences, just pick what is convenient for you.

#25 Updated by SLindoMansilla over 3 years ago

Monday at 13:30?

#26 Updated by tsaupe over 3 years ago

SLindoMansilla wrote:

Monday at 13:30?

Ok, fine for me.

#27 Updated by tsaupe over 3 years ago

Status update:

remote workers configured for x86_64 and ppc64le

I'm unable to get a permanent machine reservation on an aarch64 host.
There is also a technical problem, aarch64 doesn't support virtualization nesting.
That makes the current testsuite setup for the extended tests unusable.
Looking for a solution.

For s390x, I'm still looking for a machine.

#28 Updated by okurz over 3 years ago

  • Target version changed from Milestone 17 to Milestone 17

#29 Updated by mgriessmeier over 3 years ago

  • Due date changed from 2018-06-19 to 2018-07-03

#30 Updated by mgriessmeier over 3 years ago

tsaupe wrote:

For s390x, I'm still looking for a machine.

Can I support you here?

#31 Updated by tsaupe over 3 years ago

mgriessmeier wrote:

tsaupe wrote:

For s390x, I'm still looking for a machine.

Can I support you here?

Sure, I'd be happy if you could give me a VM.
All orthos machines have by far too few resources for the tests.

#32 Updated by SLindoMansilla over 3 years ago

  • Blocks action #36754: [qe-core][functional][systemd][medium] test fails in systemd_testsuite - needs further investigation added

#33 Updated by riafarov over 3 years ago

Clarify if can solve aarch64 workers issue first.

#34 Updated by SLindoMansilla over 3 years ago

s390x worker already working.

Only aarch64 missing. Need to research how to enable kvm virtualization for aarch64 on SLE12-SP3 or SLE15.

SR about packages needed by os-autoinst when using svirt backend (s390x, xen): https://build.opensuse.org/request/show/618317

#35 Updated by mgriessmeier over 3 years ago

  • Due date deleted (2018-07-03)
  • Target version changed from Milestone 17 to Milestone 21+

#36 Updated by SLindoMansilla almost 3 years ago

  • Blocks deleted (action #36754: [qe-core][functional][systemd][medium] test fails in systemd_testsuite - needs further investigation)

#37 Updated by SLindoMansilla almost 3 years ago

  • Related to action #36754: [qe-core][functional][systemd][medium] test fails in systemd_testsuite - needs further investigation added

#38 Updated by SLindoMansilla almost 3 years ago

Hi Thomas,

if I remember properly, you already got aarch64, ppc64le, s390x and x86_64 workers for your openQA instance. If so, could you resolve this ticket?

#39 Updated by okurz almost 3 years ago

  • Target version changed from Milestone 21+ to Milestone 21

#40 Updated by SLindoMansilla almost 3 years ago

  • Status changed from Feedback to Workable

systemd team is still missing an aarch64 worker

#41 Updated by tsaupe almost 3 years ago

SLindoMansilla wrote:

systemd team is still missing an aarch64 worker

It seems we have insufficient machines on aarch64 to get a fixed worker slaves.
Since all the other slaves are set up, I can live with that.
If in need, I will try to use an orthos machine instead.

I'm closing the ticket therewith.

#42 Updated by SLindoMansilla almost 3 years ago

  • Status changed from Workable to In Progress

#43 Updated by SLindoMansilla almost 3 years ago

  • Status changed from In Progress to Resolved

Also available in: Atom PDF