metal-stack
Add switch migrate endpoint
Replaces https://github.com/metal-stack/metal-api/pull/526
With the previous PR migrating from Cumulus to SONiC was expected to occur during switch registration. The problem with that is that a switch replacement requires the new switch to have the same ID as the old one. But deploying a new switch with the same ID as an existing one can be problematic in some cases.
Therefore the new approach implements a switch/migrate endpoint that migrates the configuration from one switch to another, allowing both switches to have different OSs (Cumulus and Edgecore SONiC). With this approach it should be possible to register a switch first and perform the migration from an existing one to the new one afterwards, without requiring its ID to be the same as the old one's.
It should be much easier to test with this approach in the mini-lab, simply create a setup there where 2 cumulus switches and one SONiC Switch is present and then migrate one of the cumulus switches to the SONiC Switch. Then the configuration on the SONiC Switch must be identical
Open for discussion:
In addition to the migrate approach, a port mapping from Cumulus to SONiC also occurs when a switch gets replaced. So a migration is also possible right on switch registration. Do we want this, or should a switch replacement remain as it is, i.e. only for replacing a broken switch by a healthy one without changing OS?
Turns out the mapping from Cumulus to SONiC port names is off by 1. spw1 should map to Ethernet0 etc.