Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Decentralized pod networking #686
Jan 29, 2018
referenced this pull request
Jan 29, 2018
I think putting the IP address in the Status section makes a lot of sense. The IP address is actually something we know before the VM gets scheduled. We can write the IP address to the Status field before assigning it to a node even in virt-controller.
I'm uncertain if reporting the MAC in the VM's status matters. I don't see a reason to expose that unless we have a use case. I can think of lots of use-cases for the IP address though.
The DHCP server looks fairly straight forward to unit test. We can just start the server and send requests to it.
Have you thought through any possibilities for unit testing the "SetupDefaultPodNetwork" function?
The only thing I could come up with after looking at it for a bit is for us to make our own go interface that wraps the netlink functions, and then mockgen our interface for the unit tests.
I can think of a lot of use-cases for non-pod networks. Only adding the IP right now works for me.
davidvossel left a comment •
We need to iterate a bit more on how we do the DHCP server.
There would be a cmd channel and error channel used to communicate with the dhcp manager.
This dhcp manager would wait for a start command on the cmd channel. A start cmd would result in another goroutine launching with the dhcp.Serve(). Any additional calls to start the dhcp server would just fast succeed.
dhcp errors would get sent back on the errors channel. We'd have the ability to inspect the state of the actual VM process to decide how to proceed with handling the error.
rmohr left a comment
I think we can pretty much leave it as it is. I think we need to make sure anyway that the network setup is either reentrant or that we skip it after the first successful run. I don't see any issue starting the dhcp server with the right config directly.
davidvossel left a comment
I found one minor thing when testing this locally that's just related to running the functional tests on a single node. I made a comment about how to address that.
For CI, jenkins has been able to verify that vm<->pod and node->vm connectivity works. However there's something going on that is preventing vm->internet from working. I believe that issue is most likely related to DNS on the jenkin's host machines. If the vm->internet connectivity continues to fail in jenkins, I'm in favor of disabling that test and following up on that issue in a separate PR. I've tested these changes locally in multiple cluster configurations and never encountered the connectivity issue Jenkins hit.
I think this patch series is in a mergable state at this point.
You've done an amazing job here @vladikr, well done!