openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842023-07-25T10:34:25ZopenSUSE Project Management Tool
Redmine QA - action #133307 (Resolved): mtui: Connection to svn+ssh is not possible or the "inconsistent ...https://progress.opensuse.org/issues/1333072023-07-25T10:34:25Zokurzokurz@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>From <a href="https://suse.slack.com/archives/C02CCRM8946/p1690189241388629" class="external">https://suse.slack.com/archives/C02CCRM8946/p1690189241388629</a></p>
<blockquote>
<p>I am getting the below error when I try to call mtui with S:m:29810:303565 what might be the issue ? this does seem to be a QE tools issue?<br>
(Vit Pelcak) E SUSE:Maintenance:29810:303565 TeReGen.Model.Plugin.20_FetchOBS: Inconsistent submission for libndr0: 4.11.14+git.391.c8ca21a34db-150200.4.50.1 vs 4.11.14+git.396.91f4f677472-150200.4.52.3. <a href="https://qam.suse.de/reports/SUSE:Maintenance:29810:303565" class="external">https://qam.suse.de/reports/SUSE:Maintenance:29810:303565</a><br>
(Vit Pelcak) So it looks like an issue in the update</p>
</blockquote>
openQA Infrastructure - action #132947 (Resolved): Bring back ada.qe.suse.de and fix it properlyhttps://progress.opensuse.org/issues/1329472023-07-18T11:29:15Zokurzokurz@suse.com
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> VM owners of a VM on ada.qe.suse.de can use it as in before the AC outage</li>
<li><strong>AC2:</strong> We can remote control the machine</li>
<li><strong>AC3:</strong> <a href="https://racktables.nue.suse.com/index.php?page=object&tab=default&object_id=16675" class="external">https://racktables.nue.suse.com/index.php?page=object&tab=default&object_id=16675</a> is up-to-date</li>
<li><strong>AC4:</strong> <a href="https://gitlab.suse.de/search?project_id=419&search=ada.qe" class="external">https://gitlab.suse.de/search?project_id=419&search=ada.qe</a> and corresponding for ada.qam and ada-mgmt is up-to-date</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Check power cables</li>
<li>Add power cable connections to racktables</li>
<li>Ensure mgmt ethernet is connected</li>
<li>Add connection details to racktables</li>
<li>Add corresponding entries for <em>both</em> mgmt and eth0 in <a href="https://gitlab.suse.de/OPS-Service/salt/" class="external">https://gitlab.suse.de/OPS-Service/salt/</a> repo and delete old entries</li>
</ul>
QA - action #125234 (Resolved): Decommission obsolete machines in qam.suse.de size:Mhttps://progress.opensuse.org/issues/1252342023-03-01T16:25:31Zokurzokurz@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>See <a href="https://gitlab.suse.de/qa-maintenance/infrastructure/-/issues/12" class="external">https://gitlab.suse.de/qa-maintenance/infrastructure/-/issues/12</a> and work on it</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> gitlab issue was resolved</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Review list on <a href="https://confluence.suse.com/display/~apappas/State+of+SRV2+serial+connections" class="external">https://confluence.suse.com/display/~apappas/State+of+SRV2+serial+connections</a> and crosscheck with inventory management entry and <a href="https://gitlab.suse.de/OPS-Service/salt/" class="external">https://gitlab.suse.de/OPS-Service/salt/</a> entries</li>
<li>For "machine exists = no" the task should be easy: Just make sure that there are no left over entries in racktables nor <a href="https://gitlab.suse.de/OPS-Service/salt/" class="external">https://gitlab.suse.de/OPS-Service/salt/</a></li>
<li>For "machine exists = obsolete" follow suggestion from hrommel to have machines removed by Eng-Infra (or remove itself for SRV2) and then continue with the other tasks</li>
</ul>
QA - action #125147 (Resolved): Nuremberg QA workstations and QAM labs cold storage move to Frank...https://progress.opensuse.org/issues/1251472023-02-28T12:46:29Zokurzokurz@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>Rent at Maxtorhof will end. The new location at Nbg Frankencampus will have lab rooms in the same building where the office rooms are. We must prepare and execute the move of QAM equipment from the old location, mostly <a href="https://racktables.nue.suse.com/index.php?page=rack&tab=default&rack_id=18018" class="external">NUE-2.2.10 QA cold storage</a> to an according Frankencampus room</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> There is no more QA/QAM equipment in Maxtorhof office rooms or <a href="https://racktables.nue.suse.com/index.php?page=rack&tab=default&rack_id=18018" class="external">NUE-2.2.10</a> and <a href="https://racktables.nue.suse.com/index.php?page=rack&tab=default&rack_id=19899" class="external">NUE-2.2.13</a> physically</li>
<li><strong>AC2:</strong> Racktables is up-to-date</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li><em>DONE</em> <del>Ask for objections</del> -> no objections</li>
<li>Organize transport of still usable equipment: Create ticket over <a href="https://sd.suse.com" class="external">https://sd.suse.com</a> to component "Facilities" asking them to move the equipment to FC Basement</li>
<li><em>Optional/nice-to-have</em> visit the Maxtorhof place beforehand and prepare the move better, e.g. nothing connected anymore, packed into boxes or something</li>
<li>Scrap decommissioned hardware, see <a href="https://wiki.suse.net/index.php/SUSE-Quality_Assurance/Labs#How_to_decommission_and_dispose_old_hardware" class="external">https://wiki.suse.net/index.php/SUSE-Quality_Assurance/Labs#How_to_decommission_and_dispose_old_hardware</a></li>
</ul>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>The above tasks shouldn't need anyone from our team on-site but it would be helpful to first check in-site and disconnect the workstations that are still connected.</p>
QA - action #125144 (Resolved): Give members of SUSE QE Tools team a chance to get familiar with ...https://progress.opensuse.org/issues/1251442023-02-28T12:31:36Zlivdywanliv.dywan@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>We agreed to take over consistent maintainership of those machines and should be sure we know what we're signing up for.</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> The SUSE QE Tools team knows the basics about the Nbg QAM machines and feels in a position to make relevant decisions</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>With the whole team walk over all machines in racktables to get accustomed.</li>
<li>Conduct a mob session with multiple team members (in the regular slot or ad-hoc, whichever is convenient)</li>
</ul>
QA - action #124724 (Resolved): Ensure Nbg QAM machines have a current maintainer as "contact per...https://progress.opensuse.org/issues/1247242023-02-17T09:24:36Zokurzokurz@suse.com
<p>Ensure Nbg QAM machines have a current maintainer as "contact person"</p>
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>With the work on <a class="issue tracker-6 status-3 priority-4 priority-default closed child parent" title="coordination: [epic] Migration of SUSE Nbg based openQA+QA+QAM systems to new security zones (Resolved)" href="https://progress.opensuse.org/issues/116623">#116623</a> it became clear that we want to have any QAM machines now treated as a joint "QE" group, including not only IP range, domain, etc., but also physical machines, their maintainership and administration. With this we should ensure that all former Nbg QAM machines are maintained by the SUSE QE Tools team. The SUSE QE Tools team will take responsibility, ensure maintainership, make decisions. This was also clarified with the line managers of the former contact persons who like to focus on other areas of work.</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1</strong>: All former Nrg QAM machines are visibly owned by the QE Tools Team</li>
</ul>
<a name="Acceptance-tests"></a>
<h2 >Acceptance tests<a href="#Acceptance-tests" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AT1:</strong> <a href="https://racktables.nue.suse.com/?page=search&last_page=search&last_tab=default&q=dabatianni" class="external">https://racktables.nue.suse.com/?page=search&last_page=search&last_tab=default&q=dabatianni</a> and <a href="https://racktables.nue.suse.com/?page=search&last_page=search&last_tab=default&q=apappas" class="external">https://racktables.nue.suse.com/?page=search&last_page=search&last_tab=default&q=apappas</a> are empty</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>We clarified that it's a better option to update the racktables entries to "<a href="mailto:qa-team@suse.de">qa-team@suse.de</a>" with a comment pointing to the former "contact person" who can still be asked for information or specific help.</li>
</ul>
<p>Suggestion for comment in racktables to include: 2023-02-28: This machine was formerly maintained by dabatianni+apappas from QA Maintenance. Feel free to contact them for specific questions regarding the former use of those machines.</p>
QA - coordination #124721 (Resolved): [epic] Ensure proper QE maintainership of Nbg QAM machineshttps://progress.opensuse.org/issues/1247212023-02-17T09:20:24Zokurzokurz@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>With the work on <a class="issue tracker-6 status-3 priority-4 priority-default closed child parent" title="coordination: [epic] Migration of SUSE Nbg based openQA+QA+QAM systems to new security zones (Resolved)" href="https://progress.opensuse.org/issues/116623">#116623</a> it became clear that we want to have any QAM machines now treated as a joint "QE" group, including not only IP range, domain, etc., but also physical machines, their maintainership and administration. With this we should ensure that all former Nbg QAM machines are maintained by the SUSE QE Tools team. The SUSE QE Tools team will take responsibility, ensure maintainership, make decisions. This was also clarified with the line managers of the former contact persons who like to focus on other areas of work.</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> <a href="https://racktables.nue.suse.com/?page=search&last_page=search&last_tab=default&q=dabatianni" class="external">https://racktables.nue.suse.com/?page=search&last_page=search&last_tab=default&q=dabatianni</a> and <a href="https://racktables.nue.suse.com/?page=search&last_page=search&last_tab=default&q=apappas" class="external">https://racktables.nue.suse.com/?page=search&last_page=search&last_tab=default&q=apappas</a> are empty</li>
<li><strong>AC2:</strong> The SUSE QE Tools team knows the basics about the Nbg QAM machines and feels in a position to make relevant decisions</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>We clarified that it's a better option to update the racktables entries to "<a href="mailto:qa-team@suse.de">qa-team@suse.de</a>" with a comment pointing to the former "contact person" who can still be asked for information or specific help.</li>
<li>With the whole team walk over all machines in racktables to get accustomed.</li>
<li>Where we see the need plan according work, e.g. to move some machines and such.</li>
</ul>
openQA Tests - action #69787 (Resolved): [qe-core][qam][sporadic] test fails in rsync_client not ...https://progress.opensuse.org/issues/697872020-08-10T15:11:33Zokurzokurz@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-Server-DVD-Updates-x86_64-qam-rsync-client@64bit fails in<br>
<a href="https://openqa.suse.de/tests/4544454/modules/rsync_client/steps/10" class="external">rsync_client</a><br>
with</p>
<pre><code>�[0m�[37m[2020-08-10T16:49:17.503 CEST] [debug] barrier wait 'rsync_setup'
�[0m[2020-08-10T16:49:17.503 CEST] [debug] tests/console/rsync_client.pm:28 called lockapi::barrier_wait
[2020-08-10T16:49:17.503 CEST] [debug] <<< testapi::record_info(title="Paused", output="Wait for rsync_setup (on parent job)", result="ok")
�[33m[2020-08-10T16:49:17.584 CEST] [info] ::: lockapi::_try_lock: Retry 1 of 7...
�[0m�[33m[2020-08-10T16:49:27.662 CEST] [info] ::: lockapi::_try_lock: Retry 2 of 7...
�[0m�[33m[2020-08-10T16:49:37.736 CEST] [info] ::: lockapi::_try_lock: Retry 3 of 7...
�[0m�[33m[2020-08-10T16:49:47.810 CEST] [info] ::: lockapi::_try_lock: Retry 4 of 7...
�[0m�[33m[2020-08-10T16:49:57.876 CEST] [info] ::: lockapi::_try_lock: Retry 5 of 7...
�[0m�[33m[2020-08-10T16:50:07.944 CEST] [info] ::: lockapi::_try_lock: Retry 6 of 7...
�[0m�[33m[2020-08-10T16:50:18.008 CEST] [info] ::: lockapi::_try_lock: Retry 7 of 7...
�[0m[2020-08-10T16:50:28.008 CEST] [debug] tests/console/rsync_client.pm:28 called lockapi::barrier_wait
[2020-08-10T16:50:28.009 CEST] [debug] <<< bmwqemu::mydie(cause_of_death="barrier 'rsync_setup': lock owner already finished")
�[33m[2020-08-10T16:50:28.089 CEST] [info] ::: basetest::runtest: # Test died: mydie at /usr/lib/os-autoinst/lockapi.pm line 41.
</code></pre>
<p>whereas the corresponding server code is</p>
<pre><code>�[0m�[37m[2020-08-10T16:54:21.049 CEST] [debug] barrier wait 'rsync_setup'
�[0m[2020-08-10T16:54:21.049 CEST] [debug] tests/console/rsync_server.pm:67 called lockapi::barrier_wait
[2020-08-10T16:54:21.049 CEST] [debug] <<< testapi::record_info(title="Paused", output="Wait for rsync_setup (on parent job)", result="ok")
�[37m[2020-08-10T16:54:21.091 CEST] [debug] barrier 'rsync_setup' not released, sleeping 5s
�[0m�[37m[2020-08-10T16:54:26.121 CEST] [debug] barrier 'rsync_setup' not released, sleeping 5s
…
�[0m�[37m[2020-08-10T16:59:32.771 CEST] [debug] barrier 'rsync_setup' not released, sleeping 5s
�[0m�[37m�[37m�[37m[2020-08-10T16:59:36.015 CEST] [debug] backend got TERM
�[0m[2020-08-10T16:59:36.015 CEST] [debug] autotest received signal TERM, saving results of current test before exiting
</code></pre>
<p>so the client already gave up waiting after a minute whereas the server has not even reached this point.</p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails often but not always. <a class="user active user-mention" href="https://progress.opensuse.org/users/11830">@dzedro</a> tends to mark according issues with <a class="issue tracker-6 status-3 priority-5 priority-high3 closed behind-schedule" title="coordination: [epic] multimachine test fails with symptoms "websocket refusing connection" and other unclear re... (Resolved)" href="https://progress.opensuse.org/issues/65118">#65118</a> . All accordingly labeled tests can be investigated for this issue.</p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>A good case: <a href="https://openqa.suse.de/tests/4542505" class="external">20200810-1</a></p>
<p>The test should be robust to cover the corresponding needed synchronisation period from both client and server side</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=Server-DVD-Updates&machine=64bit&test=qam-rsync-client&version=15" class="external">latest</a></p>