action #111338
Updated by jbaier_cz over 2 years ago
## Motivation
In #110524 a proof-of-concept has shown that it's feasible to have helm charts for an openQA webui+worker kubernetes cluster. To have something supported and maintainable we should have helm charts within our openQA repo (or a related repo) with at least static helm chart tests
## Acceptance criteria
* **AC1:** Tested helm charts for openQA workers in a repo maintained by us
## Suggestions
* Read https://github.com/os-autoinst/openQA/pull/4650 , try it out, see what's missing
* Add "industry standard" helm chart static tests
* Include at least the parts covering openQA worker## Motivation
Based on good success we had lately to drive open sourcing other tooling like qem-dashboard and qem-bot and because we want to save internal ressources and because we love open source as a company and because we want to have tooling public for disaster recovery scenarios we should open source mtui as well
## Acceptance criteria
* **AC1:** A public open source project for mtui exists with free software license
## Suggestions
* okurz reviewed all source code of mtui and found nothing that looks like it needs to be kept private
* Ask current representatives of code owners what to look out for when open sourcing
* After that just go ahead and make https://gitlab.suse.de/qa-maintenance/mtui open source, e.g. next to https://github.com/openSUSE/qem-bot/
* Push the current source state as a new commit, do not import the complete git history (just in case we have something sensitive in the history). Optional: Review the complete git repo and mirror
* Adapt license, e.g. GPL or MIT
* Remove stuff from internal repo, only keep for deployment where necessary, same as we did for https://gitlab.suse.de/qa-maintenance/bot-ng and https://gitlab.suse.de/opensuse/qem-dashboard/ . As alternative archive the current repository and use new OBS approach for deploying