action #138275
opencoordination #168895: [saga][epic][infra] Support SUSE PRG office move while ensuring business continuity
Ensure that there is proper ownership and maintainership for qanet.qa.suse.cz
0%
Description
Motivation¶
In https://suse.slack.com/archives/C02CANHLANP/p1697546053983439 we found problems stemming from space depletion and stale NFS mounts on qanet.qa.suse.cz . jbaier has access (root to be confirmed) and could help with cleanup a little bit. We need to ensure that this machine has a proper ownership and maintainership for qanet.qa.suse.cz, e.g. if Eng-Infra owns it and forgot about it or if LSG QE UV owns it and forgot about it or if QE Tools team needs to take over ownership and maintainership
Acceptance criteria¶
- AC1: https://racktables.nue.suse.com/index.php?page=object&tab=default&object_id=4860 has a proper description about what this machine is used for, who owns and maintains it
- AC2: It is ensured that qanet.qa.suse.cz is properly maintained, up-to-date, monitored
Suggestions¶
- Clarify within LSG QE and with Eng-Infra who is actually expected to maintain, who has access currently, who would be willing to maintain
- Make sure that the owner properly maintains the machine
- If we end up as owners then get ssh root access, ensure the OS is an up-to-date current system as we usually maintain, add to salt, ensure system is monitored, etc.
- Ensure https://racktables.nue.suse.com/index.php?page=object&tab=default&object_id=4860 is up-to-date
Updated by okurz about 1 year ago · Edited
https://gitlab.suse.de/OPS-Service/salt/-/merge_requests/4416 related to add SSH keys for qanet.qa.suse.cz (merged)
Updated by okurz about 1 year ago
- Status changed from New to Blocked
- Assignee set to okurz
Updated by okurz 8 months ago
https://sd.suse.com/servicedesk/customer/portal/1/SD-142028 was "resolved" but not entirely convincing. AC1 would be covered but as long as OPS-Service/salt is applied - which we still want - then we can"t apply our own salt states and hence not ensure an up-to-date system state nor monitor it. We can also block on #756789 which is blocked on https://jira.suse.com/browse/ENGINFRA-3732
Updated by okurz 4 months ago
Meanwhile we have root ssh access. I don't know when this was done. I see that there is a salt minion running but there is no valid /etc/salt/minion. Maybe someone from IT removed the connection or it's configured elsewhere. I assume that IT still controls DHCP config and more over salt so my comment from https://sd.suse.com/servicedesk/customer/portal/1/SD-142028 holds
Your decision is in conflict with the latest discussion with Moroni Flores regarding the topic of having DHCP servers maintained by IT. As long as OPS-Service/salt is applied - which we still want - then we can"t apply our own salt states and hence not ensure an up-to-date system state nor monitor it. There is also https://jira.suse.com/browse/ENGINFRA-3732 so I don’t plan to open another SD ticket for now blocking on that.
Blocking on https://jira.suse.com/browse/ENGINFRA-3732