action #111338
Updated by tinita almost 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 history) * 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 necessary