Project

General

Profile

action #111338

Updated by tinita over 1 year 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

Back