Project

General

Profile

action #81060

coordination #80142: [saga][epic] Scale out: Redundant/load-balancing deployments of openQA, easy containers, containers on kubernetes

Create a helm chart to deploy web UI in kubernetes

Added by ilausuch 10 months ago. Updated about 2 months ago.

Status:
Blocked
Priority:
Normal
Assignee:
Category:
Feature requests
Target version:
Start date:
2020-12-14
Due date:
% Done:

0%

Estimated time:
Difficulty:

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.

Suggestions

  • Highly recommended based on work done in # 80142
  • 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

Related issues

Related to openQA Project - action #76978: How to run an openQA test in 5 minutesNew2020-11-04

Blocked by openQA Project - action #88187: Set the addresses in the "internal clients" configurableResolved2021-01-25

History

#1 Updated by cdywan 10 months ago

  • Category set to Feature requests
  • Status changed from New to Workable

#2 Updated by okurz 10 months ago

  • Target version set to future

This looks great, thx. Let's see when we have capacity to work on this

#3 Updated by ilausuch 9 months ago

  • Related to action #88187: Set the addresses in the "internal clients" configurable added

#4 Updated by cdywan 9 months ago

  • Related to deleted (action #88187: Set the addresses in the "internal clients" configurable)

#5 Updated by cdywan 9 months ago

  • Blocked by action #88187: Set the addresses in the "internal clients" configurable added

#6 Updated by okurz 8 months ago

  • 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.

#7 Updated by okurz 8 months ago

#88187 merged, unblocked

#8 Updated by ilausuch 8 months ago

  • Status changed from Workable to In Progress
  • Assignee set to ilausuch

#9 Updated by openqa_review 8 months ago

  • Due date set to 2021-03-09

Setting due date based on mean cycle time of SUSE QE Tools

#10 Updated by ilausuch 8 months ago

  • Status changed from In Progress to Blocked

Bloqued until the problems with #76978 is solved

#11 Updated by ilausuch 8 months ago

For validation the helm chart we could use

helm lint ./chart

But also there is an other interesting tool kubebal

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

#12 Updated by okurz 7 months ago

  • Due date deleted (2021-03-09)

removing due date as the ticket is blocked. No need for a reminder.

#13 Updated by cdywan 7 months ago

  • Blocks action #90344: kubevirt backend for openQA and/or os-autoinst added

#14 Updated by ilausuch 6 months ago

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

#15 Updated by okurz 4 months ago

  • Related to action #76978: How to run an openQA test in 5 minutes added

#16 Updated by cdywan 4 months ago

  • Blocks deleted (action #90344: kubevirt backend for openQA and/or os-autoinst)

#17 Updated by cdywan 4 months ago

  • Blocked by action #90344: kubevirt backend for openQA and/or os-autoinst added

#18 Updated by okurz 4 months ago

  • Blocked by deleted (action #90344: kubevirt backend for openQA and/or os-autoinst)

#19 Updated by ilausuch about 2 months ago

  • Assignee deleted (ilausuch)

#20 Updated by okurz about 2 months ago

  • Assignee set to okurz

Also available in: Atom PDF