openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842021-06-18T10:48:35ZopenSUSE Project Management Tool
Redmine openQA Project - action #94255 (New): containers: Improve the speed of the container test in CIhttps://progress.opensuse.org/issues/942552021-06-18T10:48:35Zilausuchilausuch@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>The container testing has two main parts: build + run containers. <br>
The building process consume a lot of time and we saw recently several failures because of timeouts <a class="issue tracker-4 status-3 priority-5 priority-high3 closed behind-schedule" title="action: openqa-in-OpenQA fails in openqa-from-containers (Resolved)" href="https://progress.opensuse.org/issues/93713">#93713</a><br>
The building process takes a lot of time installing packages with zypper (we don't have metrics yet, but is human observation).</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC 1</strong>: Decrease the time to run the container tests</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<p>Because we want to focus on test openQA itself and not the packages we install in our system, I suggest to focus only on open QA testing, and don't care too much about the required packages.<br>
For that, I suggest split each container images in two parts (two different Dockerfiles). One Dockerfile will prepare the base system with the installation of all the packages. The other Docker file will run the openQA code for testing. <br>
The base image could be created during the test, but most interesting, I think is that, we can use a pre build image created by OBS (or other service) every day (or with the frequency we decided) and uploaded tom some registry</p>
openQA Project - action #94030 (Resolved): Cleanup logging in autoinst-log.txt for download assetshttps://progress.opensuse.org/issues/940302021-06-15T12:51:18Zilausuchilausuch@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>In the ticket <a class="issue tracker-4 status-3 priority-4 priority-default closed child" title="action: Cleanup logging in autoinst-log.txt (Resolved)" href="https://progress.opensuse.org/issues/91527">#91527</a> we listed other cases to cleanup. One of these is the information of the assets download, e.g.</p>
<pre><code>[2021-05-17T13:49:33.0579 CEST] [info] Download of Tumbleweed.x86_64-1.0-virtualbox-Snapshot20210516.vagrant.virtualbox.box processed:
[info] [#358]
Cache size of "/var/lib/openqa/cache" is 57GiB, with limit 180GiB
[info] [#358]
Downloading "Tumbleweed.x86_64-1.0-virtualbox-Snapshot20210516.vagrant.virtualbox.box" from "http://openqa1-opensuse/tests/1745884/asset/other/Tumbleweed.x86_64-1.0-virtualbox-Snapshot20210516.vagrant.virtualbox.box"
[info] [#358]
Content of "/var/lib/openqa/cache/openqa1-opensuse/Tumbleweed.x86_64-1.0-virtualbox-Snapshot20210516.vagrant.virtualbox.box" has not changed, updating last use
</code></pre>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC 1</strong> : indent with the same indentation criteria than in <a class="issue tracker-4 status-3 priority-4 priority-default closed child" title="action: Cleanup logging in autoinst-log.txt (Resolved)" href="https://progress.opensuse.org/issues/91527">#91527</a></li>
</ul>
<a name="Suggestion"></a>
<h2 >Suggestion<a href="#Suggestion" class="wiki-anchor">¶</a></h2>
<ul>
<li><a href="https://github.com/os-autoinst/os-autoinst/pull/1670" class="external">https://github.com/os-autoinst/os-autoinst/pull/1670</a></li>
<li>See: <a href="https://github.com/os-autoinst/os-autoinst/blob/09824a01348c41641d5cff8cd6d4192ad5ebd7a6/bmwqemu.pm#L199" class="external">https://github.com/os-autoinst/os-autoinst/blob/09824a01348c41641d5cff8cd6d4192ad5ebd7a6/bmwqemu.pm#L199</a></li>
</ul>
openQA Project - action #92893 (Resolved): containers, docker-compose: Ensure that the scheduler ...https://progress.opensuse.org/issues/928932021-05-20T10:34:39Zilausuchilausuch@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>Trying to complete the task <a class="issue tracker-4 status-12 priority-4 priority-default child" title="action: How to run an openQA test in 5 minutes size:M (Workable)" href="https://progress.opensuse.org/issues/76978">#76978</a> I found a problem in the webui container. It cannot connect to the scheduler and the jobs still unscheduled</p>
<pre><code class="text syntaxhl" data-language="text">scheduler_1 | -- Blocking request (http://127.0.0.1:9527/api/send_job)
scheduler_1 | -- Connect 41d600104970be636ece6296a21d1bdc (http://127.0.0.1:9527)
</code></pre>
<p>It could be easily fixed adding OPENQA_WEB_SOCKETS_HOST: "websockets" to the scheduler declaration</p>
<p>But then an other problems happens:</p>
<pre><code class="text syntaxhl" data-language="text">scheduler_1 | -- Client <<< Server (http://websockets:9527/api/send_job)
scheduler_1 | HTTP/1.1 403 Forbidden\x0d
scheduler_1 | Content-Length: 26\x0d
scheduler_1 | Server: Mojolicious (Perl)\x0d
scheduler_1 | Date: Thu, 20 May 2021 10:24:45 GMT\x0d
scheduler_1 | Content-Type: application/json;charset=UTF-8\x0d
scheduler_1 | \x0d
scheduler_1 | {"error":"Not authorized"}
</code></pre>
<p>This happens when we launch a web UI openQA using the docker-compose, and try to run a job (using clone_job)</p>
<a name="Acceptance-Criteria"></a>
<h2 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC 1</strong>: scheduler can connect to websockets without problems</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Investigate the auth method to these services. Maybe the auth method is only localhost</li>
<li>Check that the client.ini has the correct credentials</li>
</ul>
<a name="References"></a>
<h2 >References<a href="#References" class="wiki-anchor">¶</a></h2>
<p>See the comments at <a class="issue tracker-4 status-3 priority-4 priority-default closed behind-schedule" title="action: containers: Web UI cannot connect to scheduler (Resolved)" href="https://progress.opensuse.org/issues/92833#note-6">#92833#note-6</a></p>
openQA Project - action #91818 (New): containers: Add logs when docker-compose up fails in the CIhttps://progress.opensuse.org/issues/918182021-04-27T09:40:06Zilausuchilausuch@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>We don't have information when docker-compose up -d fails in the CI test for containers.</p>
<a name="Acceptance-Criteria"></a>
<h2 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC 1</strong>: CI shows logs when docker-compose up fails</li>
</ul>
openQA Project - action #91815 (New): containers: Expand the docker-compose CI test to check heal...https://progress.opensuse.org/issues/918152021-04-27T09:35:26Zilausuchilausuch@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>PO suggested to split <a class="issue tracker-4 status-3 priority-4 priority-default closed child" title="action: containers: The deploy using docker-compose is not stable and eventually fails (Resolved)" href="https://progress.opensuse.org/issues/89731">#89731</a> and move the AC2 to a new ticket. Currently CI is not checking that all the containers are healthy</p>
<a name="Acceptance-Criteria"></a>
<h2 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC 1</strong>: Expand the docker-compose CI test to include this case</li>
</ul>
<a name="Suggestion"></a>
<h2 >Suggestion<a href="#Suggestion" class="wiki-anchor">¶</a></h2>
<p>A PR is started as a proposal for <a href="https://progress.opensuse.org/issues/89731#note-28" class="external">https://progress.opensuse.org/issues/89731#note-28</a><br>
<a href="https://github.com/os-autoinst/openQA/pull/3864" class="external">https://github.com/os-autoinst/openQA/pull/3864</a></p>
openQA Project - action #91584 (New): containers: ensure the failure of the web UI container when...https://progress.opensuse.org/issues/915842021-04-22T10:36:05Zilausuchilausuch@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>We can see in this log <a href="https://openqa.opensuse.org/tests/1708952#step/single_container_webui/107" class="external">https://openqa.opensuse.org/tests/1708952#step/single_container_webui/107</a> how in spite Apache fails the container continues working.<br>
In this test the certificates were removed, and the error was expected running the single container web UI (non docker-compose)</p>
<pre><code>validate_script_output got:
AH00526: Syntax error on line 18 of /etc/apache2/vhosts.d/openqa-ssl.conf:
SSLCertificateFile: file '/etc/apache2/ssl.crt/server.crt' does not exist or is empty
</code></pre>
<p>This could be a problem in a production environment because without Apache the API doesn't work.</p>
<a name="Acceptance-Criteria"></a>
<h2 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC 1</strong>: Container exits when Apache fails</li>
<li><strong>AC 2</strong>: Container exits when any of the critical processes fails.</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<p>In the daily meeting when this was exposed we suggested to create a simple health-check using pgrep to check that Apache is working all the time. This health-check will be included in the container and will be a complement to external health-checks.</p>
openQA Project - action #91046 (Resolved): CI: "webui-docker-compose" seems that eventually fails...https://progress.opensuse.org/issues/910462021-04-13T09:08:23Zilausuchilausuch@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>In <a class="issue tracker-4 status-3 priority-4 priority-default closed child" title="action: containers: The deploy using docker-compose is not stable and eventually fails (Resolved)" href="https://progress.opensuse.org/issues/89731">#89731</a> we introduced a initial webui container in charge of initializing the database. We have a test where the health check failed<br>
<a href="https://github.com/os-autoinst/openQA/pull/3838/checks?check_run_id=2329551052" class="external">https://github.com/os-autoinst/openQA/pull/3838/checks?check_run_id=2329551052</a></p>
<p>The problem is that the docker-compose exit with an error because the health check of the webuid_db_init container failed</p>
<pre><code class="text syntaxhl" data-language="text"> Name Command State Ports
------------------------------------------------------------------------------------------------------------------------------------------------
webui_db_1 docker-entrypoint.sh postgres Up (healthy) 5432/tcp
webui_webui_db_init_1 sh -c chmod -R a+rwX /data ... Up (unhealthy) 443/tcp, 80/tcp, 0.0.0.0:49153->9526/tcp, 9527/tcp, 9528/tcp, 9529/tcp
make: *** [Makefile:306: test-containers-compose] Error 1
</code></pre>
<p>The healthcheck is this one <br>
<a href="https://github.com/os-autoinst/openQA/blob/abd9a2297430377cd9876c3cbcec8b2cb4302722/container/webui/docker-compose.yaml#L116" class="external">https://github.com/os-autoinst/openQA/blob/abd9a2297430377cd9876c3cbcec8b2cb4302722/container/webui/docker-compose.yaml#L116</a></p>
<p>Take in consideration the DB error lines</p>
<pre><code class="text syntaxhl" data-language="text">db_1 | 2021-04-13 02:43:08.038 UTC [98] ERROR: relation "api_keys" does not exist at character 15
db_1 | 2021-04-13 02:43:08.038 UTC [98] STATEMENT: select * from api_keys;
db_1 | 2021-04-13 02:43:10.441 UTC [100] ERROR: relation "dbix_class_deploymenthandler_versions" does not exist at character 24
db_1 | 2021-04-13 02:43:10.441 UTC [100] STATEMENT: SELECT me.version FROM dbix_class_deploymenthandler_versions me ORDER BY id DESC LIMIT $1
db_1 | 2021-04-13 02:43:10.446 UTC [100] ERROR: relation "dbix_class_deploymenthandler_versions" does not exist at character 24
</code></pre>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC 1</strong>: Determine the cause of the failure</li>
<li><strong>AC 2</strong>: Fix the problem</li>
</ul>
openQA Project - action #90989 (Workable): containers: Configurable workdir location in docker-co...https://progress.opensuse.org/issues/909892021-04-12T09:55:25Zilausuchilausuch@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>Currently, the workdir is created in the <code>containers/webui</code> directory with two problems:</p>
<ul>
<li>This clutters the git directory. (The path is already in <code>.gitignore</code>, though.)</li>
<li>The directory is owned by root causing the tidy script to fail on permission errors.</li>
</ul>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1</strong>: Use a different default directory or at least prevent the interference with the tidy script.</li>
<li><strong>AC2</strong>: Allow to configure the workdir path, e.g. via an environment variable.</li>
<li><strong>AC3</strong>: Document where files are stored by default and AC2.</li>
</ul>
openQA Project - action #90767 (Resolved): containers: Fix github test "webui-docker-compose" tim...https://progress.opensuse.org/issues/907672021-04-07T10:21:10Zilausuchilausuch@suse.com
<a name="Problem"></a>
<h2 >Problem<a href="#Problem" class="wiki-anchor">¶</a></h2>
<p>The test webui-docker-compose exceeds 30 minutes and is cancelled with the message <br>
"The job running on runner Hosted Agent has exceeded the maximum execution time of 30 minutes."</p>
<a name="Acceptance-Criteria"></a>
<h2 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC 1</strong>: The test is executed without being cancelled</li>
</ul>
<a name="Resources"></a>
<h2 >Resources<a href="#Resources" class="wiki-anchor">¶</a></h2>
<p>Example of crenellation: <a href="https://github.com/os-autoinst/openQA/actions/runs/725105078" class="external">https://github.com/os-autoinst/openQA/actions/runs/725105078</a></p>
openQA Project - action #89929 (New): containers: Fix nginx configuration to independence the WS ...https://progress.opensuse.org/issues/899292021-03-11T12:17:32Zilausuchilausuch@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>Now the configuration of nginx uses the following urls as backend for websockets and livehandler</p>
<ul>
<li><a href="http://webui_websockets_1:9527" class="external">http://webui_websockets_1:9527</a>;</li>
<li><a href="http://webui_livehandler_1:9528" class="external">http://webui_livehandler_1:9528</a>;</li>
</ul>
<p>The problem is that this name (webui_...) is dependent on the parent directory of the docker-compose</p>
<a name="Acceptance-Criteria"></a>
<h2 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC 1</strong>: Modify the configuration file to separate the name of the urls from the parent directory of the docker-compose</li>
</ul>
<a name="Suggestion"></a>
<h2 >Suggestion<a href="#Suggestion" class="wiki-anchor">¶</a></h2>
<p>Can be replaced by </p>
<ul>
<li><a href="http://websockets:9527/" class="external">http://websockets:9527/</a></li>
<li><a href="http://livehandler_1:9528/" class="external">http://livehandler_1:9528/</a></li>
</ul>
<p>See <a href="https://github.com/os-autoinst/openQA/pull/3755" class="external">https://github.com/os-autoinst/openQA/pull/3755</a></p>
openQA Project - action #89755 (Resolved): container: Fix missing shared directories and its perm...https://progress.opensuse.org/issues/897552021-03-09T16:19:23Zilausuchilausuch@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>Some directories are missing generating errors like this</p>
<pre><code>gru_1 | Can not create MOJO_TMPDIR : mkdir /var/lib/openqa/share/factory/tmp: Permission denied at /usr/share/openqa/script/../lib/OpenQA/Setup.pm line 306.
</code></pre>
<p>The directories has to be:</p>
<p>/data/factory/iso:rw<br>
/data/factory/hdd:rw<br>
/data/factory/other:rw<br>
/data/factory/tmp:rw<br>
/data/testresults:rw<br>
/data/tests:ro<br>
/data/conf:ro</p>
<p>Also the <code>factory</code> and <code>testresults</code> directories have to be writable by <code>geekotest</code> user in the container</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC 1</strong>: Ensure factory/testresults directories are created</li>
<li><strong>AC 2</strong>: Ensure container user has permissions for these directories</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Does the user in the container have the right permissions?</li>
<li>Does os-autoinst/openQA/... create all folders on demand?</li>
<li>See <a href="https://github.com/os-autoinst/openQA/pull/3755" class="external">https://github.com/os-autoinst/openQA/pull/3755</a></li>
</ul>
openQA Project - action #89752 (Resolved): containers: Add a worker service as part of the docker...https://progress.opensuse.org/issues/897522021-03-09T16:05:55Zilausuchilausuch@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>To have a complete openQA deployment using the docker-compose at least one worker should be created</p>
<a name="Acceptance-Criteria"></a>
<h2 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC 1</strong>: Worker service is part of the compose workflow</li>
<li><strong>AC 2</strong>: The number of workers is configurable.</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>See: <a href="https://github.com/os-autoinst/openQA/pull/3755" class="external">https://github.com/os-autoinst/openQA/pull/3755</a></li>
<li>Add a section for the worker service to <code>container/webui/docker-compose.yaml</code></li>
<li>Add a variable like <code>$WORKER_COUNT</code></li>
<li>Add a corresponding healthcheck</li>
</ul>
openQA Project - action #89749 (New): containers: Allow to the user to choose the source of image...https://progress.opensuse.org/issues/897492021-03-09T15:55:59Zilausuchilausuch@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>Now only the local build images can be used on the docker-compose. As a user would be nice to give me the option to choose without changing the docker-compose yaml</p>
<a name="Acceptance-Criteria"></a>
<h2 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h2>
<p><strong>AC 1</strong>: The user can choose the images<br>
<strong>AC 2</strong>: Create a test to check that local build images and remote images can be used</p>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Use docker-compose variables e.g. image: ${OPENQA_WEBUI_IMAGE}</li>
<li>Add the default values to .env file</li>
<li>See <a href="https://github.com/os-autoinst/openQA/pull/3755" class="external">https://github.com/os-autoinst/openQA/pull/3755</a></li>
</ul>
openQA Project - action #88315 (New): Complete the worker container test obtaining the key/secret...https://progress.opensuse.org/issues/883152021-01-28T15:32:32Zilausuchilausuch@suse.com
<a name="Problem"></a>
<h1 >Problem<a href="#Problem" class="wiki-anchor">¶</a></h1>
<p>The ticket <a href="https://progress.opensuse.org/issues/80682" class="external">https://progress.opensuse.org/issues/80682</a> test that the worker container starts and try to connect to the web UI. But this connection cannot be completed because there are not existing credentials by default.</p>
<a name="Acceptance-Criteria"></a>
<h1 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h1>
<ul>
<li>AC1: Create a pair of credentials</li>
<li>AC2: Set the client.conf with the new credentials and check that the worker connects to the web UI without problems.</li>
</ul>
openQA Project - coordination #81060 (Blocked): [epic] openQA web UI in kuberneteshttps://progress.opensuse.org/issues/810602020-12-15T06:09:11Zilausuchilausuch@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>Helm charts allows you to automate the deployment of a complex set of items in a kubernetes environment. These elements are not only limited to pods (containers) but also to configurations (configmaps and secrets), and all the resources they need in the correct order and with the proper checks.</p>
<p>Thanks to the work done in <a class="issue tracker-6 status-15 priority-4 priority-default parent" title="coordination: [saga][epic] Scale out: Redundant/load-balancing deployments of openQA, easy containers, containe... (Blocked)" href="https://progress.opensuse.org/issues/80142">#80142</a> we saw how to divide the web UI into parts, which were could be converted into HA and which had to remain standalone. In addition to how we should configure the load balancer to integrate each of the different services that make up the complete web UI.</p>
<p>This ticket proposes to create a helm chart capable of generating a complete and functional deployment of the web UI based on the following prerequisites:</p>
<ul>
<li>There is a pre-existing installation of kubernetes</li>
</ul>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> The complete web UI HA is installed with the DB with the default options</li>
<li><strong>AC2:</strong> The web UI is accessible from outside of the cluster</li>
<li><strong>AC3:</strong> The helm chart is configurable with: Typical and basic parameters and, number of replicas for HA, type of persistence for DB, ...</li>
<li><strong>AC4:</strong> Documentation is completed with instructions of use</li>
<li><strong>AC5:</strong> Deployed together with rancher</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Highly recommended based on work already done in <a class="issue tracker-6 status-15 priority-4 priority-default parent" title="coordination: [saga][epic] Scale out: Redundant/load-balancing deployments of openQA, easy containers, containe... (Blocked)" href="https://progress.opensuse.org/issues/80142">#80142</a>, e.g. the existing docker-compose setup</li>
<li><del>Proof-of-concept of either openQA webUI <em>or</em> worker within kubernetes, e.g. using k3s or try rancher directly</del> done for both webUI and worker in <a class="issue tracker-4 status-3 priority-4 priority-default closed child" title="action: [timeboxed:20h][spike] openQA proof-of-concept within kubernetes size:M (Resolved)" href="https://progress.opensuse.org/issues/110524">#110524</a></li>
<li>Use local kubernetes deployments to development purposes (this avoid the infra needs). For instance: minikube, k3s,... </li>
<li>Figure out if is necessary to publish the helm chart and where: <a href="https://helm.sh/docs/howto/chart_releaser_action/">https://helm.sh/docs/howto/chart_releaser_action/</a></li>
<li>Combine with rancher</li>
<li>Ensure proper testing of the charts
<ul>
<li>Create kubernetes cluster inside docker inside GitHub Actions: <a href="https://github.com/marketplace/actions/kind-cluster">https://github.com/marketplace/actions/kind-cluster</a></li>
<li>Look at chart-testing tool: <a href="https://github.com/marketplace/actions/helm-chart-testing">https://github.com/marketplace/actions/helm-chart-testing</a></li>
<li>Try to deploy the chart inside CI</li>
</ul></li>
<li>Add definitions for init containers to allow fetching tests/needles from git repository during installation</li>
<li>As an alternative to git, provide a persistent volume claim template for shared volume (ReadMany) -- think about Longhorn</li>
<li>Add definition for rsyncd container to allow usage of cache service in the worker pod to synchronize data between webui and worker pods</li>
<li>Enhance customization options of the current chart, add common options (like annotations, pod security, replicas count, ...) which are provided by the blank helm templates (reuse initial templates created by <code>helm create</code>)</li>
</ul>