-
-
Notifications
You must be signed in to change notification settings - Fork 280
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 for multiple Kafka clusters within a spec #465
Comments
Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue. |
Copying over discussion from Slack as we don't know when it will dissapear cause of the free plan
|
Strawman suggestion for an approach - we could provide a cluster identifier for each server
|
I'm wondering if we really need the multiple clusters feature. For instance, if you think about how you would deploy an application generated with this AsyncApiSpec in K8s, the multiple cluster feature would not add any benefit. Usually, you have one Async spec for dev and one for prod because they will evolve at a different speed. Am I missing anything here? 🤔 Having said that, I like the feature of passing multiple brokers for one cluster. It's very in line with almost every streaming platform 🙂 |
I think I'm just used to being able to include both because that's how I use OpenAPI (e.g. https://spec.openapis.org/oas/v3.0.3#server-object-example ) |
Usually, I use |
+1 for this feature request. When developing a new version of the spec, we will typically create a new branch with a new spec version. We do not programmatically change the contract when promoting the spec from dev/test to prod, it is just approved and promoted. Our Kafka clients need a cluster server list in prod that is separate and independent from the list for the dev/test environment |
Could this be considered a duplicate of #244? Not sure. That's why I'm asking. |
Yes, I think so - I hadn't seen that issue before |
Isn't that issue more related to using multiple sets of brokers, each with different topics? Seems like a more complicated implementation since there is still only one url per server |
This issue has been automatically marked as stale because it has not had recent activity 😴 |
This issue has been automatically marked as stale because it has not had recent activity 😴 |
It is not. That one was pointing to another direction. This one is still valid and I think this should become an actual strawman RFC0. |
I think the question we might need to answer here is: Is it worth to be added in the core spec or rather as a Kafka server binding? Does the "cluster" concept applies to other protocols (It doesn't have to apply to all but most)? |
This is not really native to Kafka, NATS have the same "problem". Usually, in code you just pass an array or asyncapi: '2.0.0'
servers:
prod-broker:
url:
- dale-prod-broker-0:9092
- dale-prod-broker-1:9092
- dale-prod-broker-2:9092
protocol: kafka
dev-broker:
url:
- dale-dev-broker-0:9092
- dale-dev-broker-1:9092
- dale-dev-broker-2:9092
protocol: kafka To me, this is the most simple and uncomplicated approach to solve this 🤔 |
@dalelane do you want to champion this? 🙂 Or can we consider this issue as |
@jonaslagoni sure - I'd be happy to pick this up again |
This issue has been automatically marked as stale because it has not had recent activity 😴 It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation. There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model. Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here. Thank you for your patience ❤️ |
support for tags in servers being added in #465 gives us a mechanism for describing this I'll leave the issue open for now so I can add an example that demonstrates this |
yes, that's right... thanks! (sorry - that'll teach me to try and multi-task! 🤦♂️) |
Is your feature request related to a problem? Please describe.
A Kafka cluster is typically made of a group of Kafka brokers. The brokers act as peers, so a client is able to make an initial connection to any broker in the cluster, and a metadata exchange takes place to inform the client which broker it should connect to.
To enable the cluster to be highly-available to connections from clients, Kafka clients are typically configured with the address of every broker in the Kafka cluster - so that it can try each broker in turn in the event that the first broker it attempts to connect to is unavailable.
Currently, this is being modelled in AsyncAPI by identifying each broker as a separate
server
in the list of servers. For the purposes of code generation, an assumption is made that all the Kafka servers listed in theservers
section of the spec belong to the same cluster, and so all server URLs can be combined to provide a single bootstrap servers list.Describe the solution you'd like
I'd like a way to identify multiple separate Kafka clusters within a single AsyncAPI spec.
For example, imagine I have a development/test Kafka cluster composed of three brokers A, B, C
and a production Kafka cluster composed of three brokers D, E, F
It's not safe to put all six broker addresses as six separate server objects in the spec, as I don't have a way to identify the grouping, and current code-generation would treat it as a single Kafka cluster with six brokers in.
Additional context
The text was updated successfully, but these errors were encountered: