Proper maintainership for openqa_service VM size:M
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
- 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
- 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
Apparently the machine is not reachable over IPv6 but a AAAA record exists.
ssh -4 firstname.lastname@example.org 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.
- Target version changed from Ready to future
- Parent task deleted (
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.
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.
What is actually done on that machine:
openqa_bugfetcher is installed from
openQA api keys are configured via
Bugzilla, jira, github and progress credentials are set via
Cronjobs are set up via
*/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