search

me-box-archive / databox-netdev

Old Dev version Databox OS container manager and dashboard server (do not use)
MIT License
3 stars 6 forks source link

Fix some network issues #62

Closed yousefamar closed 7 years ago

yousefamar commented 7 years ago

This PR prevents containers that are already in pair networks from connecting again, mitigating #60. It also raises the number of networks we can have to a theoretical 65535.

What I did was a bit hacky, but in essence, the networks that are created will have subnet 10.0.0.0/24 through to 10.255.255.0/24 instead of Docker defaults.

It shouldn't be necessary to launch the Docker daemon with similar settings, though I left some room just in case (if launching through systemd, config is /etc/docker/daemon.json with something like { "bip": "10.0.0.1/24"}).

The reason that I'm not PRing into master, and instead into a feature branch, is because there are still other issues with this container network pair architecture. Mainly I believe it's race conditions and timing issues where connections are made after containers are launched, instead of created, and that in turn has containers trying to communicate to other containers that they can't see yet. This throws a lot of things out of whack, such as apps requesting tokens from the arbiter before it was connected to them, so now they don't have the needed tokens. Huge mess.

Anyway, @Toshbrown suggested that we revert to pre-#50 because of these regressions, and I agree. We should also enact a feature freeze until the launch. This would be an enhancement, and doesn't change the APIs, and isn't critical before the launch.

I suggest that this branch can stay as it is (at current master) and we revert master to match @Toshbrown branch backupPlan, since that is, for all intents and purposes, ready for the launch.

sevenEng commented 7 years ago

Things seem to be a little bit more complex than previously thought. As this Friday is approaching, and really couple of unclear issues hanging around. It seems that it's reasonable to have a relatively stable master branch and another feature branch.