You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description:
In Kubernetes deployment scenarios (for example using Argo Rollouts) it would be highly beneficial for an application to establish all of its subscriptions (core NATS) on the NATS server while keeping the connection in a "paused" state, i.e. not receiving any messages until the service is fully ready. This functionality would allow a service to start up, initialize its subscriptions, and then begin processing messages only after an explicit resume command is issued.
In addition, having the ability to assign weights to connections or subscriptions would enable gradual rollout of a new version of a service. For example, during an Argo Rollout, operators could gradually increase the traffic weight directed to the new version without requiring any changes on the client side (clients continue to publish requests to the same subject).
Enable a connection mode where an application can create all subscriptions upon startup but “pause” message delivery from the NATS server until explicitly resumed.
This feature would help ensure that a service does not start processing traffic before it is fully initialized and ready. Weighted Routing/Connections:
Allow configuration of weight values for individual connections or subscriptions within the same NATS cluster.
This would enable a gradual rollout (canary deployment) scenario where, for instance, the new version of a service could initially receive a small percentage (e.g., 10%) of the traffic, while the stable version receives the rest.
Over time, these weights could be adjusted to gradually shift more traffic to the new version.
Use case
When deploying an update via Argo Rollout in Kubernetes, a new pod can start up and create all necessary subscriptions on the shared NATS cluster while keeping its connection paused. Once readiness checks pass, an operator (or an automated process) gradually resumes message processing by assigning a low weight (e.g., 10%) to the new version. As confidence in the new version increases, the weight can be increased step by step until it eventually reaches 100%, and the old version is phased out.
Contribution
No response
The text was updated successfully, but these errors were encountered:
Proposed change
Description:
In Kubernetes deployment scenarios (for example using Argo Rollouts) it would be highly beneficial for an application to establish all of its subscriptions (core NATS) on the NATS server while keeping the connection in a "paused" state, i.e. not receiving any messages until the service is fully ready. This functionality would allow a service to start up, initialize its subscriptions, and then begin processing messages only after an explicit resume command is issued.
In addition, having the ability to assign weights to connections or subscriptions would enable gradual rollout of a new version of a service. For example, during an Argo Rollout, operators could gradually increase the traffic weight directed to the new version without requiring any changes on the client side (clients continue to publish requests to the same subject).
Proposed Functionality:
Connection Pause/Resume like Support pausing and resuming consumers but for core NATS:
Enable a connection mode where an application can create all subscriptions upon startup but “pause” message delivery from the NATS server until explicitly resumed.
This feature would help ensure that a service does not start processing traffic before it is fully initialized and ready.
Weighted Routing/Connections:
Allow configuration of weight values for individual connections or subscriptions within the same NATS cluster.
This would enable a gradual rollout (canary deployment) scenario where, for instance, the new version of a service could initially receive a small percentage (e.g., 10%) of the traffic, while the stable version receives the rest.
Over time, these weights could be adjusted to gradually shift more traffic to the new version.
Use case
When deploying an update via Argo Rollout in Kubernetes, a new pod can start up and create all necessary subscriptions on the shared NATS cluster while keeping its connection paused. Once readiness checks pass, an operator (or an automated process) gradually resumes message processing by assigning a low weight (e.g., 10%) to the new version. As confidence in the new version increases, the weight can be increased step by step until it eventually reaches 100%, and the old version is phased out.
Contribution
No response
The text was updated successfully, but these errors were encountered: