-
Notifications
You must be signed in to change notification settings - Fork 694
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
Proposal to provide config based deactivation of QueueGroups for Service #1669
base: main
Are you sure you want to change the base?
Conversation
…ice. Not every service is required to be in a QueueGroup. Some services require direct address and the code changes presented here are for discussion. Is this an acceptable way to turn off QueueGroups? It works in my testing, but was wondering if there are better suggestions? Naturally, these changes have dependencies. The Schema entry for the services info_response will need changing, to allow for the tokensied naming with a period. This definition https://nats.io/schemas/micro/v1/info_response.json specifically requires `basic_name` to allow the period and it is proposed to create a `micro_name` definition that includes the period. Just to be clear, I appreciate that this might not be the solution, but as we do more with Service, this has come up and needs to be addressed. I'm happy to make the various PRs to extend this, but wanted to seek opinion and counsel before blindly going after a PR! If you're curious, you can export the env var `NOVALIDATE="nope"` for the `nats` CLI client and stand up some period tokenised services and get info using this PR. ```go group := srv.AddGroup("test") // the subject token pattern here is "test.get.1234" err = group.AddEndpoint("get.1234", micro.HandlerFunc(getHandler), micro.WithDisableQueueGroup(true)) ``` Cheers, Dave Signed-off-by: davedotdev <me@dave.dev>
Can you elaborate a bit more on the use case here? We'll either end up with multiple instances all getting the request or each instance being entirely unique - in which case having a queue group is a noop really. |
Sure. It's not a switch of design, but a configurable option to add more design options. This is for service use cases that don't require NATS to load balance them, pushing the act of steering request distribution elsewhere for service like sentinel nodes, workflow style routers and other systems. Users get the benefit of the service abstraction and CLI tooling, but with extra controls for different service styles. If the queue group stays turned on (default), then it's as before. If however QGs are turned off for an endpoint, then the service can be unique. That means something else can distribute requests to it. Also, subject names can be more complex, enabling different patterns. A service in theory could require QG, vanilla pub/sub or direct request/reply. Use cases include: Fleet management; IoT etc could need both QG and non-QG approaches; signalling to end-points to download an over the air update; taking control of a building management system that's online as service; rolling IoT/fleet coordinated reboots etc. In the network world, being able to manage a fleet of network operating systems, with direct communication capabilities is key. It's a convenience extension. In highly connected systems, NATS can be the central pillar of observability, communication, data and control, without requiring on other service abstractions. That help? In short, multiple use cases, but summarised within extra design options, fleet and IoT. Assuming the above satisfies your query, is there anything in the codified approach which could be done better? I figure it's a minimal surface area, non-breaking proposal and I tried to keep this initial stab within the patterns and structure of the code. |
Idea seems fine, think we need a more concise problem statement. changes to micro affects all languages and so we start with a ADR update and go from there into all languages |
I'll look at the ADR. Cheers. |
Proposal to provide config based deactivation of QueueGroups for Service
Not every service is required to be in a QueueGroup. Some services require direct address and the code changes presented here are for discussion.
Is this an acceptable way to turn off QueueGroups? It works in my testing, but was wondering if there are better suggestions?
Naturally, these changes have dependencies. The Schema entry for the services
info_response
will need changing, to allow for the tokensied naming with a period.This definition
https://nats.io/schemas/micro/v1/info_response.json
specifically requiresbasic_name
to allow the period and it is proposed to create amicro_name
definition that includes the period.Just to be clear, I appreciate that this might not be the solution, but as we do more with Service, this has come up and needs to be addressed. I'm happy to make the various PRs to extend this, but wanted to seek opinion and counsel before blindly going after a PR!
If you're curious, you can export the env var
NOVALIDATE="nope"
for thenats
CLI client and stand up some period tokenised services and get info using this PR.Cheers,
Dave