openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842024-03-19T14:15:29ZopenSUSE Project Management Tool
Redmine openQA Project - coordination #157537 (Blocked): [epic] Secure setup of openQA test machines with...https://progress.opensuse.org/issues/1575372024-03-19T14:15:29Zokurzokurz@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>In <a href="https://sd.suse.com/servicedesk/customer/portal/1/SD-150437" class="external">https://sd.suse.com/servicedesk/customer/portal/1/SD-150437</a> we are asked to handle "compromised root passwords in QA segments" including s390zl11…16 . We should secure our network and password handling better.</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> No openQA machine test machines directly accessible by SUSE users use ssh root with publically known passwords</li>
</ul>
<a name="Ideas"></a>
<h2 >Ideas<a href="#Ideas" class="wiki-anchor">¶</a></h2>
<ol>
<li>Be able to set a different password valid for tests, in particular s390kvm…, e.g. be able to set password by test variable and follow through in the complete test platform -> <a class="issue tracker-4 status-1 priority-5 priority-high3 child" title="action: [spike][timeboxed:10h] Use a different ssh root password for s390x kvm installation openQA jobs (New)" href="https://progress.opensuse.org/issues/157555">#157555</a></li>
<li>Key based authentication -> <a class="issue tracker-4 status-15 priority-4 priority-default child" title="action: [spike][timeboxed:10h] Use ssh key authentication in particular for s390x kvm installation openQA... (Blocked)" href="https://progress.opensuse.org/issues/157744">#157744</a></li>
<li>Rotating, automatic passwords saved as test variables connected to images, e.g. to be able to use a pre-installed image</li>
<li>Better secure the networks to have s390kvm… (and others) less accessible -> We have stated the requirement in <a href="https://confluence.suse.com/pages/viewpage.action?pageId=1006108843" class="external">https://confluence.suse.com/pages/viewpage.action?pageId=1006108843</a> that ssh 22/tcp needs to be reachable. We could try to replicate the setup we know from o3 to give OSD a second network interface which allows ssh 22/tcp and block ssh 22/tcp on .oqa.prg2.suse.org as usually we don't need ssh to workers, just from within the oqa network as well as for administrative purposes for which we could go over OSD which we also already normally do for salt. -> <a class="issue tracker-4 status-1 priority-4 priority-default child" title="action: Better secure the networks to have s390kvm… (and others) less accessible (New)" href="https://progress.opensuse.org/issues/157750">#157750</a></li>
</ol>
openQA Project - coordination #152847 (Blocked): [epic] version control awareness within openQA f...https://progress.opensuse.org/issues/1528472023-12-21T12:48:46Zokurzokurz@suse.comQA - coordination #129280 (Blocked): [epic] Move from SUSE NUE1 (Maxtorhof) to new NBG Datacentershttps://progress.opensuse.org/issues/1292802023-05-15T07:12:10Zokurzokurz@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>SUSE NUE1 is being evacuated so we need to ensure our services are provided from other places and that NUE1 has been evacuated by us.</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> NUE1 (Maxtorhof) is not relied upon by SUSE QE Tools anymore and has been evacuated by us</li>
</ul>
<a name="Ideas"></a>
<h2 >Ideas<a href="#Ideas" class="wiki-anchor">¶</a></h2>
<ul>
<li>"To-be-decommissioned" machines obviously should not be moved to a new datacenter</li>
<li>Consider decommissioning some more machines in the process, e.g. "qanet" which should be replaced by Eng-Infra maintained DHCP+DNS same as we have in PRG1, PRG2, NUE2 (e.g. FC Basement) and also qanet does not have proper remote management capabilities</li>
<li>Some machines might be better moved to FC Basement rather than new NBG Datacenter</li>
</ul>
QA - coordination #123800 (Blocked): [epic] Provide SUSE QE Tools services running in PRG2 aka. P...https://progress.opensuse.org/issues/1238002023-01-30T14:46:55Zokurzokurz@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>SUSE is deprecating NUE1 (Maxtorhof) and setting up a Prague Co-Location datacenter "Prg CoLo" or "DC7" as primary location in particular for serving public services. This includes what we serve so far from VM clusters managed by EngInfra and in particular the openqa.opensuse.org infrastructure, likely also openqa.suse.de. We must participate in planning and setup and accordingly a migration until we can provide our services from Prg CoLo.</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> SUSE QE Tools services are provided out of Prg CoLo</li>
</ul>
QA - coordination #121720 (Blocked): [saga][epic] Migration to QE setup in PRG2+NUE3 while ensuri...https://progress.opensuse.org/issues/1217202022-12-08T19:30:27Zokurzokurz@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>SUSE is deprecating NUE1 (Maxtorhof) and setting up a Prague Co-Location datacenter "Prg CoLo" or "DC7" as primary location in particular for serving public services. This includes what we serve so far from VM clusters managed by EngInfra and in particular the openqa.opensuse.org infrastructure, likely also openqa.suse.de. Or defined differently: Everything that is currently served from NUE1-SRV1. We must participate in planning and setup and accordingly a migration until we can provide our services from Prg CoLo and do not rely on NUE1-SRV1 anymore except for the purpose of an optional fail-over datacenter in Nbg.<br>
SUSE is deprecating NUE1 (Maxtorhof) and setting up replacement data centers. Additionally a new datacenter is planned as fail-over location</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> SUSE QE Tools services are provided out of Prg CoLo <a class="issue tracker-6 status-15 priority-4 priority-default child parent behind-schedule" title="coordination: [epic] Provide SUSE QE Tools services running in PRG2 aka. Prg CoLo (Blocked)" href="https://progress.opensuse.org/issues/123800">#123800</a></li>
<li><strong>AC2:</strong> NUE1 (Maxtorhof) is not relied upon by SUSE QE Tools anymore and has been evacuated by us <a class="issue tracker-6 status-15 priority-5 priority-high3 child parent behind-schedule" title="coordination: [epic] Move from SUSE NUE1 (Maxtorhof) to new NBG Datacenters (Blocked)" href="https://progress.opensuse.org/issues/129280">#129280</a></li>
<li><strong>AC3:</strong> Relevant SUSE QE Tools services are provided out of NUE3 <a class="issue tracker-6 status-3 priority-4 priority-default closed child parent" title="coordination: [epic] Migration out of SUSE NUE1 - QE setup in NUE3 (Resolved)" href="https://progress.opensuse.org/issues/130955">#130955</a></li>
</ul>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Coordination chat room <a href="https://suse.slack.com/archives/C04MDKHQE20" class="external">#dct-migration</a></p>
openQA Project - coordination #58184 (Blocked): [saga][epic][use case] full version control aware...https://progress.opensuse.org/issues/581842019-10-15T10:19:57Zokurzokurz@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>This is linked to <a href="https://progress.opensuse.org/projects/openqav3/wiki#Use-case-4" class="external">Use case 4</a> and motivated by a discussion by the QA tools team in the weekly meeting 2019-10-15. What we should have are for example user forks and branches, fully versioned test schedules and configuration settings</p>
<a name="User-story"></a>
<h2 >User story<a href="#User-story" class="wiki-anchor">¶</a></h2>
<p>As a test case contributor during test case development I want to run tests on production instances with all necessary changes recorded in version control before merging to master so that my change will have minimal unexpected impact (test regressions) on existing tests</p>
<a name="Further-user-stories-from-httpsconfluencesusecompagesviewpageactionpageId365527173"></a>
<h2 >Further user stories (from <a href="https://confluence.suse.com/pages/viewpage.action?pageId=365527173" class="external">https://confluence.suse.com/pages/viewpage.action?pageId=365527173</a>)<a href="#Further-user-stories-from-httpsconfluencesusecompagesviewpageactionpageId365527173" class="wiki-anchor">¶</a></h2>
<ol>
<li>I want to start a job based on a modified test in production (In production tests can behave differently, for example because of the heavier load) -> see openqa-clone-job + CASEDIR</li>
<li>I want to edit needles and test if they work before proposing changes</li>
<li>I want to compare the results of a certain job group between two of my branches</li>
<li>I want to schedule a test 100 times without it showing up in the group overview -> see <a href="https://progress.opensuse.org/projects/openqatests/wiki#Statistical-investigation" class="external">statistical-investigation</a></li>
<li>I want to trigger multiple cloned jobs for each pull-request (Sometimes you want to trigger VR for different jobs against the same PR. it would be nice to do that in one command line)</li>
<li>I want to trigger the relevant tests automatically by creating a PR</li>
</ol>
<a name="Implications-and-suggestions"></a>
<h2 >Implications and suggestions<a href="#Implications-and-suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li><p>The usual test contributor workflows should be supported and made easier by making openQA fully aware of tests triggered for development purposes without negatively impacting existing validation tests</p>
<ul>
<li>Potential impact on asset management</li>
<li>No pollution of validation test reports by development tests</li>
</ul></li>
<li><p>If there are new/modified needles involved, the existing workflow cannot handle that. The current practice is:</p>
<ul>
<li>Test your changes (and possibly needle changes) locally and create PR(s)</li>
<li>Edit needles online and save them (then they will be committed to master). Requires admin rights</li>
</ul></li>
<li><p>DONE: Cloning cancelled or incomplete jobs currently does not work as openqa-clone-custom-git-refspec requires the vars.json file from a completed job with this file uploaded -> <a href="https://github.com/os-autoinst/openQA/pull/3170" class="external">https://github.com/os-autoinst/openQA/pull/3170</a></p></li>
<li><p>Replace "fetchneedles" by inherent git support</p></li>
<li><p>Provide support for github pull request validation</p></li>
<li><p>DONE: Extend openqa-clone-custom-git-refspec to accept list of source tests to clone -> <a href="https://github.com/os-autoinst/openQA/pull/2577" class="external">https://github.com/os-autoinst/openQA/pull/2577</a></p></li>
<li><p>DONE: openqa-clone-custom-git-refspec: Output in markdown format for easy copy/pasting into git commit messages and github PR comments -> <a href="https://github.com/os-autoinst/openQA/pull/2577" class="external">https://github.com/os-autoinst/openQA/pull/2577</a></p></li>
<li><p>openqa-clone-custom-git-refspec: Provide link to /tests/overview page for the custom build when multiple tests have been cloned</p></li>
<li><p>Make the trigger source of test jobs apparent, e.g. the source git repositories</p></li>
<li><p><a class="issue tracker-6 status-3 priority-4 priority-default closed parent" title="coordination: [EPIC] Interactive mode is an usability disaster (Resolved)" href="https://progress.opensuse.org/issues/14818#note-18">#14818#note-18</a> : "Tim got a ticket from Ray that the docker test failed and wants openQA to reproduce the issue and pause at the beginning of the docker test. Afterwards he wants openQA to make a disk snapshot and step through the test execution to find out where the problem is. After he found out, he reloads the snapshot to tweak the execution. During this process, openQA records his steps and allows to add needles."</p></li>
</ul>