openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842022-07-18T11:16:56ZopenSUSE Project Management Tool
Redmine openQA Infrastructure - action #113716 (Resolved): [qe-core] proxy-scc is downhttps://progress.opensuse.org/issues/1137162022-07-18T11:16:56Zmaritawernermawerner@suse.com
<p>On Friday, July 15, at 10.45 the proxy-scc stopped working. A Jira SD ticket for eng infra was raised by QE: <a href="https://sd.suse.com/servicedesk/customer/portal/1/SD-92678" class="external">https://sd.suse.com/servicedesk/customer/portal/1/SD-92678</a></p>
<p>In the slack channel help-scc Jiri Novak and Thomas Schmidt from the SCC team discussed the technical details:<br>
<a href="https://suse.slack.com/archives/C02AYV7UJSD/p1657792209257829" class="external">https://suse.slack.com/archives/C02AYV7UJSD/p1657792209257829</a></p>
<p>In short: the very old caasp cluster will be replaced by a Kubernetes instance.</p>
openQA Tests - action #11458 (Resolved): Feature 319716: Automatic Update of YaST at beginning of...https://progress.opensuse.org/issues/114582016-04-01T13:04:25Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/319716" class="external">https://fate.suse.com/319716</a></p>
<p>First check if the Feature status is "done".</p>
<a name="tasks-left-to-be-done"></a>
<h2 >tasks left to be done<a href="#tasks-left-to-be-done" class="wiki-anchor">¶</a></h2>
<ul>
<li>verify on osd that it's triggered as <code>yast_no_self_update</code> on 12-sp2 server build > 2002</li>
<li>add to o3</li>
<li>optionally: extend to check that the installer really updates itself in case an update is present</li>
</ul>
openQA Tests - action #11456 (Resolved): Feature 319639: Set hostname in Installer properlyhttps://progress.opensuse.org/issues/114562016-04-01T13:03:11Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/319639" class="external">https://fate.suse.com/319639</a></p>
<p>First check if the Feature status is "done".</p>
<p>All components of the Installer depend on correctly configured network. Current system hostname is, e.g. used as "the default" when user tries to (re)configure their network in Installer. This configuration checks validity of entered (or default) values and complain when something is wrong. This confuses users as we are expected to provide sane defaults (or nothing).</p>
<p>When Linuxrc is in charge of configuring network (e.g. when installation is started with ifcfg=*=dhcp or when Linuxrc just needs network) the inst-sys then resolves own hostname to the ip address of "first" network interface. It confuses all tools which depends on the resolver's result (e.g. hostname --fqdn)</p>
<p>Proper behavior should be (very simple one out of several possible scenarios):</p>
<pre><code>use a hostname provided by DHCP server (if any) or
return "not resolvable" error
</code></pre>
<p>The question is: What to use as a system name (e.g., for command line) in inst-sys? It seems that "installer" or "suse" would just do the job.</p>
<p>For SLE 12 SP1 it was hotfixed on yast side (see <a href="https://bugzilla.suse.com/show_bug.cgi?id=946047" class="external">https://bugzilla.suse.com/show_bug.cgi?id=946047</a> for reference)</p>
<p>Purpose of this request is to get proper fix into linuxrc and to drop above hotfix from yast, so affrected pieces are (probably): Linuxrc, installation-images and yast2</p>
openQA Tests - action #11454 (Resolved): Feature 319624: YaST - Existing SSH Host Keys Dialoghttps://progress.opensuse.org/issues/114542016-04-01T13:02:05Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/319624" class="external">https://fate.suse.com/319624</a></p>
<p>First check if the Feature status is "done".</p>
<p>YaST has the following feature that could lead to security implications.</p>
<a name="httpswwwsusecomdocumentationsles-12book_sle_deploymentdatasec_i_yast2_proposalhtml"></a>
<h2 ><a href="https://www.suse.com/documentation/sles-12/book_sle_deployment/data/sec_i_yast2_proposal.html" class="external">https://www.suse.com/documentation/sles-12/book_sle_deployment/data/sec_i_yast2_proposal.html</a><a href="#httpswwwsusecomdocumentationsles-12book_sle_deploymentdatasec_i_yast2_proposalhtml" class="wiki-anchor">¶</a></h2>
<p>HINT: Existing SSH Host Keys</p>
<a name="If-you-install-SUSE-Linux-Enterprise-Server-on-a-machine-with-one-or-more-existing-Linux-installations-the-installation-routine-automatically-imports-the-SSH-host-key-with-the-most-recent-access-time-from-an-existing-installation"></a>
<h2 >If you install SUSE Linux Enterprise Server on a machine with one or more existing Linux installations, the installation routine automatically imports the SSH host key with the most recent access time from an existing installation.<a href="#If-you-install-SUSE-Linux-Enterprise-Server-on-a-machine-with-one-or-more-existing-Linux-installations-the-installation-routine-automatically-imports-the-SSH-host-key-with-the-most-recent-access-time-from-an-existing-installation" class="wiki-anchor">¶</a></h2>
<p>If a system was compromised the keys shouldn't be used during system re-installation. Currently the user needs to delete the keys manually or to delete the complete partition table so that YaST will not find the data during installation.</p>
<p>The idea of this feature is to have a special YaST dialog that notifies the user that an old system was found and offers the option to import the existing SSH keys. This would make the import and the already existing feature more transparent.</p>
<p>The current list is here, in control file: <a href="https://github.com/yast/skelcd-control-SLES/blob/d2f9a79c0681806bf02eb38c4b7c287b9d9434eb/control/control.SLES.xml#L53-L71" class="external">https://github.com/yast/skelcd-control-SLES/blob/d2f9a79c0681806bf02eb38c4b7c287b9d9434eb/control/control.SLES.xml#L53-L71</a> </p>
openQA Tests - action #11452 (Resolved): Feature 318945: AutoYaST EULA displayhttps://progress.opensuse.org/issues/114522016-04-01T13:00:40Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/318945" class="external">https://fate.suse.com/318945</a><br>
Feature status is "done".</p>
<p>During the SLES12 Common Criteria AutoYaST profile development we came across a limitation that the EULA page cannot be shown and accepted during the installation.</p>
<p>As the Common Criteria AutoYaST profiles for SLES12 are predefined and not created by a system administrator the EULA needs to be accepted during installation. Right now we use the Firstboot YaST service to show the EULA during first system boot.</p>
<p>Acceptance criteria:</p>
<ul>
<li>define and document the way customers using AutoYaST should accept the EULA</li>
</ul>
openQA Tests - action #11450 (Resolved): Feature 318787: YaST logic on Network Restart while no c...https://progress.opensuse.org/issues/114502016-04-01T12:59:32Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/318787" class="external">https://fate.suse.com/318787</a></p>
<p>First check if the Feature status is "done". Feature is marked as "done".</p>
openQA Tests - action #11448 (Resolved): Feature 318405: implement bash autocompletion for btrfs ...https://progress.opensuse.org/issues/114482016-04-01T12:58:08Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/318405" class="external">https://fate.suse.com/318405</a></p>
<p>First check if the Feature status is "done".</p>
<p>Customer requests a zypper-like autocompletion for btrfs command, so double-tab shows the next layer of valid commands and options. From customer point of view this would help a lot on moving over to a new technology and raises acceptance as operations made easier for operators.</p>
openQA Tests - action #11446 (Resolved): Feature 318144: Btrfs quota group improvementshttps://progress.opensuse.org/issues/114462016-04-01T12:57:11Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/318144" class="external">https://fate.suse.com/318144</a></p>
<p>First check if the Feature status is "done".</p>
<p>I propose that I improve the implementation of btrfs quota groups beyond what we had for SLES-12 GA. The benefits to this work would be that snapper and our end users would get improved accounting of space usage on btrfs. In addition I list a few items which are intended to generally improve the quality of btrfs quota groups.</p>
<p>Specifically:</p>
<p>Kernel Tasks:</p>
<ul>
<li><p>Implement hierarchical quota groups. This way snapper could create parent groups which account properly for the groups below them. This may have a performance impact on quota rescan though.</p></li>
<li><p>Delete qgroup items on subvolume deletion (I wanted this for us earlier but it turned out to be more complicated than initially thought)</p></li>
</ul>
<p>Btrfsprogs:</p>
<ul>
<li><p>Accounting of heirarchical groups in btrfsck (right now btrfsck only cares about level 0 groups)</p></li>
<li><p>btrfsck to write out fixed qgroup items. This prevents user from having to do a rescan on unclean shutdown.</p></li>
</ul>
openQA Tests - action #11444 (Closed): Feature 318101: Show user defined comments in grub2 menu f...https://progress.opensuse.org/issues/114442016-04-01T12:56:05Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/318101" class="external">https://fate.suse.com/318101</a></p>
<p>First check if the Feature status is "done".</p>
openQA Tests - action #11442 (Resolved): Feature 317970: Remove creation of autoyast profile duri...https://progress.opensuse.org/issues/114422016-04-01T12:54:55Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/317970" class="external">https://fate.suse.com/317970</a></p>
<p>Feature status is "done".</p>
<p>With SLES10/SLES11, we did create an autoyast profile at the end of the installation. With both products doing a full system configuration during installation, this did made sense.</p>
<p>With SLES12, most things are no longer configureable during installation and we suggest to the customer to configure it later in the running system. So a lot of config entries are missing from this autoyast profile. And the resulting autoyast profile is different then if you create it later in the running system.</p>
<p>Thus we should stop creating the autoyast profile during installation and only concentrate on doing it later in the running system.</p>
openQA Tests - action #11440 (Resolved): Feature 317897: [BETA 1] Provide minimal possible size o...https://progress.opensuse.org/issues/114402016-04-01T12:52:10Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/317897" class="external">https://fate.suse.com/317897</a><br>
Feature status is "done".</p>
<p>The btrfs allows shrinking but to use that feature from YaST it is required to know the minimal possible size in advance. Currently this is not possible to query that size.</p>
<p>The btrfs command could provide the value for YaST.</p>
openQA Tests - action #11436 (Resolved): Feature 317701: Additional bootloader testing: Do not us...https://progress.opensuse.org/issues/114362016-04-01T12:50:07Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/317701" class="external">https://fate.suse.com/317701</a></p>
<p>First check if the Feature status is "done".</p>
<p>In past perl-Bootloader is used as abstraction layer over various bootloaders and also as a way how to not write code in ycp for bootloader.<br>
Now situation is completelly different. Yast code is in ruby. We support only single bootloader. And last but not least GRUB2 configuration is just writting some values to inifile like files and run some scripts.<br>
In such situation perl-Bootloader just adds additional source of problems with no clear benefits.</p>
<p>So proposal is to write config files and run scripts directly in yast2-bootloader and keep perl-Bootloader only as thin layer for updating kernel to ensure menu is regenerated after new kernel installation.</p>
openQA Tests - action #11432 (Resolved): Feature 312751: snapper: cleanup rules based on free spa...https://progress.opensuse.org/issues/114322016-04-01T12:46:57Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/312751" class="external">https://fate.suse.com/312751</a></p>
<p>First check if the Feature status is "done".</p>
<p>Description:</p>
<p>During a discussion in the Beta tester group we found that it would be useful not only cleanup btrfs snapshots based on "age", but also depending on the filesystem's fill-level and/or free space</p>
openQA Tests - action #11332 (Resolved): Install SMT pattern on SLES 12 SP1 then migrate from SP1...https://progress.opensuse.org/issues/113322016-03-29T13:55:32Zmaritawernermawerner@suse.com
<ul>
<li>Install SLES 12 SP1</li>
<li>Install SMT, see <a href="https://www.suse.com/documentation/sles-12/book_smt/data/smt_installation.html" class="external">https://www.suse.com/documentation/sles-12/book_smt/data/smt_installation.html</a></li>
<li>Migrate from SP1 to SP2 and make sure that SMT still works</li>
<li>Note: SMT pulls MySQL, might have some impacts</li>
</ul>
openQA Tests - action #11330 (Resolved): Install SMT pattern on SLES 12 SP2https://progress.opensuse.org/issues/113302016-03-29T13:52:22Zmaritawernermawerner@suse.com
<ul>
<li>Install SLES 12 SP2</li>
<li>Install SMT pattern, see <a href="https://www.suse.com/documentation/sles-12/book_smt/data/smt_installation.html" class="external">https://www.suse.com/documentation/sles-12/book_smt/data/smt_installation.html</a></li>
<li>make sure everything works fine</li>
<li>Note: SMT pulls MySQL, might have some impacts</li>
<li>Note: SMT & proxy SCC might have some impacts</li>
</ul>