coordination #106546


[epic][tools] adoption

Added by jbaier_cz over 1 year ago. Updated 8 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.

Subtasks 3 (0 open3 closed)

action #106547: Setup database for dashboard.qam.suse.deResolvedjbaier_cz2022-02-10

action #106549: Deployment host for dashboard.qam.suse.deResolvedjbaier_cz2022-02-10

action #106552: Document deployment process for dashboard.qam.suse.deResolvedjbaier_cz2022-02-10


Related issues 1 (0 open1 closed)

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

Actions #1

Updated by jbaier_cz over 1 year ago

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

Updated by jbaier_cz over 1 year ago

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

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

Actions #4

Updated by okurz over 1 year ago

  • Target version set to future

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

Actions #5

Updated by jbaier_cz 8 months ago

  • Status changed from New to Resolved
  • Assignee set to jbaier_cz
  • Target version changed from future to Ready

We discussed this issue briefly inside the team and decided that we are happy with the current solution. It feels stable enough to call that a production deployment.


Also available in: Atom PDF