Change Details

Prerequisite for T262899. We need to add the switch config to the server provisioning automation and the AssignIPs script seems ideal for that based on the order of steps defined in: https://wikitech.wikimedia.org/wiki/Server_Lifecycle#Requested_-%3E_Planned_additional_steps_&_Spare_-%3E_Planned This would only be for "regular" servers. Most complex setups, like trunked ports, multiple NICs, etc.. would need to be done manually in Netbox. The current idea is to add the following fields to https://netbox.wikimedia.org/extras/scripts/interface_automation/AssignIPs/ * Switch interface name * Cable ID * Cable type (mostly to distinguish between fiber and DAC, unless we set it to the correct one later on using PuppetDB) Then the extra data needed and derived from other sources: * Switch name, derived from device's rack * VLAN, from the existing script fields * switch interface type, derived from port name * Cable color, derived from cable type Additionally from its original purpose the script would: # Create the switch interface if not present # Configure or update the switch interface (status, vlan, type) # Connect the ##PRIMARY## server interface to the aforementioned switch interface Then a Homer run from the operator would be needed to apply the changes to the switch. This could optionally be extended to support management cables by asking the operator: * Management cable ID * Management switch port Additionally, a report for mismatch interfaces type on either-side of the cable would be a nice plus.

Prerequisite for T262899. We need to add the switch config to the server provisioning automation and the AssignIPs script seems ideal for that based on the order of steps defined in: https://wikitech.wikimedia.org/wiki/Server_Lifecycle#Requested_-%3E_Planned_additional_steps_&_Spare_-%3E_Planned This would only be for "regular" servers. Most complex setups, like trunked ports, multiple NICs, etc.. would need to be done manually in Netbox. The current idea is to add the following fields to https://netbox.wikimedia.org/extras/scripts/interface_automation/AssignIPs/ * Switch interface name * Cable ID * Cable type (mostly to distinguish between fiber and DAC, unless we set it to the correct one later on using PuppetDB) Then the extra data needed and derived from other sources: * Switch name, derived from device's rack * VLAN, from the existing script fields * switch interface type, derived from port name * Cable color, derived from cable type Additionally from its original purpose the script would: # Create the switch interface if not present # Configure or update the switch interface (status, vlan, type) # Connect the ##PRIMARY## server interface to the aforementioned switch interface Then a Homer run from the operator would be needed to apply the changes to the switch. This could optionally be extended to support management cables by asking the operator: * Management cable ID * Management switch port Which would create the mgmt switch port and connect the mgmt cable. Additionally, a report for mismatch interfaces type on either-side of the cable would be a nice plus.

Prerequisite for T262899. We need to add the switch config to the server provisioning automation and the AssignIPs script seems ideal for that based on the order of steps defined in: https://wikitech.wikimedia.org/wiki/Server_Lifecycle#Requested_-%3E_Planned_additional_steps_&_Spare_-%3E_Planned This would only be for "regular" servers. Most complex setups, like trunked ports, multiple NICs, etc.. would need to be done manually in Netbox. The current idea is to add the following fields to https://netbox.wikimedia.org/extras/scripts/interface_automation/AssignIPs/ * Switch interface name * Cable ID * Cable type (mostly to distinguish between fiber and DAC, unless we set it to the correct one later on using PuppetDB) Then the extra data needed and derived from other sources: * Switch name, derived from device's rack * VLAN, from the existing script fields * switch interface type, derived from port name * Cable color, derived from cable type Additionally from its original purpose the script would: # Create the switch interface if not present # Configure or update the switch interface (status, vlan, type) # Connect the ##PRIMARY## server interface to the aforementioned switch interface Then a Homer run from the operator would be needed to apply the changes to the switch. This could optionally be extended to support management cables by asking the operator: * Management cable ID * Management switch port Which would create the mgmt switch port and connect the mgmt cable. Additionally, a report for mismatch interfaces type on either-side of the cable would be a nice plus.