azure-container-networking
azure-container-networking copied to clipboard
fix: issue dhcp request on windows secondary interfaces
Reason for Change:
We need to issue a dhcp request to the host in order to create a mapping for the secondary interface. The mapping allows for us to query the azure dns server on the secondary interface. The dhcp discover request occurs before the interface has the intended ip or is moved into the container namespace, but it does have an apipa autoconfigured ip. The auto assigned ip allows us to set the source ip of the packet so that the dhcp packet goes out on the interface that we want. We assume the interface always gets an auto configured ip. Then, once cni completes, we expect that secondary interface to be moved into the container.
Adds validation for nwCfg.Master since we issue exec commands with the field, so ensure this validation does not break anything else.
Reorganizes code into dhcp linux, windows and common.
Reorganizes retry logic into separate package
Confirm that we only run this code if we are on swiftv2 windows (is the nic type condition correct?). Confirmed yes.
Tested:
- standalone prototype binary
- swiftv2 windows happy path (saw packet on secondary)
- swiftv2 time out on waiting for response will correctly give context deadline exceeded
- swiftv2 multiple pods can be created
- swiftv2 ips are assigned according to mtpnc
- https://msazure.visualstudio.com/One/_build/results?buildId=105427745&view=results
Limitations:
- Assumes auto configuration ip will always be assigned to the interface
Issue Fixed:
Requirements:
- [X] uses conventional commit messages
- [ ] includes documentation
- [ ] adds unit tests
- [x] relevant PR labels added
Notes: Related to #2989