coordination #81060
open
coordination #80142: [saga][epic] Scale out: Redundant/load-balancing deployments of openQA, easy containers, containers on kubernetes
[epic] openQA web UI in kubernetes
Added by ilausuch almost 4 years ago.
Updated over 2 years ago.
Category:
Feature requests
Estimated time:
(Total: 0.00 h)
Description
Motivation¶
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.
Thanks to the work done in #80142 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.
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:
- There is a pre-existing installation of kubernetes
Acceptance criteria¶
- AC1: The complete web UI HA is installed with the DB with the default options
- AC2: The web UI is accessible from outside of the cluster
- AC3: The helm chart is configurable with: Typical and basic parameters and, number of replicas for HA, type of persistence for DB, ...
- AC4: Documentation is completed with instructions of use
- AC5: Deployed together with rancher
Suggestions¶
- Highly recommended based on work already done in #80142, e.g. the existing docker-compose setup
Proof-of-concept of either openQA webUI or worker within kubernetes, e.g. using k3s or try rancher directly done for both webUI and worker in #110524
- Use local kubernetes deployments to development purposes (this avoid the infra needs). For instance: minikube, k3s,...
- Figure out if is necessary to publish the helm chart and where: https://helm.sh/docs/howto/chart_releaser_action/
- Combine with rancher
- Ensure proper testing of the charts
- Add definitions for init containers to allow fetching tests/needles from git repository during installation
- As an alternative to git, provide a persistent volume claim template for shared volume (ReadMany) -- think about Longhorn
- Add definition for rsyncd container to allow usage of cache service in the worker pod to synchronize data between webui and worker pods
- 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
helm create
)
- Category set to Feature requests
- Status changed from New to Workable
- Target version set to future
This looks great, thx. Let's see when we have capacity to work on this
- Related to action #88187: Set the addresses in the "internal clients" configurable added
- Related to deleted (action #88187: Set the addresses in the "internal clients" configurable)
- Blocked by action #88187: Set the addresses in the "internal clients" configurable added
- Target version changed from future to Ready
Zoltan has mentioned this specific ticket to me. I think we can bring it back on our backlog again as a next task to followup with.
- Status changed from Workable to In Progress
- Assignee set to ilausuch
- Due date set to 2021-03-09
Setting due date based on mean cycle time of SUSE QE Tools
- Status changed from In Progress to Blocked
Bloqued until the problems with #76978 is solved
For validation the helm chart we could use
helm lint ./chart
But also there is an other interesting tool kubeval
helm template ./chart | kubeval --strict
This allows testing with the default helm chart values, but also set different values and test the helm chart with these. This is important in case we have different branches of execution based on conditions
helm template --set area.key="val" | kubeval --strict
Or more complex, creating a VALUES.yaml file with the new values
area:
key: "val"
And use to check it
echo "$VALUES" | helm template -f - | kubeval --strict
- Due date deleted (
2021-03-09)
removing due date as the ticket is blocked. No need for a reminder.
- Blocks action #90344: kubevirt backend for openQA and/or os-autoinst added
Take in consideration the detected problem and the solutions in https://github.com/os-autoinst/openQA/pull/3821
In a helm chart should be an initial stage (a web UI pod) to create the initial DB (if is not created). This pod can be destroyed after done its job
- Related to action #76978: How to run an openQA test in 5 minutes size:M added
- Blocks deleted (action #90344: kubevirt backend for openQA and/or os-autoinst)
- Blocked by action #90344: kubevirt backend for openQA and/or os-autoinst added
- Blocked by deleted (action #90344: kubevirt backend for openQA and/or os-autoinst)
- Assignee deleted (
ilausuch)
- Status changed from Blocked to Workable
- Assignee deleted (
okurz)
Considering #88187 was resolved I assume this is no longer blocked.
- Blocked by deleted (action #88187: Set the addresses in the "internal clients" configurable)
- Status changed from Workable to New
- Tracker changed from action to coordination
- Subject changed from Create a helm chart to deploy web UI in kubernetes to [epic] openQA web UI in kubernetes
- Description updated (diff)
- Status changed from New to Blocked
- Assignee set to okurz
- Description updated (diff)
I added some more suggestions (as a result of working on #110524). Also, I think we do not need to limit ourselves to just the web UI, workers (at least qemu_x86_64) can run in the kubernetes as well.
- Target version changed from Ready to future
Also available in: Atom
PDF