action #168967
closedSupport setup network for new bare-metal in PRG2e - D10 (SD-169875) size:S
0%
Description
Observation¶
5 machines for QE-Performance team in PRG2 to be ‘kind of relocation' for CC reason. 2 of them have arrived and have been installed in new QE Rack in [[https://racktables.nue.suse.com/index.php?page=rack&rack_id=24567 PRG2e - D10]], these 2 new 1 socket machines will be used as replacement for 2 very old UMA machines performance for 15SP7 and 16.
Machine name:
- 1u-perf01; 1u-perf01-ipmi
- 1u-perf02; 1u-perf02-ipmi
QE-Performance team and IT team need Tools team kindly support on this network enabling, for machines in this Rack can:
- be in qe-prg2e-date QE vlan, both NIC and IPMI get correct IP address from 10.146.4.0/23 and 2a07:de40:b230:1::/64
- machines has the access to Beijing network 10.200.128.0/20
https://sd.suse.com/servicedesk/customer/portal/1/SD-169875
Acceptance Criteria¶
- AC1: @cachen is happy with how the network connection of those machines is setup
Suggestions¶
- Ask the OP to clarify what we can help with
Updated by mkittler about 2 months ago
- Tags set to infra
- Category set to Support
- Target version set to Ready
Updated by mkittler about 2 months ago
- Status changed from New to In Progress
- Assignee set to mkittler
I'll see whether I can create a MR on the OPS repo similar to what has been done in #168556#note-7.
Updated by mkittler about 2 months ago
I cannot just create a MR like https://gitlab.suse.de/OPS-Service/salt/-/merge_requests/5605 because the host are not present at all.
So I created a MR similar to https://gitlab.suse.de/OPS-Service/salt/-/commit/38fff72bf30a53915b26f9507d7a5268ddd78b05 first: https://gitlab.suse.de/OPS-Service/salt/-/merge_requests/5709
However, there are a few things I'm not sure about:
- There are not enough
;free_ip
spots left. I simply appended the new hosts. I hope this is ok. - I don't know the MAC address of the interfaces. There is a rack linked in the ticket description and it has exactly two machines in it. So I copied those MAC addresses. Obviously this might be completely wrong and you were just referring to the rack but the machines have not been added there yet in racktables. I used the MAC addresses of the interfaces ipmi and eth0. Whether the latter is correct I don't know. (There wouldn't be any MAC addresses for eth2/eth3 present anyway. So even if that is what's supposed to be used I would not be able to configure it.) At least it doesn't look like these MAC addresses are already assigned to some other host.
- It is nowhere stated explicitly that DHCP/iPXE is supposed to be configured as in #168556#note-7 but the ticket title says "for new bare-metal" so I assumed that this is supposed to be done.
It would be nice if you would be more explicit on what you want us to configure when creating tickets like that.
After that is done I can change IPMI passwords and create worker slots like in https://gitlab.suse.de/openqa/salt-pillars-openqa/-/merge_requests/921.
Updated by livdywan about 2 months ago
- Subject changed from Support setup network for new bare-metal in PRG2e - D10 (SD-169875) to Support setup network for new bare-metal in PRG2e - D10 (SD-169875) size:S
- Description updated (diff)
Updated by cachen about 2 months ago
mkittler wrote in #note-3:
I cannot just create a MR like https://gitlab.suse.de/OPS-Service/salt/-/merge_requests/5605 because the host are not present at all.
So I created a MR similar to https://gitlab.suse.de/OPS-Service/salt/-/commit/38fff72bf30a53915b26f9507d7a5268ddd78b05 first: https://gitlab.suse.de/OPS-Service/salt/-/merge_requests/5709
However, there are a few things I'm not sure about:
- There are not enough
;free_ip
spots left. I simply appended the new hosts. I hope this is ok.- I don't know the MAC address of the interfaces. There is a rack linked in the ticket description and it has exactly two machines in it. So I copied those MAC addresses. Obviously this might be completely wrong and you were just referring to the rack but the machines have not been added there yet in racktables. I used the MAC addresses of the interfaces ipmi and eth0. Whether the latter is correct I don't know. (There wouldn't be any MAC addresses for eth2/eth3 present anyway. So even if that is what's supposed to be used I would not be able to configure it.) At least it doesn't look like these MAC addresses are already assigned to some other host.
- It is nowhere stated explicitly that DHCP/iPXE is supposed to be configured as in #168556#note-7 but the ticket title says "for new bare-metal" so I assumed that this is supposed to be done.
It would be nice if you would be more explicit on what you want us to configure when creating tickets like that.
Hello Marius, Big thanks for your helping on this task. Viktor is asking us to provide IPv4 and IPv6 addressed for eth0 and ipmi interfaces. My assumption is they need the address for the DHCP/DNS setup. The expectation for these 2 machines are clear, that IPMI/NIC eth0 can successfully get ip address from 10.146.4.0/23 qe-prg2e-date vlan, then QE-Performance team can continue their deployment from remotely. I hope DC-OPS team has recorded the correct MAX address for these 2 machines, then your MR should fulfill.
After that is done I can change IPMI passwords and create worker slots like in https://gitlab.suse.de/openqa/salt-pillars-openqa/-/merge_requests/921.
You can leave this passwords change to QE-Performance team, as these 2 machines will be connected to openqa.qa2.suse.asia Beijing local openQA, so they don't need worker slots from OSD. It means as long as the IPMI connection works, all the rest deployment can be taken over by QE-Performance team :)
Updated by openqa_review about 2 months ago
- Due date set to 2024-11-13
Setting due date based on mean cycle time of SUSE QE Tools
Updated by mkittler about 2 months ago
- Status changed from In Progress to Feedback
Then I think my MR will work as-is. I asked again on help-it-ama to get my MR merged.
You can leave this passwords change to QE-Performance team, as these 2 machines will be connected to openqa.qa2.suse.asia Beijing local openQA, so they don't need worker slots from OSD. It means as long as the IPMI connection works, all the rest deployment can be taken over by QE-Performance team :)
Good, that's even better :-)
Updated by okurz about 1 month ago
- Due date deleted (
2024-11-13) - Status changed from Feedback to Blocked
- Priority changed from High to Normal
Updated by mkittler about 1 month ago
- Status changed from Blocked to Feedback
The MR has just been merged. I suppose it'll become effective in the next hours. You can try whether you can reach the machines via IPMI then.
Updated by mkittler about 1 month ago · Edited
It looks like IP addressed for all hosts are correctly returned by the DHCP server. Unfortunately the BMC is not responding via HTTP or IPMI. (I also tried via jumpy@qe-jumpy.prg2.suse.org
.)
Updated by JNa about 1 month ago · Edited
I have tried, and the IPMI connection on these 2 machines are working properly.Thank you.
Updated by mkittler about 1 month ago
- Status changed from Feedback to Resolved
Nice that it worked. So I'm considering this issue resolved.
Updated by okurz 20 days ago
- Copied to action #173500: Support setup network for new bare-metal in PRG2e - D10 (SD-173361) added