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 #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 - coordination #53249 (New): [epic][qe-core][functional] ensure that grub_test gets ...https://progress.opensuse.org/issues/532492019-06-18T09:05:07Zjorauchjrauch@suse.com
<a name="Description"></a>
<h2 >Description<a href="#Description" class="wiki-anchor">¶</a></h2>
<p>Sometimes it happens that the system is not yet shutdown and rebooting from the previous module when entering grub_test.<br>
This has been seen after trying to workaround the missed tiano core screen on aarch64: <a href="https://openqa.opensuse.org/tests/940347#step/grub_test/1" class="external">https://openqa.opensuse.org/tests/940347#step/grub_test/1</a></p>
<p>We need to ensure that the booting is in progress as soon as we enter grub_test</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> The tasks 1, 2 and 3 are done before changing the code.</li>
<li><strong>AC2:</strong> This ticket is refined again after tasks 1, 2 and 3 are done.</li>
<li><strong>AC3:</strong> The problem is fixed.</li>
</ul>
<a name="Tasks"></a>
<h2 >Tasks<a href="#Tasks" class="wiki-anchor">¶</a></h2>
<ol>
<li>Find in which tests scenarios, the following modules are NOT schedule: reboot_after_installation, first_boots</li>
<li>In which scenarios grub_test is schedule, and what is the previous module that was executed?</li>
<li>Find all modules executed after installation, reboot, boot
<ul>
<li>Migrate the data in the picture to confluence (do NOT upload the picture)</li>
</ul></li>
</ol>
<p><em>. *Unify all the scenarios to use wait_boot</em> not to be done yet</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 - coordination #50510 (New): [qe-core][functional][epic] write documentation for lib...https://progress.opensuse.org/issues/505102019-04-17T09:21:27Zjorauchjrauch@suse.com
<p>Each function in the lib/ folder needs to be documented with POD</p>
<a name="AC"></a>
<h2 >AC<a href="#AC" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> Most of the functions are documented</li>
<li><strong>AC2:</strong> Undocumented functions are marked as undocumented</li>
<li><strong>AC3:</strong> each function in lib/ has a POD block that explains it</li>
</ul>
<a name="How-to-write-the-documentation"></a>
<h2 >How to write the documentation<a href="#How-to-write-the-documentation" class="wiki-anchor">¶</a></h2>
<ul>
<li>At level one we have the name of the module and a short synopsis with brief description</li>
<li>At level two we have the names of each functions before the functions</li>
</ul>
<pre><code class="perl syntaxhl" data-language="perl"><span class="cm">=head1 MY_MODULE
=head1 SYNOPSIS
use lib::my_module
This is a module that does foobar
=cut</span>
<span class="k">use</span> <span class="nv">testapi</span>
<span class="k">use</span> <span class="nv">stuff</span>
<span class="k">use</span> <span class="nv">other_stuff</span>
<span class="cm">=head2 my_function
my_function($arg1, $arg2);
a single space before it is required!
format for list item:
=over
=item * list 1
=item * list 2
=back
This is a function that does nothing because it's for documentation purposes
Describe here also, what C<$arg1> and C<$arg2> will do and also cover what the function returns if applicable.
=cut</span>
<span class="k">sub </span><span class="nf">my_function</span> <span class="p">{}</span>
</code></pre> openQA Tests - coordination #50507 (New): [qe-core][functional][saga] document lib/ functionshttps://progress.opensuse.org/issues/505072019-04-17T09:17:05Zjorauchjrauch@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>As we currently have no documentation for the functions in lib/ we need a mechanism to automatically generate it from POD inside the files.</p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>The team decided to apply the best practices described in <a href="https://www.perl.com/pub/2005/07/14/bestpractices.html/" class="external">https://www.perl.com/pub/2005/07/14/bestpractices.html/</a></p>
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 #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>