Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix swarm timeout between orborus and worker hosted on separate nodes #1146

Merged
merged 6 commits into from
Jul 3, 2023

Conversation

0x0elliot
Copy link
Member

@0x0elliot 0x0elliot changed the base branch from main to 1.2.0 June 22, 2023 23:55
@0x0elliot 0x0elliot changed the title Fix swarm timeout Fix swarm timeout between orborus and worker hosted on separate nodes Jun 22, 2023
@0x0elliot
Copy link
Member Author

0x0elliot commented Jun 23, 2023

yet to be tested. let's wait before we proceed.

@0x0elliot
Copy link
Member Author

Shuffle/Shuffle-docs#171 please close as you close this.

@0x0elliot
Copy link
Member Author

my concerns i would want you to review start here:

targetInterface := interfaces[1]

my assumption is that in the container, the first network interface after loopback is the best way to spot the docker bridge network. this is an observation i made. i don't know when it would change. you will have to give some feedback on the consistency of this.

i am also thinking of checking once if the network interface contains "eth0" since it does till a certain part.

@0x0elliot 0x0elliot requested a review from frikky June 23, 2023 02:01
Copy link
Member

@frikky frikky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Submit review!!

functions/onprem/orborus/orborus.go Outdated Show resolved Hide resolved
functions/onprem/orborus/orborus.go Outdated Show resolved Hide resolved
functions/onprem/orborus/orborus.go Outdated Show resolved Hide resolved
@0x0elliot
Copy link
Member Author

0x0elliot commented Jun 29, 2023

Would test this and make sure it's somewhat ready for prod. Be ready to see it break however. Quite unsure about the network interface naming however if chatGPT isn't hallucinating:

When a container is started, Docker creates a network namespace for that container, isolating its network stack from the host and other containers. Within the container's network namespace, Docker creates a virtual Ethernet interface that connects to the bridge network interface (docker0) on the host. This interface is typically named eth0.

If a container is connected to multiple networks, additional virtual Ethernet interfaces are created, and they are named sequentially as eth1, eth2, and so on.

I referred to this pattern in the code. Will test it by tomorrow so you can put it to prod.

https://medium.com/@diegogabrielschurch/how-docker-network-works-bridge-driver-e4819459cc8a this article does make me a little bit more clear. but i know we will break something :)

Docker by default creates rules to redirect the packages that go throw docker0 to eth0 interface. Also, creates a NAT over our docker networks to make them behave like private networks and block access from outside of the network.

@0x0elliot
Copy link
Member Author

This definitely makes me feel more confident in nothing messing up.

@0x0elliot
Copy link
Member Author

Ready for merge. Let's break things.

@0x0elliot
Copy link
Member Author

ready

@frikky
Copy link
Member

frikky commented Jul 3, 2023

Looks better! Covering all bases with a fallback

@frikky frikky merged commit 6e405e7 into Shuffle:1.2.0 Jul 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

None yet

2 participants