openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842023-11-28T06:58:19ZopenSUSE Project Management Tool
Redmine ALP - action #151558 (Resolved): [security] firstrun on sle-micro >= 6.0 should be ALPifiedhttps://progress.opensuse.org/issues/1515582023-11-28T06:58:19Ztjyrinki_susetjyrinki+redmine@suse.de
<p>openQA test in scenario sle-micro-6.0-Default-encrypted-x86_64-container_selinux@uefi fails in<br>
<a href="https://openqa.suse.de/tests/12874494/modules/firstrun/steps/5" class="external">firstrun</a></p>
<p>Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle-micro&flavor=Default-encrypted&machine=uefi&test=container_selinux&version=6.0" class="external">latest</a></p>
<p>Firstrun is failing with distri sle-micro and version 6.0 - that is, ALP - in the encrypted flavor (that does not use ignition but uses firstrun wizard). This is likely due to it picking up the SLE Micro 5.x expections while it should now work as intended on ALP. There may or may not be difference between ALP Dolomite and ALP Marble in this regard, but likely it should be largely the same.</p>
<p>selinux_setup was updated to use is_alp || is_sle_micro('>=6.0'), jeos/firstrun should maybe using is_sle || is_sle_micro('<6.0') in some places and the former in other places, not sure what would be optimal.</p>
openQA Project - action #127238 (New): It's not possible to remove own force_result comments, and...https://progress.opensuse.org/issues/1272382023-04-05T06:42:05Ztjyrinki_susetjyrinki+redmine@suse.de
<p>Here is an example:</p>
<p><a href="https://openqa.suse.de/tests/10848924#comments" class="external">https://openqa.suse.de/tests/10848924#comments</a></p>
<p>The soft-fail forcing was done erronously, and would be wanted to be removed. However, when trying to remove the comment Forbidden message is given to the person who made the comment (the person is also Administrator).</p>
<p>This ticket looks like opposite of ticket <a class="issue tracker-4 status-1 priority-3 priority-lowest" title="action: It's possible to delete force_result comments (New)" href="https://progress.opensuse.org/issues/107239">#107239</a>, so I'm not sure what to do. However, in the recent months it feels there has been more related changes - now these un-deletable comments are also carried over automatically to new runs, and those carried over comments are also undeletable. If this kind of comment would happen in maintenance tests and couldn't be corrected (without availability of someone who has more direct rights than even Administrator has), it could mean even accidentally giving green light to an erronous update if the correction would be delayed.</p>
openQA Project - action #123724 (Resolved): auto_review not working despite ticket in openQA auto...https://progress.opensuse.org/issues/1237242023-01-27T07:20:44Ztjyrinki_susetjyrinki+redmine@suse.de
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>Ticket #122215 seems not functional still, the affected tests do not get the softfail forcing still automatically but need to be set manually daily.</p>
<p>The ticket has:<br>
<code>auto_review:"Test result is NOT same as baseline":force_result:softfailed</code><br>
... at the end of the subject, and the ticket was moved to openQA auto review project.</p>
<p>The tests can be found at the 15-SP4 runs at <a href="https://openqa.suse.de/group_overview/429" class="external">https://openqa.suse.de/group_overview/429</a></p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1</strong>: Result is changed to softfailed as specified in the title of the ticket</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Verify that the regex valid/working e.g. <code>auto_review:"Test result is NOT same as baseline":force_result:softfailed</code>, maybe by putting the title in a unit test and seeing if that fails</li>
<li>Check that the ticket is filed correctly, i.e. using the force result tracker - this <strong>seems</strong> to be correct</li>
<li>Check the code in <a href="https://github.com/os-autoinst/scripts" class="external">https://github.com/os-autoinst/scripts</a></li>
</ul>
openQA Project - action #119467 (Resolved): "Internal server error" on opening any job group fron...https://progress.opensuse.org/issues/1194672022-10-27T06:00:25Ztjyrinki_susetjyrinki+redmine@suse.de
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>Build specific pages etc work, but job group front page like <a href="https://openqa.suse.de/group_overview/268" class="external">https://openqa.suse.de/group_overview/268</a> does not.</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> No obvious related regression on OSD</li>
<li><strong>AC2:</strong> Test coverage for the branding button code exists for both the job comments as well as job group comments</li>
</ul>
openQA Infrastructure - action #90275 (Resolved): Replacement openQA OSD aarch64 hardware (was: D...https://progress.opensuse.org/issues/902752021-03-18T10:29:54Ztjyrinki_susetjyrinki+redmine@suse.de
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>We have had a machine from orthos, but we need to renew the lease every now and then or lose it. It would be easier to have a more permanent solution for eg snapshot validations.</p>
<p>openQA tests aarch64 on KVM, this ticket would be about improving the baremetal aarch64 testing. We were not able to test RC1 on baremetal (non-rpi) aarch64 due to lack of access to hardware (eg problems on thunderx10)</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1</strong>: <strong>DONE</strong> Make new arm machines available</li>
<li><strong>AC2</strong>: openqaworker-arm-4 is salted and processing jobs</li>
<li><strong>AC3</strong>: openqaworker-arm-5 is salted and processing jobs</li>
</ul>
openQA Tests - action #87710 (Resolved): [qe-yast][qe-core][qem][QU] test fails in scc_registrati...https://progress.opensuse.org/issues/877102021-01-13T15:57:00Ztjyrinki_susetjyrinki+redmine@suse.de
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP2-Full-QR-x86_64-multipath@64bit-no-tmpfs fails in<br>
<a href="https://openqa.suse.de/tests/5281462/modules/scc_registration/steps/5" class="external">scc_registration</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Maintainer: okurz</p>
<p>Test installation on machine with virtual multipath hardware. Only tests succesful detection of multipath and installation. No functional testing of multipath itself.</p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.suse.de/tests/5182070" class="external">376.10</a></p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>See Online-QR's result at: <a href="https://openqa.suse.de/tests/5259366" class="external">https://openqa.suse.de/tests/5259366</a><br>
This is the first time the test is tried to run on Full images.<br>
Also SP3 Yast tests do not test multipath on Full: <a href="https://openqa.suse.de/tests/overview?distri=sle&version=15-SP3&build=124.5&groupid=129" class="external">https://openqa.suse.de/tests/overview?distri=sle&version=15-SP3&build=124.5&groupid=129</a></p>
<p>This task might be for QE Yast to enable multipath testing on Full images at some point.</p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Full-QR&machine=64bit-no-tmpfs&test=multipath&version=15-SP2" class="external">latest</a></p>
openQA Tests - action #87709 (Resolved): [qe-core][qem][QU] test fails in bootloaderhttps://progress.opensuse.org/issues/877092021-01-13T15:55:43Ztjyrinki_susetjyrinki+redmine@suse.de
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP2-Full-QR-x86_64-gnome_smb@64bit fails in<br>
<a href="https://openqa.suse.de/tests/5281460/modules/bootloader/steps/5" class="external">bootloader</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Maintainer: okurz, mgriessmeier</p>
<p>Install gnome using smb and MIRROR_SMB variable available in Server-MINI-ISO flavor (only)</p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.suse.de/tests/5182082" class="external">376.10</a></p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>See Online-QR's result at: <a href="https://openqa.suse.de/tests/5259405" class="external">https://openqa.suse.de/tests/5259405</a><br>
This is the first time the test is tried to run on Full images.</p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Full-QR&machine=64bit&test=gnome_smb&version=15-SP2" class="external">latest</a></p>
openQA Tests - action #87707 (Resolved): [qe-core][qem][QU] test fails in bootloaderhttps://progress.opensuse.org/issues/877072021-01-13T15:54:41Ztjyrinki_susetjyrinki+redmine@suse.de
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP2-Full-QR-x86_64-gnome_http@64bit fails in<br>
<a href="https://openqa.suse.de/tests/5281459/modules/bootloader/steps/5" class="external">bootloader</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Maintainer: okurz, mgriessmeier</p>
<p>Install default system using the gnome desktop using a remote repository over http.</p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.suse.de/tests/5182081" class="external">376.10</a></p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>See Online-QR's result at: <a href="https://openqa.suse.de/tests/5259404" class="external">https://openqa.suse.de/tests/5259404</a><br>
This is the first time the test is tried to run on Full images.</p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Full-QR&machine=64bit&test=gnome_http&version=15-SP2" class="external">latest</a></p>
openQA Tests - action #87704 (Resolved): [qe-core][qem][QU] test fails in boot_encrypt on s390x (...https://progress.opensuse.org/issues/877042021-01-13T15:52:23Ztjyrinki_susetjyrinki+redmine@suse.de
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP2-Online-QR-s390x-lvm-encrypt-separate-boot@s390x-kvm-sle12 fails in<br>
<a href="https://openqa.suse.de/tests/5259382/modules/boot_encrypt/steps/10" class="external">boot_encrypt</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Same as lvm-full-encrypt, but with separate boot not encrypted partition, only installation to not repeat everything again with small risk.<br>
Maintainer: riafarov</p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.suse.de/tests/5256009" class="external">377.1</a></p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>Last good: <a href="https://openqa.suse.de/tests/5239855" class="external">376.16</a> (or more recent)</p>
<p>--<br>
Note: also this passing is already using the separated QAM YAML schedule schedule/qam/QR/lvm_encrypt_separate_boot.yaml<br>
--</p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?arch=s390x&distri=sle&flavor=Online-QR&machine=s390x-kvm-sle12&test=lvm-encrypt-separate-boot&version=15-SP2" class="external">latest</a></p>
openQA Tests - action #80452 (Resolved): [qe-core][qem] Problems with aarch64 RAID 15SP1/SP2 QU t...https://progress.opensuse.org/issues/804522020-11-26T12:13:47Ztjyrinki_susetjyrinki+redmine@suse.de
<p>Passed for 15SP1 16 days ago:<br>
<a href="https://openqa.suse.de/tests/overview?distri=sle&version=15-SP1&build=45.41&groupid=249" class="external">https://openqa.suse.de/tests/overview?distri=sle&version=15-SP1&build=45.41&groupid=249</a></p>
<p>Failed in a later build:<br>
<a href="https://openqa.suse.de/tests/overview?distri=sle&version=15-SP1&build=47.3&groupid=249" class="external">https://openqa.suse.de/tests/overview?distri=sle&version=15-SP1&build=47.3&groupid=249</a></p>
<p>(same build, aarch64 specific for playground)<br>
<a href="https://openqa.suse.de/tests/overview?distri=sle&version=15-SP1&build=47.3rerun1&groupid=249" class="external">https://openqa.suse.de/tests/overview?distri=sle&version=15-SP1&build=47.3rerun1&groupid=249</a></p>
<p>But associated with change last Thursday like:<br>
<a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/commit/16631d3018a1cddae2e5825670d1a066e10fb015" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/commit/16631d3018a1cddae2e5825670d1a066e10fb015</a><br>
that led to setup_libyui error:<br>
<a href="https://openqa.suse.de/tests/5060842#step/setup_libyui/1" class="external">https://openqa.suse.de/tests/5060842#step/setup_libyui/1</a><br>
and with manual schedule omitting the setup_libyui to raid_gpt error:<br>
<a href="https://openqa.suse.de/tests/5063512#step/raid_gpt/1" class="external">https://openqa.suse.de/tests/5063512#step/raid_gpt/1</a></p>
<p>Then Rodion mentioned YAML schedule should not be used and moved back to non-YAML (even though the passing tests 16 days earlier were using the YAML schedule):<br>
<a href="https://gitlab.suse.de/qa-maintenance/qam-openqa-yml/-/commit/0a9c964daa754911478d01a29ffb4d9148c79fdf" class="external">https://gitlab.suse.de/qa-maintenance/qam-openqa-yml/-/commit/0a9c964daa754911478d01a29ffb4d9148c79fdf</a></p>
<p>But that lead to different errors, which in turn were partially fixed by:<br>
<a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/commit/96c4dca21c8bd7d9b11cffd58c2f9985ed319f53" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/commit/96c4dca21c8bd7d9b11cffd58c2f9985ed319f53</a></p>
<p>Before now George started looking at, at least RAID 0, 5 and 10 were proven to have passed at least once for 15SP1 Build 47.3, while 1 and 6 remained problemtic.</p>
<p>For 15SP2, everything passed 5 days ago at <a href="https://openqa.suse.de/tests/overview?distri=sle&version=15-SP2&build=375.8&groupid=321" class="external">https://openqa.suse.de/tests/overview?distri=sle&version=15-SP2&build=375.8&groupid=321</a> but similarly failures with latest build (rerun can get it further though): <a href="https://openqa.suse.de/tests/overview?distri=sle&version=15-SP2&build=376.1&groupid=321" class="external">https://openqa.suse.de/tests/overview?distri=sle&version=15-SP2&build=376.1&groupid=321</a></p>
<p>SP2 is still using YAML.</p>
openQA Tests - coordination #64126 (New): [qe-core][epic] Identify packages that have automated i...https://progress.opensuse.org/issues/641262020-03-03T13:23:14Ztjyrinki_susetjyrinki+redmine@suse.de
<p>There's both 1) potentially indirect testing of packages that could be marked as tested automatically, and 2) database of TEST_SUITE_SUFFICIENT information from Updates Squad that could be used likewise.</p>
<p>Let's use this ticket to define guidelines for us.</p>
<a name="How"></a>
<h1 >How<a href="#How" class="wiki-anchor">¶</a></h1>
<ul>
<li>How to own our testing better (Where our needs for tooling end, and where the tooling should be provided by external teams)</li>
<li>How to decide whether it should be a package test, an openQA test, or a separate test ran within openQA</li>
<li>How to match this with our test plan</li>
</ul>
openQA Tests - action #58673 (Resolved): libqt5_qtbase fails on 15 SP2https://progress.opensuse.org/issues/586732019-10-25T06:31:45Ztjyrinki_susetjyrinki+redmine@suse.de
<p>The new test just merged seems to be working elsewhere but needles fail on 15 SP2.</p>
<p><a href="https://openqa.suse.de/tests/3527794" class="external">https://openqa.suse.de/tests/3527794</a></p>
openQA Tests - action #57584 (Resolved): [qam] test fails in evolution_setup_servers - dovecot n...https://progress.opensuse.org/issues/575842019-10-01T11:52:32Ztjyrinki_susetjyrinki+redmine@suse.de
<p>After <a href="https://progress.opensuse.org/issues/56273" class="external">https://progress.opensuse.org/issues/56273</a> got fixed, the evolution_setup_servers is now failing, a rerun done first at <a href="https://openqa.suse.de/tests/3397700" class="external">https://openqa.suse.de/tests/3397700</a> and a newer one at <a href="https://openqa.suse.de/tests/3424806" class="external">https://openqa.suse.de/tests/3424806</a></p>
<p>"No provider of 'dovecot' found." at <a href="https://openqa.suse.de/tests/3397700#step/evolution_prepare_servers/18" class="external">https://openqa.suse.de/tests/3397700#step/evolution_prepare_servers/18</a></p>
<p>qam-regression-message is currently disabled, <a href="https://progress.opensuse.org/issues/57260" class="external">https://progress.opensuse.org/issues/57260</a> is about re-enabling it once the issues are all fixed.</p>
openQA Project - action #56789 (New): New needles from git repository not working with openqa-clo...https://progress.opensuse.org/issues/567892019-09-11T08:14:09Ztjyrinki_susetjyrinki+redmine@suse.de
<p>Use case:</p>
<p>To be able to test tests in production (openqa.opensuse.org or openqa.suse.de) before merging the needles and tests themselves, since results have proven to vary on those loaded machines compared to local openQA instance or VM.</p>
<p>It is currently working if there are no new needles involved, but this issue describes the problem with custom needles which would be theoretically supported by openqa-clone-custom-git-refspec but not working in practice.</p>
<p>Problem description:</p>
<p>First of all, documentation [1] says "Path to needles subdirectory to use, defaults to "needles" within PRODUCTDIR. Can be a git repository URL, comparable to CASEDIR", and CASEDIR states "for example <a href="mailto:git@github.com">git@github.com</a>:os-autoinst/os-autoinst-distri-opensuse.git#feature/test".</p>
<p>[1] <a href="https://github.com/os-autoinst/os-autoinst/blob/master/doc/backend_vars.asciidoc" class="external">https://github.com/os-autoinst/os-autoinst/blob/master/doc/backend_vars.asciidoc</a></p>
<p>However,</p>
<pre><code>openqa-clone-custom-git-refspec https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/8332 https://openqa.opensuse.org/tests/xxxxxxxx --apikey=XXX --apisecret=XXX NEEDLES_DIR=git@github.com:tjyrinki/os-autoinst-needles-opensuse.git#poo-12345
</code></pre>
<p>results in:</p>
<pre><code>Could not create directory '/var/lib/empty/.ssh'.
Host key verification failed.
fatal: Could not read from remote repository.
</code></pre>
<p>Using https instead (NEEDLES_DIR=<a href="https://github.com/tjyrinki/os-autoinst-needles-opensuse.git" class="external">https://github.com/tjyrinki/os-autoinst-needles-opensuse.git</a>) gets one further, but openQA complains about wrong needles location:</p>
<pre><code>init needles from /var/lib/openqa/pool/15/os-autoinst-needles-opensuse
Needle /var/lib/openqa/pool/15/os-autoinst-needles-opensuse/ssh-login-ok-20160813.json is not under project directory /var/lib/openqa/cache/xxx at /usr/lib/os-autoinst/needle.pm line 63.
</code></pre>
<p>Oliver Kurz suggested playing around with the PRODUCTDIR to try to workaround the forbidding use of (correctly checked out) needles dir which I did but it didn't get any better with trying to set that to eg pool/... directories, which also changes on every run.</p>
openQA Tests - action #50867 (Resolved): [qam] nfsidmap part of the autofs tests fail on SLE12https://progress.opensuse.org/issues/508672019-04-30T07:30:08Ztjyrinki_susetjyrinki+redmine@suse.de
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<pre><code class="bash syntaxhl" data-language="bash">nfsidmap <span class="nt">-c</span>
<span class="s1">'id_resolver'</span> keyring was not found
</code></pre>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<ul>
<li>Build <a href="https://openqa.suse.de/tests/2844872#step/autofs_client/39" class="external">20190430</a>
In scenario sle-12-SP3-Server-DVD-Updates-x86_64-1-mau-autofs-server@64bit</li>
</ul>
<a name="Expected-results"></a>
<h2 >Expected results<a href="#Expected-results" class="wiki-anchor">¶</a></h2>
<p>I cannot find any expected result in OSD, so I consider this a new test.</p>
<a name="Further-information"></a>
<h2 >Further information<a href="#Further-information" class="wiki-anchor">¶</a></h2>
<p>Latest job in this scenario: <a href="https://openqa.suse.de/tests/latest?test=mau-autofs-server&flavor=Server-DVD-Updates&arch=x86_64&distri=sle&version=12-SP3&machine=64bit" class="external">https://openqa.suse.de/tests/latest?test=mau-autofs-server&flavor=Server-DVD-Updates&arch=x86_64&distri=sle&version=12-SP3&machine=64bit</a></p>