coordination #106546

[epic][tools] adoption

Added by jbaier_cz 5 months ago. Updated 5 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
(Total: 0.00 h)


Others became reliant on qem-dashboard+qem-bot which is effectively making qem-dashboard+qem-bot a critical component even though we may not like that.

We should make same improvements to better handle this component.


action #106547: Setup database for dashboard.qam.suse.deNew

action #106549: Deployment host for dashboard.qam.suse.deNew

action #106552: Document deployment process for dashboard.qam.suse.deNew

Related issues

Related to QA - action #106179: No aggregate maintenance runs scheduled today on osd - down size:SResolved2022-02-08


#1 Updated by jbaier_cz 5 months ago

  • Subject changed from [epic] adoption to [epic][tools] adoption
  • Target version deleted (future)

#2 Updated by jbaier_cz 5 months ago

  • Related to action #106179: No aggregate maintenance runs scheduled today on osd - down size:S added

#3 Updated by jbaier_cz 5 months ago

okurz wrote:

can you just share for our readers a little bit more how the current setup looks like please :)

The dashboard is a "classical web application" so (apart from job-oriented bot-ng) it requires a place where it can run continuously. It also requires a database for some transient data and (optionally) a HTTP proxy to handle extra stuff like HTTPS termination (although that can be managed by the application itself). As there already were some QAM-related stuff running on the, it was a clear choice at that time. To lower the complexity for future server upgrades, most of the services there were deployed in independent containers with only host network in between (the connection outside was NAT-ed by the host).

The bot-ng was moved (as result of #96998) into a Gitlab pipeline as it does not require to run all the time (it was basically a cron job in the old setup). It does need to communicate with the dashboard API to be able to work.

The current deployment (after we moved the code to the GitHub) still runs from the GitLab pipeline. We have a scheduled job there which just invokes another pipeline from qa-maintenance/qamops repository. There is a parameter PLAYBOOK which contains path to an Ansible playbook with the deployment tasks. The Ansible connects to the, ensures user/group presence, required directory structure, creates systemd service files and check outs the code from the git repository. If there were any changes it will also restart the service. It is entirely possible to also include database configuration and secrets (secrets are encrypted by ansible-vault, the password to decrypt is known by the pipeline)

#4 Updated by okurz 5 months ago

  • Target version set to future

Thanks a lot. This information is very good and helpful. Not something to be done immediately though.

Also available in: Atom PDF