QA

Regarding "openqa-ses" chat was in https://suse.slack.com/archives/C02CANHLANP/p1667993899105129:

(Oliver Kurz) ok. I wrote to qa-team@suse.de. If I receive no response then I think this is a topic for QE mgmt, shouldn't happen that we have machines which nobody wants to know about :slightly_smiling_face:
(Matthias Griessmeier) I agree. Ses is storage, I don't know/remember why it has osd-admins as contact. Probably because openqa is in the name. I'd say if the machine is not pingable, nor reachable over ipmi and no one responses, let's unmount it and move it to cold storage. This seems to be historical leftover. […] Gerhard is aware and next time he is in srv1. He will disconnect it. I cannot even find it in https://gitlab.suse.de/OPS-Service/salt/-/blob/production/pillar/domain/suse_de.sls
that's probably the reason why dns does not resolve - so I think it is safe to remove it. to make it official, created https://sd.suse.com/servicedesk/customer/portal/1/SD-103880

Also I asked Lazaros Haleplidis in https://suse.slack.com/archives/C0488BZNA5S/p1668081298115499:

(Lazaros Haleplidis) also I have a question about machines like openqa-ses.suse.de https://racktables.nue.suse.com/index.php?page=object&object_id=13558 . nobody seems to know the machine and it's not reachable. But racktable lists switch port connections so by powering off/on machines or disconnecting/connecting the switch ports you and others from EngInfra could identify the MAC addresses and just go ahead with the migration and nobody from our side can contribute more.

No response in Slack. I asked mgriessmeier to share access to https://sd.suse.com/servicedesk/customer/portal/1/SD-103880 . The machine is still in racktables untouched.

OSD-Admins is now participant on https://sd.suse.com/servicedesk/customer/portal/1/SD-103880, we can track this

SD ticket was resolved with: "Has been unmounted and placed in the cold storage." racktables wasn't updated yet. Need to check with mgriessmeier if he created a new cold storage entry at FC location

blocked by #121282. After that we need to ensure that we actually have the system migrated to the new network security zone(s)

With #121282 resolved we can now unblock and continue here.

We can declare that as blocked by https://sd.suse.com/servicedesk/customer/portal/1/SD-109299

The migration is supposedly concluded. I cannot login on qe-jumpy.suse.de to verify it at the moment, though. hostname --fqdn only returns hostname: Name or service not known on storage.qa.suse.de.

The VPN is online again. However, it doesn't look like the host has actually been migrated. So I've left a comment on https://sd.suse.com/servicedesk/customer/portal/1/SD-109299. (It is not possible to re-open the ticket. I've mentioned it in the chat to get some attention.)

mkittler to check latest changes after mcaj mentioned

the DNS change for the device storage.qa.suse.de - https://racktables.nue.suse.com/index.php?page=object&tab=default&object_id=13558
is here: https://gitlab.suse.de/OPS-Service/salt/-/merge_requests/3232/

already merged. Maybe we need to reboot or check the host's status.

Still blocked by https://sd.suse.com/servicedesk/customer/portal/1/SD-109299.

The host has been migrated and I've updated racktables. Now I only need to check our salt/alerting (as currently the host-up alert for the old domain is firing).

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

I've also edited the other alerts manually (actually just the ping alert used the full domain name and had to be changed). So this should cover everything.

I'm seeing alerts because salt-states-openqa is failing like so, hence re-opening:

         ID: /root/.ssh/id_ed25519.backup_osd
   Function: file.managed
     Result: False
    Comment: Pillar id_ed25519.backup_osd does not exist
    Started: 13:25:13.881664
   Duration: 2.935 ms
    Changes:  

And this looks to be the fix for it: https://gitlab.suse.de/openqa/salt-pillars-openqa/-/merge_requests/498

Yes, and the pipeline has already passed.