Hi Sarah, On Friday, 6 November 2020 19.43.31 CET Sarah Julia Kriesch wrote:
Hi,
if you want to speak public about tickets, can you make these ones also public, please?
https://progress.opensuse.org/issues/69328 is public. https://progress.opensuse.org/issues/72880 was a wrong lead and does not add any useful information. But to satisfy curiousity: It was describing the problem that the s390x testing ressources assigned for the SUSE internal openQA instance dedicated for testing SUSE products was insufficient some time ago (years or month). This has actually been resolved a long time ago.
Gesendet: Freitag, 06. November 2020 um 16:18 Uhr Von: "Lubos Kocman" <lubos.kocman@suse.com> An: "opensuse-factory@opensuse.org" <opensuse-factory@opensuse.org> Betreff: [opensuse-factory] Ad-hoc openSUSE s390x meeting 06.11.2020
Original meeting minutes: https://etherpad.opensuse.org/p/ReleaseEngineering-20200611-s390x-openqa
Discussion about openSUSE/s390x
Attendees: Lubos, Oliver, Ihno Lubos: my understanding is that following is the issue https://progress.opensuse.org/issues/72880
Oliver: to summarize situation we don't have any commitment to get s390x maintaining Oliver this issue is currently specific for openSUSE: [o3][s390x] Early fail on s390x workers: connection refused https://progress.opensuse.org/issues/69328
The community is waiting for that since months. We can not do anything in this direction, because the mainframe is in the SUSE network.
Oliver: we need more commitment from QA department to maintain openQA/s390x or even SUSE as a whole.
Ihno: number of s390x guests has no real limits. Oliver: when we talk about openSUSE, the very single instance was either not fully used or working. Ihno: I can work on the cases where guests are not working.
Oliver: I'm Product Owner for maintaining openQA as a software as well as the infrastructure of openqa.opensuse.org. What is outside our scope is to fix tests, review the tests or getting the distribution published (not only for s390x). That is responsibility of "release managers".
Really? Is a Release Manager responsible for a working infrastructure for development? In my experience, there should be Admins for this job.
Sorry about that. The phrasing is ambiguous. The SUSE team "QE Tools" ensures that the infrastructure of openqa.opensuse.org is well maintained. Though community members have access to the infrastructure (explained below). What I see as the responsibility of a "release manager" here is "fix tests, review the tests or getting the distribution published (not only for s390x)". And that does not even mean that such person would need to do the actual fixing, just ensuring that it happens by delegating to the right people to do that :) In my observation that is working out quite ok for openSUSE Tumbleweed and Leap for the architectures like x86_64, ppc64le, aarch64 and others.
We are lucky to have Guillaume G. to keep ARM working. okurz was asked by Andrew Waafa at an openSUSE Conference what could be done and the advice was to simply ask every day or as often as possible about the state of the builds, why tests are not executed, report tickets, find the right people to delegate to, etc. . Agreement with Andrew Waffa in discussion to make openSUSE/ARM a thing
Ihno: it will be our top priority to get s390x/openQA working. If you need HW resources, we can give it to you. Lubos: we need to revisit our current dedicated QA resources with introduction of s390x in Leap Oliver: I don't think that the current contract works, reality is more like a reactive support which is nice but either there is no one asking or tickets are not properly triaged and ignored.
Ihno: externals can only do just a certain part of openQA work, many things have to be done by SUSE employees.
I agree. And that is the case here, too. SUSE is owner of the mainframe, because it has been used mainly for SUSE Linux Enterprise.
Oliver: We have a dedicated s390x "QE core" product owner for openQA tests, that is Timo Jyrinki https://confluence.suse.com/display/qasle/QE+squads+-+new+structure. The scope is basic test suite (install login and so on). For installer the product owner of the corresponding QE team is Rodion Iafarov.
Tasks:
Lubos to talk to Marita or possibly Ralf regarding dedicated resources in Leap 15.3 interlock document. We have more arches to support, we'll need more people to maintain openqa as well. Note by okurz: The important point to reach is the common understanding that openSUSE is part of SUSE's business. IBM are interested and happy about any "good publicity" for IBM Mainframes, i.e. s390x.
Lubos to see if we can find external IBM s390x/openSUSE contact. The problem is that the person would not have the possibility to fix all of the openqa issues due to the fact that some issues can be addressed only by SUSE Employees.
You don't have to look long. You have got an openSUSE Member and IBM employee in the community. https://lists.opensuse.org/opensuse-zsystems/2020-10/msg00000.html
I have been working for IBM since October and have received the approval for openSUSE contributions at the end of the month. This week we had a small discussion how to proceed.
IBM is watching that as a win-win situation to receive an openSUSE Member as an employee. We want to improve the cooperation on this way.
I can do all necessary from IBM side. But I can not do that inside of SUSE (the mainframe issue case).
I am very happy to hear that. I also want to offer my help and you are very welcome to contact me. For example I could explain some basics about the openQA setup and walk with you over basic steps of how the distribution(s) are currently tested in conjunction with openqa.opensuse.org, how test results are evaluated for publishing of new snapshots, etc.
openqa.opensuse.org is available for administration for non-SUSE employees as well. See https://progress.opensuse.org/projects/openqav3/wiki/#Accessing-o3-infrast ructure for details
Ihno: to reach out to Ralf U. regarding importance of s390x/openSUSE openqa and basic ticket triaging as a responsibility for the QE department. Current situation is bad no tests were finished in last 6 months or so and nothing was even communicated in tickets. Ihno: revisit current s390x resources for openQA. And make sure that they're online.
Oliver: I will update ticket and link it accordingly, but I would be really happy if Release Manager can first get commitment from not-only QE management.
Side note: we have only one power8 worker for openqa. Ihno: are build hosts and testing hosts in different network? Oliver: yes Success story from ARM: external machines not maintained by QE Tools team (within SUSE). openQA and openqa.opensuse.org can and is using any machine that is reachable over internet with sufficient bandwidth, e.g. cloud instances, physical machines at SUSE partners, etc. This is an opportunity for SUSE partners to have easier access with less effort to contribute to the testing of openSUSE and SUSE distributions.
I hope, that we can have that with IBM in the future, too. :)
That would be lovely :) Also in case we see something missing in this context regarding openQA then we would be happy to look into according openQA feature requests ? or bug reports ;)
Lubos: I'll consinder the Power topic for Leap 15.3 interlock as well.
Best regards, Sarah
Have fun, Oliver -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org