The only options we have to make network changes so far are:
1/ manual change
2/ automated but full config change via Homer
Unfortunately, this 2nd option is slow (gathering data from multiple locations, generating a whole config), not flexible, and error prone (eg. risk of pushing an unrelated change)
I suggest we introduce a 3rd way in the form of a Spicerack module that will abstract specific parts of the configuration.
This should work hand in hand with Netbox to be dynamic (for example: no dependency on Homer yaml files).
It will be more and more valuable as vendors are moving away from flat configurations, towards REST-like APIs.
Short term use cases:
- server facing switch port config for host provisioning and decommissioning - DONE
- Troubleshooting automation - DONE
Medium term is:
Longer term:
- Maintenance automation (upgrade device, etc)
- DDoS mitigation automation (T251767, blackholing, etc)
Focusing on the short term, as a proof of concept this module would be used by both cookbooks:
- sre.hosts.provision
- sre.hosts.decommission
The switch configuration would be abstracted with:
def configure_switch_interface(self, netbox_device)
Which would:
1/ get the switch/interface data from Netbox (requires Netbox to already be up to date, which can be done right before, in the same cookbook)
2/ get the current switch port(s) config
3/ warn the user (or refuse to do the change) if the interface is used for something else
4/ configure the switch port(s) - for now just replace the interface config, later on could be idempotent and offer conciliation options (eg. only change the MTU or vlans)
That's a high level view, feedback welcome :)