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

Support mutliple cluster contact points on the standalone Gateway #4856

Closed
Zelldon opened this issue Jul 1, 2020 · 7 comments · Fixed by #9508
Closed

Support mutliple cluster contact points on the standalone Gateway #4856

Zelldon opened this issue Jul 1, 2020 · 7 comments · Fixed by #9508
Labels
kind/feature Categorizes an issue or PR as a feature, i.e. new behavior scope/gateway Marks an issue or PR to appear in the gateway section of the changelog version:8.1.0-alpha3 Marks an issue as being completely or in parts released in 8.1.0-alpha3 version:8.1.0 Marks an issue as being completely or in parts released in 8.1.0

Comments

@Zelldon
Copy link
Member

Zelldon commented Jul 1, 2020

Is your feature request related to a problem? Please describe.

Currently we support only one cluster contact point, which is problematic when this contact point is currently not available.
This can happen in multiple situations, directly on start but also on a network partition. Imagine the gateway was partitioned it removes all there nodes, because it can't connect to them. When the network partition is over but the contact point is not available it will not be able to connect to the rest of the cluster.

We handle this in k8s setup via dns, since we use as contact point a domain which can be resolved to multiple nodes. This is not easy possible on bare metal, docker setups or integration tests.

Especially on the last one I would like to have these kind of feature, because it makes it possible to write more different integration tests and make them also less flaky.

It is also a bit confusing why we support only one in the gateway and multiple at the broker side.

Note: The contact point is directly used as initial contact point in atomix.

Describe the solution you'd like

Similar to the initial contact points in the broker I would expect a list of contact points.

Describe alternatives you've considered
Idk how to fix that in it tests or docker compose setup?

@Zelldon Zelldon added kind/feature Categorizes an issue or PR as a feature, i.e. new behavior Status: Needs Priority scope/gateway Marks an issue or PR to appear in the gateway section of the changelog labels Jul 1, 2020
@npepinpe
Copy link
Member

npepinpe commented Jul 1, 2020

Currently blocks us from testing the behaviour of a gateway after network partition.

@npepinpe npepinpe self-assigned this Jul 1, 2020
@npepinpe npepinpe removed their assignment Aug 20, 2020
@npepinpe
Copy link
Member

npepinpe commented Nov 9, 2020

I'm downgrading this to mid until we make a decision on whether or not standalone gateway will be the deployment for Cloud GA.

@Zelldon
Copy link
Member Author

Zelldon commented Oct 7, 2021

Would be interesting if we deploy standalone gateway in cloud @npepinpe

@npepinpe
Copy link
Member

npepinpe commented Oct 7, 2021

In cloud we use the broker's service URL, which already performs load balancing, so I'm not sure if having multiple contact points is all that useful for that particular set up. I think it's still mostly useful for deployments where there is nothing between the gateway and brokers, i.e. bare metal deployments.

@Zelldon
Copy link
Member Author

Zelldon commented Oct 7, 2021

Ah true you're right.

@aivinog1
Copy link
Contributor

Hey @Zelldon @npepinpe!
We are currently deploying Zeebe on our bare metal environment and it would be nice if we could have load balancing support for this out of the box. I can contribute it if you are generally is okay with this feature in Zeebe :) I would also vote for the same in #9413.

@npepinpe
Copy link
Member

Go for it. Keep in mind that there's no real load balancing happening here - this list is just a way for the gateway to join the cluster initially. Once it has joined, it will talk to the different brokers based on the topology of the cluster.

The only asterisk here is make sure everything works as is with the embedded gateway.

@oleschoenburg oleschoenburg added the version:8.1.0-alpha3 Marks an issue as being completely or in parts released in 8.1.0-alpha3 label Jul 5, 2022
@Zelldon Zelldon added the version:8.1.0 Marks an issue as being completely or in parts released in 8.1.0 label Oct 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes an issue or PR as a feature, i.e. new behavior scope/gateway Marks an issue or PR to appear in the gateway section of the changelog version:8.1.0-alpha3 Marks an issue as being completely or in parts released in 8.1.0-alpha3 version:8.1.0 Marks an issue as being completely or in parts released in 8.1.0
Projects
None yet
5 participants