openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842021-10-25T13:29:26ZopenSUSE Project Management Tool
Redmine openQA Project - action #101457 (New): Native per-module bug tagshttps://progress.opensuse.org/issues/1014572021-10-25T13:29:26Zrpalethorperichard.palethorpe@suse.com
<a name="Motivation"></a>
<h1 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h1>
<p>We need to tag individual modules (e.g. LTP tests) within a job. Presently we (kernel qa) do this within job comments using syntax like "test123: bug#123". This requires parsing job comments.</p>
<p>Other teams have different solutions, like parsing external YAML files and marking individual modules as soft-failed.</p>
<p>Providing a single structured data source in OpenQA will simplify reporting and bug tag propagation.</p>
<a name="Goal"></a>
<h1 >Goal<a href="#Goal" class="wiki-anchor">¶</a></h1>
<p>Provide simple interface through OpenQA to:</p>
<ul>
<li>assign a bug to a job module</li>
<li>query the bug assigned to a job module</li>
<li>remove a bug from a job module</li>
</ul>
<p>I think a single reference to one bug tracker is sufficient. Related items in other trackers can be handled by one external tracker (e.g. Redmine).</p>
<a name="Non-Goals"></a>
<h1 >Non-Goals<a href="#Non-Goals" class="wiki-anchor">¶</a></h1>
<ul>
<li>Propagate bugs from one build to the next</li>
<li>Notifications or reporting</li>
</ul>
<a name="Alternatives"></a>
<h1 >Alternatives<a href="#Alternatives" class="wiki-anchor">¶</a></h1>
<ul>
<li>External service and database (e.g <a href="https://gitlab.suse.de/kernel-qa/bugtags" class="external">https://gitlab.suse.de/kernel-qa/bugtags</a>)</li>
</ul>
openQA Tests - action #62339 (Rejected): [kernel][ltp] <syscall> slept too long failures in VMshttps://progress.opensuse.org/issues/623392020-01-20T08:58:37Zrpalethorperichard.palethorpe@suse.com
<p>Sometimes timing tests fail with this, especially on ARM. As we are running the tests in VMs on hosts with lots of contention, this is most likely caused by the environment.</p>
openQA Project - action #55751 (Resolved): Formatting for <br> and <code> tags in job description...https://progress.opensuse.org/issues/557512019-08-20T08:14:55Zrpalethorperichard.palethorpe@suse.com
<p>Previously we could write to force a line break in comments. Also we could use tags.</p>
<p>It seems these are now ignored or filtered. See:<br>
<a href="https://openqa.suse.de/group_overview/155" class="external">https://openqa.suse.de/group_overview/155</a></p>
<p>and <a href="https://openqa.suse.de/tests/3262174#comment-195942" class="external">https://openqa.suse.de/tests/3262174#comment-195942</a></p>
<p><em>hint</em> Look at the raw text</p>
<p>For job group descriptions we can switch to using Markdown style code sections if that works. However we need the tags for comments because they are submitted as a single line of text to the openqa cli. Of course someone could fix the cli and newline handling in comments.</p>
openQA Project - action #53891 (Resolved): [openqa] Posting comments results in getting comments ...https://progress.opensuse.org/issues/538912019-07-05T09:22:17Zrpalethorperichard.palethorpe@suse.com
<p>Take the following:</p>
<p>rich@rpws ~> openqa-client --host openqa.opensuse.org --apikey CB3705D3354546E0 --apisecret XXX jobs/975114/comments POST text=test123<br>
[<br>
{<br>
bugrefs => [],<br>
created => "2019-07-05 08:15:47 +0000",<br>
id => 43271,<br>
renderedMarkdown => "update comment test\n",<br>
text => "update comment test",<br>
updated => "2019-07-05 08:45:11 +0000",<br>
userName => "rpalethorpe",<br>
},<br>
]<br>
rich@rpws ~> openqa-client --host <a href="https://openqa.opensuse.org" class="external">https://openqa.opensuse.org</a> --apikey CB3705D3354546E0 --apisecret XXX jobs/975114/comments POST text=test123<br>
{ id => 43287 }</p>
<p>okurz thinks this may be due to <a href="https://github.com/os-autoinst/openQA/pull/2110" class="external">https://github.com/os-autoinst/openQA/pull/2110</a>.</p>
<p>Note that this only happens on O3 and not OSD. I also tried using two different versions of the openqa-client. Also the following works:</p>
<p>openqa-client --host openqa.opensuse.org --apikey CB3705D3354546E0 --apisecret XXX jobs/975114/comments/43271 PUT text="update comment test"<br>
{ id => 43271 }</p>
<p>So the problem maybe only effects POST requests.</p>
openQA Project - action #48182 (Resolved): [openqa] Disable bug carry over for a job grouphttps://progress.opensuse.org/issues/481822019-02-21T09:39:53Zrpalethorperichard.palethorpe@suse.com
<p>Because we have an <a href="https://gitlab.suse.de/rpalethorpe/jdp/blob/master/notebooks/Propagate%20Bug%20Tags.ipynb" class="external">external script</a> for propagating bug tags, we need to remove OpenQA's carry over comments.</p>
<p>In fact OpenQA's carry over comments are almost always wrong for the Kernel group anyway. They have also begun dropping the message stating they are a carry over comment. This makes deleting them more challenging. For example I did not post the following comment <a href="https://openqa.suse.de/tests/2481835#comment-165567" class="external">https://openqa.suse.de/tests/2481835#comment-165567</a> and neither did my script (you can see the bug summary is stale).</p>
<p>Alternatively to disabling the comments, we could parse any existing comments and check if they are doing something suspicious, like tagging a passing test. Then delete/modify those comments, however this could result in legitimate comments being deleted (or modified) in corner cases. The user should be able to override the script so I don't think this is a good idea.</p>
<p>AFAICT it is not currently possible to disable bug carry over for a given job group.</p>
openQA Project - action #40538 (Workable): Reset/Clear guest RAM when it reboots in QEMU to reduc...https://progress.opensuse.org/issues/405382018-09-03T14:22:40Zrpalethorperichard.palethorpe@suse.com
<p>During installation 4GB+ of RAM can be used by the guest. Most of the time the RAM usage is much lower than this.</p>
<p>After installation completes the system is rebooted and then a snapshot is taken. In theory the snapshot should be very small because the system has only just booted, however it appears that QEMU thinks all the RAM is still in use and saves it to the snapshot. This might not be unexpected because on bare metal the RAM is preserved between reboots on modern systems. However, assuming that it is not relied upon by the guest OS, we don't need it to happen and can save some time.</p>
<p>Some ideas to solve this:</p>
<ul>
<li>Use the virtio memory balloon</li>
<li>Use the -no-reboot switch and restart the QEMU process if it exits unexpectedly.</li>
<li>Patch QEMU to clear (some of) the RAM when the guest initiates a reboot.</li>
</ul>
openQA Project - action #40520 (New): SKIPTO fails to load snapshotshttps://progress.opensuse.org/issues/405202018-09-03T10:41:57Zrpalethorperichard.palethorpe@suse.com
<p>There appear to be multiple problems with this feature. In particular when using MAKETESTSNAPSHOTS.</p>
<p>Sometimes loading snapshots works as expected, but others it fails with various different error messages. Some of them from QEMU directly and others from the QEMU backend.</p>
<p>One error from the backend is:<br>
DIE Sequence mismatch while loading 'shutdown-shutdown' snapshot state: 30 != 28 at /home/geekotest/os-autoinst/OpenQA/Qemu/SnapshotConf.pm line 102.</p>
<p>Another from QEMU is:<br>
[2018-09-03T10:33:04.0775 CEST] [debug] QEMU: qemu-system-aarch64: Unknown savevm section or instance '0000:00:06.0/virtio-scsi' 0<br>
[2018-09-03T10:33:04.0775 CEST] [debug] QEMU: qemu-system-aarch64: load of migration failed: Invalid argument</p>
<p>Restarting the same job multiple times with SKIPTO seems to increase the chances of a failure.</p>
openQA Project - action #38822 (Resolved): Qemu: Could not open backing file: Cannot reference an...https://progress.opensuse.org/issues/388222018-07-25T09:41:54Zrpalethorperichard.palethorpe@suse.com
<p>When trying to revert to a snapshot QEMU dies with the following error or something similar:</p>
<pre><code>-blockdev driver=qcow2,node-name=hd0-overlay1,file=hd0-overlay1-file,cache.no-flush=on,backing=hd0: Could not open backing file: Cannot reference an existing block device with additional options or a new filename
</code></pre>
<p>The backing file is the hd0 block device which is specified on the command line. Possibly we should not specify block devices used as backing files on the command line and just allow them to be read from the overlay file. It is not clear what the expected usage is.</p>
openQA Project - action #36460 (Resolved): [kernel][tools] QEMU Refactor - Performance settingshttps://progress.opensuse.org/issues/364602018-05-23T14:02:30Zrpalethorperichard.palethorpe@suse.com
<p>Decide on cache mode and 'discard'.</p>
openQA Project - action #36034 (Rejected): [kernel][tools] QEMU Refactor - Regression, first Grub...https://progress.opensuse.org/issues/360342018-05-09T11:08:11Zrpalethorperichard.palethorpe@suse.com
<p><a href="http://rpws.suse.cz/tests/237#step/grub_test/5" class="external">http://rpws.suse.cz/tests/237#step/grub_test/5</a></p>
<p>It appears that some files are missing from there expected location, possibly the disk configuration is not stable. Pinning the drive serial numbers may help.</p>
openQA Project - action #35815 (Resolved): [kernel][tools] Refactor QEMU backend - Fix VNC instal...https://progress.opensuse.org/issues/358152018-05-03T10:32:31Zrpalethorperichard.palethorpe@suse.com
<p>It appears that switching to the installation text console is broken with the new version (install-shell) in the logpackages test. Nothing happens when select console is called, it just stays in the graphical shell. However switching to the 'root-console' does work.</p>
openQA Project - action #35443 (Resolved): [kernel][tools] QEMU Refactor - Acceptance testinghttps://progress.opensuse.org/issues/354432018-04-24T16:06:49Zrpalethorperichard.palethorpe@suse.com
<p>Test on all architectures and backends. Test with interactive mode.</p>
openQA Project - action #35440 (Resolved): [kernel][tools] QEMU Refactor - Code format and rebasehttps://progress.opensuse.org/issues/354402018-04-24T16:02:55Zrpalethorperichard.palethorpe@suse.com
<p>Rebase onto master branch, use perl format and rebase the commit log.</p>
openQA Project - action #35437 (Resolved): [kernel][tools] QEMU Refactor - Publish diskhttps://progress.opensuse.org/issues/354372018-04-24T16:00:01Zrpalethorperichard.palethorpe@suse.com
<p>Write the overlays into a copy of the base block device image and publish it (do_extract_assets).</p>
openQA Project - action #35434 (Resolved): [kernel][tools] QEMU Refactor - Ensure consistent use ...https://progress.opensuse.org/issues/354342018-04-24T15:54:46Zrpalethorperichard.palethorpe@suse.com
<p>Replace verbose for loops and similar with standard library functions. Also just try to reduce verbosity in general.</p>