action #153682
closedcoordination #121720: [saga][epic] Migration to QE setup in PRG2+NUE3 while ensuring availability
coordination #153685: [epic] Move from SUSE NUE1 (Maxtorhof) to PRG2e
Move of selected LSG QE machines NUE1 to PRG2e - quinn size:M
0%
Description
Acceptance criteria¶
- AC1: quinn is usable from PRG2e, i.e. as bare-metal test machine in OSD
Suggestions¶
- DONE Follow https://jira.suse.com/browse/ENGINFRA-3737
- Follow what has been done in #153670
- Ensure PXE boot works, possibly same as #155521, simply add next_server config in OPS-Service/salt
- Update openQA salt pillars
- Ensure machine can be reached
- Ensure openQA bare-metal tests using the machine are successful
Updated by okurz 3 months ago
- Copied from action #153670: Move of selected LSG QE machines NUE1 to PRG2e - fozzie size:M added
Updated by okurz 3 months ago
- Copied to action #153688: Move of selected LSG QE machines NUE1 to PRG2e - openqaw9-hyperv added
Updated by okurz 2 months ago
- Description updated (diff)
- Status changed from Blocked to New
- Assignee deleted (
okurz) - Target version changed from future to Ready
https://jira.suse.com/browse/ENGINFRA-3737 done. Connectivity, racktables and verification using openQA should be done.
Updated by okurz 2 months ago
- Related to action #155725: [openQA][infra][sut] Failed to establish connnection to fozzie-sp and quinn-sp added
Updated by xlai about 2 months ago
@okurz Hi Oliver, when prioritizing which machines to bring up earlier, can we suggest to bump priority of this machine? For 15sp6 VT test, we notice machine shortage to meet 1 day acceptance due time. Thanks in advance!
Updated by dheidler about 2 months ago
- Status changed from Workable to In Progress
Updated by dheidler about 2 months ago · Edited
- Status changed from In Progress to Blocked
Now waiting for infra: https://gitlab.suse.de/OPS-Service/salt/-/merge_requests/4852
We couldn't test this as we still have no access to fozziebear (dhcp server) as already requested in #153664 and ENGINFRA-3732.
Updated by xlai about 2 months ago
Hi,
Is this blocked by
https://jira.suse.com/browse/ENGINFRA-3732? Is the machine usable in openqa now?
Updated by okurz about 1 month ago
xlai wrote in #note-15:
Hi,
Is this blocked by
https://jira.suse.com/browse/ENGINFRA-3732?
Yes
Is the machine usable in openqa now?
No, not yet
Updated by xlai about 1 month ago
okurz wrote in #note-16:
xlai wrote in #note-15:
Hi,
Is this blocked by
https://jira.suse.com/browse/ENGINFRA-3732?Yes
Is the machine usable in openqa now?
No, not yet
@okurz Thanks for the reply Oliver. I am a little bit confused. Just to be clear of the situation. The ENGINFRA-3732 is about asking permission on some dhcp server. Without permission, will this ticket be blocked forever? Can SUSE-IT do it for us? BTW, what is the real TODO part to make the machine workable in openqa?
Updated by okurz about 1 month ago
xlai wrote in #note-17:
@okurz Thanks for the reply Oliver. I am a little bit confused. Just to be clear of the situation. The ENGINFRA-3732 is about asking permission on some dhcp server. Without permission, will this ticket be blocked forever?
Without access to the DHCP server our work will be harder and takes more time but we will still continue. The challenge is to ensure that the network connections and configurations are correct. For that having access to the DHCP logs would make verification much easier.
Can SUSE-IT do it for us?
SUSE-IT are the owners of the DHCP server so they need to act to either give us access, that's the above ticket, or react to requests to verify the DHCP operation.
BTW, what is the real TODO part to make the machine workable in openqa?
After the network network configuration was verified we can mark the according worker classes as production-ready again. That should be it as we already have other machines in place that showed that the general PRG2e-qe network including PXE is usable.
Updated by xlai about 1 month ago · Edited
I see, thanks Oliver. BTW, below is merged.
Now waiting for infra: https://gitlab.suse.de/OPS-Service/salt/-/merge_requests/4852
or react to requests to verify the DHCP operation
Do you mean verifying above MR's change? Would you please share the request link? I'd like to make some voice there ;-) . Or, will it be enough to check the ipxe boot on our side?
Updated by okurz about 1 month ago
- Status changed from Blocked to In Progress
xlai wrote in #note-19:
I see, thanks Oliver. BTW, below is merged.
Now waiting for infra: https://gitlab.suse.de/OPS-Service/salt/-/merge_requests/4852
or react to requests to verify the DHCP operation
Do you mean verifying above MR's change?
Yes. @dheidler can you clarify what's the latest state here regarding network configuration on quinn+fozzie?
Would you please share the request link? I'd like to make some voice there ;-)
Certainly, the most recent request is actually in https://jira.suse.com/browse/ENGINFRA-3732?focusedId=1334243#comment-1334243
There might be more communication in discouraged private conversations. For what we need to rely on dheidler to drive the topic.
. Or, will it be enough to check the ipxe boot on our side?
You are welcome to do so but I expect that dheidler has done so already within the past 8 days. I just don't know the current state.
Updated by okurz about 1 month ago
- Status changed from In Progress to Blocked
Apparently the network setup was never completed: https://sd.suse.com/servicedesk/customer/portal/1/SD-151127
Blocked again
Updated by dheidler about 1 month ago
- Status changed from Blocked to Feedback
Seems that on the existing os on the disk of quinn there was some bridge set up with STP enabled.
For some reason the TOR switch didn't like that and deactivated the port.
I deleted that bridge from the existing os (that is being installed over by openQA anyway).
Now it seems to work fine looking at the verification run.
--> https://gitlab.suse.de/openqa/salt-pillars-openqa/-/merge_requests/747
Updated by xlai about 1 month ago · Edited
dheidler wrote in #note-22:
Seems that on the existing os on the disk of quinn there was some bridge set up with STP enabled.
For some reason the TOR switch didn't like that and deactivated the port.I deleted that bridge from the existing os (that is being installed over by openQA anyway).
Now it seems to work fine looking at the verification run.--> https://gitlab.suse.de/openqa/salt-pillars-openqa/-/merge_requests/747
Thanks. Looks good to me. From verification job link, it seems we will need to update automation test for the new ip subnet range. @Julie_CAO FYI.
Updated by okurz about 1 month ago
- Due date set to 2024-03-27
Updated by xlai about 1 month ago
- Status changed from Feedback to Resolved
It is working for OSD tests. Thanks!
Updated by okurz about 1 month ago
I don't understand. Both quinn and fozzie are bare-metal test machines meaning that by default you can assume nothing is installed on those machines. Is this a mount path that is provided by test code when tests install a new operating system on those machines?
Updated by Julie_CAO about 1 month ago
okurz wrote in #note-27:
I don't understand. Both quinn and fozzie are bare-metal test machines meaning that by default you can assume nothing is installed on those machines. Is this a mount path that is provided by test code when tests install a new operating system on those machines?
thanks Oliver. It should be an issue from automation tests. I'll look into the test scripts.