action #120279: Proper maintainership for openqa_service VM size:M - openQA Infrastructure (public) - openSUSE Project Management Tool

Actions

Copy link

action #120279

open

Proper maintainership for openqa_service VM size:M

Added by okurz about 2 years ago. Updated almost 2 years ago.

Status:

Workable

Priority:

Normal

Assignee:

Category:

Target version:

QA (public) - future

Start date:

2022-11-10

Due date:

% Done:

Estimated time:

Tags:

infra

Description

Motivation¶

The VM openqa_service runs the openqa_bugfetcher.

We need to talk about maintainership of the openqa_service VM, e.g. updates, upgrades, backup, config management, monitoring, etc.

Possibly we can just add the VM to salt as we do for other QE machines already, see parent

Acceptance criteria¶

AC1: We know who maintains the machine
AC2: The machine is updated+upgraded
AC3: There exists backup and/or config management
AC4: The machine is properly monitored

Suggestions¶

Clarify with Eng-Infra about maintainership of the machine including updates, upgrades, backup, config management, monitoring, etc.
Ask someone with access to the system to provide access, e.g. dheidler should add ssh keys from openqa-salt-pillars for SUSE QE Tools members
Check the state of the system, e.g. OS level, etc.
If we need to maintain it maybe it's easier to just transform into a CI pipeline, e.g. on gitlab.suse.de, and then decommission the VM

Related issues 2 (0 open — 2 closed)

Actions

Copy link

Updated by okurz about 2 years ago

Copied from action #120276: Prepare openqa_bugfetcher for upcoming bugzilla update added

Actions

Copy link

Updated by okurz about 2 years ago

Description updated (diff)
Parent task set to #118636

Actions

Copy link

Updated by okurz about 2 years ago

Apparently the machine is not reachable over IPv6 but a AAAA record exists. ssh -4 root@openqa-service.suse.de establishes a connection but I can't login with usual passwords.

@dheidler if you have access you could add the ssh keys from our team from https://gitlab.suse.de/openqa/salt-pillars-openqa/-/blob/master/sshd/users.sls

The machine seems to be salt controlled by Eng-Infra so the question is about who conducts upgrades, how is monitoring done, etc.

Actions

Copy link

Updated by livdywan about 2 years ago

Subject changed from Proper maintainership for openqa_service VM to Proper maintainership for openqa_service VM size:M
Description updated (diff)
Status changed from New to Workable

Actions

Copy link

Updated by okurz about 2 years ago

Target version changed from Ready to future
Parent task deleted (~~#118636~~)

Let me reconsider based on the "hope" that SUSE-IT sufficiently maintains this machine. We still have #120276 to make sure the main service for the openQA bug fetching still works compatible with a new bugzilla version.

Actions

Copy link

Updated by dheidler about 2 years ago

Documented ssh access via https://gitlab.suse.de/openqa/password/

Actions

Copy link

Updated by dheidler about 2 years ago

I asked Bernhard Wiedemann for clarification:

Die VM laeuft auf unserem morla cluster mit libvirt/KVM.
Solange die an unserem salt master haengt, taucht die auch bei unseren woechentlichen Updates im Infra Team mit auf, dann kuemmern wir uns um die Updates.
Weiss nicht, ob man 2 verschiedene salt master haben kann.
Zumindest mit salt-ssh solltet ihr die zusaetzlich managen koennen.

Actions

Copy link

Updated by dheidler about 2 years ago

What is actually done on that machine:

openqa_bugfetcher is installed from devel:openQA repo.

openQA api keys are configured via /etc/openqa/client.conf.

Bugzilla, jira, github and progress credentials are set via /etc/openqa/bugfetcher.conf and /etc/openqa/bugfetcher_o3.conf.

Cronjobs are set up via /etc/crontab:

*/10     *       *       *       *       root  (date;fetch_openqa_bugs) > /tmp/fetch_openqa_bugs_osd.log
1        */10    *       *       *       root  (date;fetch_openqa_bugs /etc/openqa/bugfetcher_o3.conf) > /tmp/fetch_openqa_bugs_o3.log

Actions

Copy link

#10