openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842020-03-25T14:23:30ZopenSUSE Project Management Tool
Redmine openQA Tests - action #64812 (New): [qe-core][functional][sporadic][needs-refining] test fails in...https://progress.opensuse.org/issues/648122020-03-25T14:23:30ZSLindoMansillaslindomansilla@suse.com
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<ul>
<li>In scenario sle-15-SP2-Online-aarch64-create_hdd_gnome@aarch64</li>
<li>Fails since Build 150.1</li>
<li>Current occurrence: <a href="https://openqa.suse.de/tests/4037593#step/shutdown/1" class="external">164.1</a></li>
</ul>
<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/3982298#step/shutdown/1" class="external">155.1</a></p>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<p><del>- Create a product bug about the screen buffer still showing the last screen instead of the locked screen (security issues + bad UX)</del> <a href="https://bugzilla.suse.com/show_bug.cgi?id=1168979" class="external">bsc#1168979</a></p>
<ul>
<li>Workaround ensure_unlocked_desktop to take into account an outdated screen buffer.</li>
</ul>
<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=aarch64&distri=sle&flavor=Online&machine=aarch64&test=create_hdd_gnome&version=15-SP2" class="external">latest</a></p>
openQA Tests - action #63649 (New): [qe-core][functional] Enhanced reboot_after_installationhttps://progress.opensuse.org/issues/636492020-02-20T13:41:14ZSLindoMansillaslindomansilla@suse.com
<a name="Tasks"></a>
<h2 >Tasks<a href="#Tasks" class="wiki-anchor">¶</a></h2>
<ol>
<li>reboot_after_installation always received from a previous module, a known system state, which is not changing over time.</li>
<li>reboot_after_installation always left the system for a following module, in a known system state, which is not changing over time.</li>
</ol>
<a name="Sugguestion"></a>
<h2 >Sugguestion<a href="#Sugguestion" class="wiki-anchor">¶</a></h2>
<ul>
<li>reboot_after_installation will end on grub menu.</li>
<li>If grub menu has a timeout, it will stop the timeout by pressing a key (esc, up?)</li>
<li>The next module has to take over from grub <strong>grub_test</strong></li>
</ul>
<a name="Latest"></a>
<h2 >Latest<a href="#Latest" class="wiki-anchor">¶</a></h2>
<ul>
<li><a href="https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=KDE-Live&machine=64bit-2G&test=kde-live_installation&version=15.1#step/reboot_after_installation/6" class="external">https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=KDE-Live&machine=64bit-2G&test=kde-live_installation&version=15.1#step/reboot_after_installation/6</a></li>
</ul>
openQA Tests - action #62480 (Workable): [qe-core][functional] Implement functions that return th...https://progress.opensuse.org/issues/624802020-01-21T14:31:43ZSLindoMansillaslindomansilla@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>At the moment, the TTY numbers are assigned to consoles when they are added (<a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/lib/susedistribution.pm#L454" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/lib/susedistribution.pm#L454</a>)</p>
<pre><code class="perl syntaxhl" data-language="perl"> <span class="nv">$self</span><span class="o">-></span><span class="nv">add_console</span><span class="p">('</span><span class="s1">install-shell</span><span class="p">',</span> <span class="p">'</span><span class="s1">tty-console</span><span class="p">',</span> <span class="p">{</span><span class="s">tty</span> <span class="o">=></span> <span class="mi">2</span><span class="p">});</span>
<span class="nv">$self</span><span class="o">-></span><span class="nv">add_console</span><span class="p">('</span><span class="s1">installation</span><span class="p">',</span> <span class="p">'</span><span class="s1">tty-console</span><span class="p">',</span> <span class="p">{</span><span class="s">tty</span> <span class="o">=></span> <span class="nv">check_var</span><span class="p">('</span><span class="s1">VIDEOMODE</span><span class="p">',</span> <span class="p">'</span><span class="s1">text</span><span class="p">')</span> <span class="p">?</span> <span class="mi">1</span> <span class="p">:</span> <span class="mi">7</span><span class="p">});</span>
<span class="nv">$self</span><span class="o">-></span><span class="nv">add_console</span><span class="p">('</span><span class="s1">install-shell2</span><span class="p">',</span> <span class="p">'</span><span class="s1">tty-console</span><span class="p">',</span> <span class="p">{</span><span class="s">tty</span> <span class="o">=></span> <span class="mi">9</span><span class="p">});</span>
<span class="c1"># On SLE15 X is running on tty2 see bsc#1054782</span>
<span class="nv">$self</span><span class="o">-></span><span class="nv">add_console</span><span class="p">('</span><span class="s1">root-console</span><span class="p">',</span> <span class="p">'</span><span class="s1">tty-console</span><span class="p">',</span> <span class="p">{</span><span class="s">tty</span> <span class="o">=></span> <span class="nv">get_root_console_tty</span><span class="p">});</span>
<span class="nv">$self</span><span class="o">-></span><span class="nv">add_console</span><span class="p">('</span><span class="s1">user-console</span><span class="p">',</span> <span class="p">'</span><span class="s1">tty-console</span><span class="p">',</span> <span class="p">{</span><span class="s">tty</span> <span class="o">=></span> <span class="mi">4</span><span class="p">});</span>
<span class="nv">$self</span><span class="o">-></span><span class="nv">add_console</span><span class="p">('</span><span class="s1">log-console</span><span class="p">',</span> <span class="p">'</span><span class="s1">tty-console</span><span class="p">',</span> <span class="p">{</span><span class="s">tty</span> <span class="o">=></span> <span class="mi">5</span><span class="p">});</span>
<span class="nv">$self</span><span class="o">-></span><span class="nv">add_console</span><span class="p">('</span><span class="s1">displaymanager</span><span class="p">',</span> <span class="p">'</span><span class="s1">tty-console</span><span class="p">',</span> <span class="p">{</span><span class="s">tty</span> <span class="o">=></span> <span class="mi">7</span><span class="p">});</span>
<span class="nv">$self</span><span class="o">-></span><span class="nv">add_console</span><span class="p">('</span><span class="s1">x11</span><span class="p">',</span> <span class="p">'</span><span class="s1">tty-console</span><span class="p">',</span> <span class="p">{</span><span class="s">tty</span> <span class="o">=></span> <span class="nv">get_x11_console_tty</span><span class="p">});</span>
<span class="nv">$self</span><span class="o">-></span><span class="nv">add_console</span><span class="p">('</span><span class="s1">tunnel-console</span><span class="p">',</span> <span class="p">'</span><span class="s1">tty-console</span><span class="p">',</span> <span class="p">{</span><span class="s">tty</span> <span class="o">=></span> <span class="mi">3</span><span class="p">})</span> <span class="k">if</span> <span class="nv">get_var</span><span class="p">('</span><span class="s1">TUNNELED</span><span class="p">');</span>
</code></pre>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> A hash in <code>/lib/Utils/TTY.pm</code> contains the assignment between console names and TTY numbers</li>
<li><strong>AC2:</strong> <code>/lib/Utils/TTY.pm</code> is properly documented</li>
</ul>
<a name="Considerations"></a>
<h2 >Considerations<a href="#Considerations" class="wiki-anchor">¶</a></h2>
<ul>
<li>Before making code changes, explain the team the idea of implementing this to avoid wasting time on a PR review.</li>
</ul>
openQA Tests - action #59014 (New): [qe-core][functional] Enhanced grub_test modulehttps://progress.opensuse.org/issues/590142019-11-04T10:11:34ZSLindoMansillaslindomansilla@suse.com
<a name="Tasks"></a>
<h2 >Tasks<a href="#Tasks" class="wiki-anchor">¶</a></h2>
<ol>
<li>grub_test always received from a previous module, a known system state, which is not changing over time.</li>
<li>grub_test always left the system for a following module, in a known system state, which is not changing over time.</li>
</ol>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Make grub_test wait for first line from the kernel, before handing over the control to the next module to ensure that the "enter" key was really pressed and got to the SUT.</li>
<li>Implement <code>NON_INTERACTIVE</code> setting to not wait for dracut.</li>
</ul>
openQA Tests - action #51857 (Workable): [qe-core][functional] create scenario upgrade_tumbleweed...https://progress.opensuse.org/issues/518572019-05-22T15:14:03Zggardet_armguillaume.gardet@arm.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>As a release manager, I want to have a real use case scenario where a user has a released tumbleweed snapshot installed which is then upgraded to the to be released snapshot.</p>
<p><code>upgrade_tumbleweed</code> should use released ISO instead of tested ISO, otherwise, installer may fail to boot properly.</p>
<p>openQA test in scenario opensuse-Tumbleweed-NET-aarch64-create_hdd_tumbleweed@aarch64 fails in<br>
<a href="https://openqa.opensuse.org/tests/939148/modules/welcome/steps/9" class="external">welcome</a></p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC:</strong> The use case of upgrading a released snapshot to the snapshot to be tested is covered in openQA</li>
</ul>
<a name="Tasks"></a>
<h2 >Tasks<a href="#Tasks" class="wiki-anchor">¶</a></h2>
<ol>
<li>Proper scenario's name to be decided.</li>
<li>Monitor the snapshot releases, when a new snapshot is released save the corresponding qcow2 image in the fixed directory</li>
<li>Once there's a new snapshot released, remove the previous 'published' </li>
<li>Update the repositories</li>
</ol>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since Build <a href="https://openqa.opensuse.org/tests/887460" class="external">20190304</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.opensuse.org/tests/869810" class="external">20190304</a></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.opensuse.org/tests/latest?version=Tumbleweed&machine=aarch64&test=create_hdd_tumbleweed&flavor=NET&arch=aarch64&distri=opensuse" class="external">latest</a></p>
openQA Tests - action #51413 (New): [qe-core][functional] Automatic checks for missing documentat...https://progress.opensuse.org/issues/514132019-05-13T09:24:06ZSLindoMansillaslindomansilla@suse.com
<a name="AC"></a>
<h2 >AC<a href="#AC" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC:</strong> It is ensured, that everyone adding new functionality also documents it</li>
</ul>
<a name="Tasks"></a>
<h2 >Tasks<a href="#Tasks" class="wiki-anchor">¶</a></h2>
<ol>
<li>Create a mechanism that runs <a href="https://metacpan.org/pod/Pod::Checker" class="external">pod-checker</a> and shows a list of undocumented functions under /lib</li>
<li>PR are not able to be merged if the check doesn't pass (or is below under a certain threshold)</li>
</ol>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ol>
<li>Take into account situations where routines/function are so small that don't need documentation, <code>##nodoc</code> could be an option to indicate the parser, that the following method doesn't need to be checked.</li>
<li>Document methods in /lib where it would be useful.</li>
<li>Figure and propose a podchecker documentation format (and use that script to for the automated checks on travis) (see poo#50510)</li>
</ol>
openQA Tests - action #48566 (New): [qe-core][functional] Crosscheck workaround for bsc#980337 in...https://progress.opensuse.org/issues/485662019-03-01T06:47:54Zokurzokurz@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP1-Installer-DVD-aarch64-extra_tests_on_gnome@aarch64 in<br>
<a href="https://openqa.suse.de/tests/2470908/modules/user_defined_snapshot/steps/80" class="external">user_defined_snapshot</a> shows that we reached gdm successfully but we still report a soft_failure pointing to <a href="https://bugzilla.suse.com/show_bug.cgi?id=980337" class="external">bsc#980337</a> which looks wrong.</p>
<a name="Conditional-acceptance-criteria"></a>
<h2 >Conditional acceptance criteria<a href="#Conditional-acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>CC1:</strong> The bug is verified fixed and the record_soft_fail removed
or</li>
<li><strong>CC2:</strong> The bug is still valid reopen the bug</li>
</ul>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Probably fails since SLE15 where the product eventually managed to boot successfully into gdm and we have not realized</p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>The bug should only be referenced in case we can <em>not</em> reach boot, or more specifically <em>not gdm</em></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?machine=aarch64&version=15-SP1&test=extra_tests_on_gnome&arch=aarch64&distri=sle&flavor=Installer-DVD" class="external">latest</a></p>
openQA Tests - action #48416 (New): [opensuse][leap] test fails in install_service - could not re...https://progress.opensuse.org/issues/484162019-02-26T08:13:06Zmlin7442mlin@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario opensuse-15.1-DVD-x86_64-zdup-Leap-42.2-gnome@64bit-2G fails in<br>
<a href="https://openqa.opensuse.org/tests/862634/modules/install_service/steps/8" class="external">install_service</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Looks like this is happened on 42.2/42.3 upgrade scenario(sporadic), I can't figure out.</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.opensuse.org/tests/862634" class="external">419.1</a> (current job)</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.opensuse.org/tests/860118" class="external">417.2</a> (or more recent)</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.opensuse.org/tests/latest?version=15.1&test=zdup-Leap-42.2-gnome&arch=x86_64&distri=opensuse&machine=64bit-2G&flavor=DVD" class="external">latest</a></p>
openQA Tests - action #46988 (New): [qe-core][functional] Detect known bugs from system journalhttps://progress.opensuse.org/issues/469882019-02-01T11:57:40Zokurzokurz@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>See parent ticket <a class="issue tracker-6 status-3 priority-4 priority-default closed parent" title="coordination: [saga][epic] Detection of "known failures" for stable tests, easy test results review and easy tr... (Resolved)" href="https://progress.opensuse.org/issues/39719">#39719</a> . As test reviewers we want to have less work to label jobs for known issues that can be detected from the system journal which we also upload</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> We have an easy way to reference bugs as soft-failures by looking at matching patterns in the system journal</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Take a look into the file <code>lib/known_bugs.pm</code> as introduced with 4fac2c92c</li>
<li>Extend pattern matching functionality to look into the system journal as well, maybe just use a matching pattern in the same file but used in the generic post_fail_hook that uploads the systemd journal, e.g. in lib/opensusebasetest.pm:problem_detection</li>
<li>Use example <a href="https://openqa.suse.de/tests/2429429#step/firefox/5" class="external">https://openqa.suse.de/tests/2429429#step/firefox/5</a> for detecting the firefox segfaulting on ppc64le</li>
<li>Use <a href="https://github.com/os-autoinst/os-autoinst/blob/master/testapi.pm#L232" class="external">force_soft_failure</a></li>
</ul>
openQA Tests - action #44468 (Workable): [qe-core][functional][tools] Proper handling of assets f...https://progress.opensuse.org/issues/444682018-11-28T16:37:47ZSLindoMansillaslindomansilla@suse.com
<a name="Motivation-Observation"></a>
<h2 >Motivation / Observation<a href="#Motivation-Observation" class="wiki-anchor">¶</a></h2>
<p>Trying to verify a <a href="https://build.suse.de/request/show/177956" class="external">SR</a> to fix the <a href="https://openqa.suse.de/tests/2263926#step/systemd_testsuite/17" class="external">systemd-testsuite</a>, I was blocked because OSD workers and QSF shared workers were malfunctioning.</p>
<p>The problem with QSF shared workers is that the needed qcow2 image was missing:</p>
<ul>
<li>sle-15-SP1-s390x-*<a href="mailto:-textmode@s390x-kvm-sle12.qcow2">-textmode@s390x-kvm-sle12.qcow2</a></li>
</ul>
<p>Because</p>
<ul>
<li><strong>openqa.suse.de</strong>:/var/lib/openqa/share/factory</li>
</ul>
<p>was NFS-mounted into</p>
<ul>
<li><strong>s390p8.suse.de</strong>:/var/lib/openqa/share/factory</li>
</ul>
<p>And the image were already cleaned up from <strong>openqa.suse.de</strong>:/var/lib/openqa/share/factory.</p>
<p>QSF shared-workers (shared-workers.qa.suse.de) have CACHEDIRECTORY configured, but this directory is ignored by the svirt backend.<br>
Only <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/6253" class="external">some changes in the test code</a> are necessary to take CACHEDIRECTORY into account, but some configuration is needed at infrastructure level.</p>
<ul>
<li><strong>shared-workers.qa.suse.de</strong>:/var/lib/openqa/cache</li>
</ul>
<p>needs to be made available from </p>
<ul>
<li><strong>s390p8.suse.de</strong>:/var/lib/openqa/cache</li>
</ul>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC:</strong> SUT's host machine on svirt backends (ie. s390p8.suse.de), which have a jump host (ie. shared-workers.qa.suse.de) with configured CACHEDIRECTORY, have available assets from that CACHEDIRECTORY.</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Look at what has already been done in that area, e.g. <a class="issue tracker-4 status-12 priority-4 priority-default" title="action: [qe-core][functional][tools] Proper handling of assets for svirt workers (Workable)" href="https://progress.opensuse.org/issues/44468#note-30">#44468#note-30</a>.</li>
</ul>
openQA Tests - action #42722 (New): [sle][systemd] test fails in systemd_testsuite - Race conditi...https://progress.opensuse.org/issues/427222018-10-19T11:52:36ZSLindoMansillaslindomansilla@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP1-Installer-DVD-x86_64-suse_patches-systemd_testsuite@64bit fails in<br>
<a href="https://openqa.suse.de/tests/2188633/modules/systemd_testsuite/steps/51" class="external">systemd_testsuite</a></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/2188633" class="external">75.6</a> (current job)</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/2182744" class="external">75.1</a> (or more recent)</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?distri=sle&flavor=Installer-DVD&arch=x86_64&test=suse_patches-systemd_testsuite&machine=64bit&version=15-SP1" class="external">latest</a></p>
openQA Tests - coordination #40484 (New): [qe-core][functional][epic] Move different checks to se...https://progress.opensuse.org/issues/404842018-08-31T12:42:59Zriafarov
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>We test some UI features which affect many and sometimes all test suites. Best example is test for proceeding without accepting license. This is important check, whereas if we want to know overall status of the build, will break all the tests. <br>
In case it's located in a separate test suite, we could still validate this functionality, but don't affect other tests.<br>
Same is valid for scenarios when some problem makes testing complex, e.g. screensaver. If we have separate test covering screensaver, we have low risk of missing something and have better stability as do not have to apply additional actions for screensaver detection.</p>
<p>installer_extended is one of test suites which can be used for UI changes <a href="https://openqa.suse.de/tests/2163370" class="external">https://openqa.suse.de/tests/2163370</a></p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ol>
<li>All such non-functional checks are identified and either addressed using this ticket, or as a sub-ticket</li>
<li>Only relevant tests are affected when some feature is broken</li>
</ol>
openQA Tests - coordination #39302 (New): [qe-core][functional][opensuse][epic][medium] uefi upgr...https://progress.opensuse.org/issues/393022018-08-08T07:43:45Zlnussellnussel@suse.com
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Ensure TW is a superset of Leap, i.e. add missing upgrade tests only on Leap to TW</li>
<li>If necessary according to lnussel add 42.1 upgrade tests by creating the assets somehow, manually or automatically</li>
</ul>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<a name="Original-observation"></a>
<h3 >Original observation<a href="#Original-observation" class="wiki-anchor">¶</a></h3>
<p>This problem affects O3 only (openqa.opensuse.org)<br>
When upgrading from any Leap version to TW.<br>
So, the assets are disk image with previous Leap installation.</p>
<p>In <a href="https://openqa.opensuse.org/tests/overview?distri=opensuse&version=15.1" class="external">https://openqa.opensuse.org/tests/overview?distri=opensuse&version=15.1</a></p>
<p>[2018-08-08T00:55:39.0872 CEST] [info] result: setup failure: Can't download <a href="mailto:opensuse-42.1-x86_64-Updates-20170213-1-cryptlvm@uefi.qcow2">opensuse-42.1-x86_64-Updates-20170213-1-cryptlvm@uefi.qcow2</a><br>
[2018-08-08T00:48:01.0851 CEST] [info] result: setup failure: Can't download <a href="mailto:opensuse-42.2-x86_64-Updates-20180206-1-cryptlvm@uefi.qcow2">opensuse-42.2-x86_64-Updates-20180206-1-cryptlvm@uefi.qcow2</a></p>
openQA Tests - action #34471 (New): [qe-core][functional][opensuse][medium] too early matching in...https://progress.opensuse.org/issues/344712018-04-08T06:13:41Zokurzokurz@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario opensuse-42.3-Updates-x86_64-textmode@64bit fails in<br>
<a href="https://openqa.opensuse.org/tests/652064/modules/zypper_up/steps/1" class="external">zypper_up</a></p>
<pre><code>[7 Apr 2018 21:01:23] <tacit> okurz: Somewhat more frequent unstable failure: https://openqa.opensuse.org/tests/652064#step/zypper_up/4 suspecting timing here as the root username is entered before the login promot
[7 Apr 2018 21:57:16] <okurz> tacit: well, problem is the not so good needle in https://openqa.opensuse.org/tests/652064#step/zypper_up/1 . as you can see on the '(i)' icon the test looks for tty6-selected and this is what we should use. What happens now that the test expects tt6, checks for just the generic needle, is happy with tty1, then the VM actually switches to tty6 but in the process the root name is already typed, only after that the getty is
[7 Apr 2018 21:57:16] <okurz> activated. But you know what, I think I have seen this slower behavior even manually. Was there some update to getty or systemd that could have caused a slow down here?
[8 Apr 2018 08:10:09] <okurz> tacit: So actually I would consider a product bug but try to remove our needles nevertheless. We can remove the needle but it might break some tests.
</code></pre>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.opensuse.org/tests/652064" class="external">20180407-3</a> (current job)</p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC:</strong> There should be no needle with tag "text-login" anymore but only tty$nr-specific ones as we did already for SLE to prevent premature matching</li>
</ul>
<a name="Tasks"></a>
<h2 >Tasks<a href="#Tasks" class="wiki-anchor">¶</a></h2>
<ol>
<li>Remove all needles with tag "text-login"</li>
<li>Fix the tests that use that needle tag.</li>
</ol>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Find current uses of the generic needles, e.g. "text-login-20160812" using <a href="https://openqa.opensuse.org/admin/needles">https://openqa.opensuse.org/admin/needles</a></li>
<li>Make sure there exist valid tty$nr-selected needles for all cases where text-login is matched on</li>
<li>Delete the too generic needles</li>
<li>Crosscheck carefully that all tests on o3 do not fail because of now deleted needles where there is no tty$nr-replacement.</li>
</ul>
<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.opensuse.org/tests/latest?distri=opensuse&machine=64bit&flavor=Updates&test=textmode&version=42.3&arch=x86_64" class="external">latest</a></p>
<p>See <a class="issue tracker-4 status-3 priority-5 priority-high3 closed behind-schedule" title="action: [functional][medium] tty login needles are matched prematurely, username typing gets lost (was: n... (Resolved)" href="https://progress.opensuse.org/issues/33097">#33097</a> for the work that has been done for the corresponding SLE needles.</p>
Travel Support and merchandising mgmt - action #3252 (New): Deadline field for the shipment requestshttps://progress.opensuse.org/issues/32522014-08-22T12:10:13Zancorgsancor@suse.com
<p>The Shipments should have a "deadline" field, since it might happen that the person receiving it has to start travelling early and might need the stuff earlier.</p>