RFE - Change to how instackenv.json is generated

[QuantumPosix]

Right now -instackenv.json uses a hardcoded interface to set as what is listed for the mac-address.
position mac.append(host.interfaces[1].mac_address)

if this were to change to use a conditional for the first position of what is setup by the admin in quads/conf/idrac_interfaces.yml based on the interfaces that were listed for the model under director only and print out that interface's mac.

[sadsfae]

@grafuls had a good suggestion to tackle with adding an additional parameter to the interfaces model in mongoDB, so we can have a defacto "pxe interface" for every system - this would provide even more flexibility in that (not recommended but if we need to) can utilize different PXE interfaces at the host level.

[sadsfae]

RFE development in progress here: https://review.gerrithub.io/c/redhat-performance/quads/+/509138

[sadsfae]

RFE development in progress here: https://review.gerrithub.io/c/redhat-performance/quads/+/509138

This is reviewed and merged, however it still needs to be packaged into RPM and applied - likely this will land in a 1.1.5 release soon and Scale Lab and then ALIAS will upgrade to it.

@asyedham in the meantime please relay to us the appropriate interface that you'd like the ALIAS version of instackenv.json that is generated to reflect, as it's not obviously EM2 / NIC2 that we use in Scale Lab. This is a quick change that upon next rendering should reflect a usable instackenv.json for your purposes now.

Specifically, which of the below interfaces taking from one of your current assignments is the one you want instackenv.json to use (and we'll set that as ALIAS default in the codebase until the above patch is packaged and pushed out)

# quads-cli --ls-interface --host e23-h25-740xd.example.com
interface: em1, mac address: 24:6E:96:C2:AB:C4, switch IP: 10.19.97.232, port: xe-0/0/4
interface: em2, mac address: 24:6E:96:C2:AB:C5, switch IP: 10.19.97.232, port: xe-0/0/5
interface: em3, mac address: 3C:FD:FE:C1:73:60, switch IP: 10.19.97.233, port: et-0/0/3:0
interface: em4, mac address: 3C:FD:FE:C1:73:61, switch IP: 10.19.97.233, port: et-0/0/3:1

[asyedham]

@sadsfae Usually the first node in the instackenv.json is used for undercloud and boot order style is set to foreman which you can see on e23-h25-740xd.example.com. But for the remaining nodes, the boot order is set to director style using badfish to deploy OSP

Badfish currently sets this boot order sequence for director mode

director_740xd_interfaces: NIC.Integrated.1-1-1,NIC.Integrated.1-2-1,NIC.Slot.7-2-1,NIC.Slot.7-1-1,NIC.Integrated.1-3-1,HardDisk.List.1-1

But earlier when we tried OSP deployment on cloud06 setting the boot order to director as above for overcloud nodes, deployment failed as the nodes got stuck in wait_call_back state as the MAC address in instackenv.json was for NIC2 and director boot order sets NIC1 ahead of NIC2. Once I updated the director boot as below I was able to get stable deployment in Alias Lab.

director_740xd_interfaces: NIC.Integrated.1-2-1,NIC.Integrated.1-1-1,NIC.Slot.7-2-1,NIC.Slot.7-1-1,NIC.Integrated.1-3-1,HardDisk.List.1-1

For OSP to deploy on Alias these requirements should be met

• Host machine has to pxe boot on the interface which is specified in the instackenv.json
• PXE boot should be enabled on this interface in bios settings

I hope the quads PR can address the above-mentioned requirements to get stable osp deployment without the need to manually modify the director boot order in badfish

Thanks,
~Asma

[sadsfae]

@sadsfae Usually the first node in the instackenv.json is used for undercloud and boot order style is set to foreman which you can see on e23-h25-740xd.example.com. But for the remaining nodes, the boot order is set to director style using badfish to deploy OSP

Badfish currently sets this boot order sequence for director mode

director_740xd_interfaces: NIC.Integrated.1-1-1,NIC.Integrated.1-2-1,NIC.Slot.7-2-1,NIC.Slot.7-1-1,NIC.Integrated.1-3-1,HardDisk.List.1-1

But earlier when we tried OSP deployment on cloud06 setting the boot order to director as above for overcloud nodes, deployment failed as the nodes got stuck in wait_call_back state as the MAC address in instackenv.json was for NIC2 and director boot order sets NIC1 ahead of NIC2. Once I updated the director boot as below I was able to get stable deployment in Alias Lab.

director_740xd_interfaces: NIC.Integrated.1-2-1,NIC.Integrated.1-1-1,NIC.Slot.7-2-1,NIC.Slot.7-1-1,NIC.Integrated.1-3-1,HardDisk.List.1-1

For OSP to deploy on Alias these requirements should be met

* Host machine has to pxe boot on the interface which is specified in the instackenv.json

* PXE boot should be enabled on this interface in bios settings

I hope the quads PR can address the above-mentioned requirements to get stable osp deployment without the need to manually modify the director boot order in badfish

Thanks,
~Asma

What we need to know from you is what interface do you consistently expect PXE traffic to use for OSP/ironic in ALIAS.

Giving us the idrac_interfaces.yml strings doesn't give us a clear picture on what interface this is because QUADS generates instackenv.json and determines its own order. Interface strings can change based on slot placement for example also.

I think that you want em1 below, but I am not positive and don't do a whole lot in ALIAS.

Please tell us from the paste below which interface/mac should be the consistent one you expect for generated instackenv.json in ALIAS. Is it EM1, EM2, EM3, EM4? - this is one of your systems in ALIAS.

# quads-cli --ls-interface --host e23-h25-740xd.example.com
interface: em1, mac address: 24:6E:96:C2:AB:C4, switch IP: 10.19.97.232, port: xe-0/0/4
interface: em2, mac address: 24:6E:96:C2:AB:C5, switch IP: 10.19.97.232, port: xe-0/0/5 <-- scale lab uses this
interface: em3, mac address: 3C:FD:FE:C1:73:60, switch IP: 10.19.97.233, port: et-0/0/3:0
interface: em4, mac address: 3C:FD:FE:C1:73:61, switch IP: 10.19.97.233, port: et-0/0/3:1

You should not need to modify the director boot via badfish at all once this is set and it can be done immediately in the ALIAS QUADS codebase so the next instackenv.json that's generated every few minutes will then reflect it.

[sadsfae]

The RFE here is merged, closing this issue now.

https://review.gerrithub.io/c/redhat-performance/quads/+/509138