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
So that e.g. queue limits can be enforced while retaining the ability of users to define their own policies. This is primarily relevant in hosted RabbitMQ scenarios.
Current thinking on how this should work is the following:
A new ctl command, rabbitmqctl set_operator_policy_override, that works almost like rabbitmqctl set_policy but only supports a subset of queue keys (see below)
Operator policy definitions are merged into "user policy" definitions (see below)
Operator policies are not global and scoped per vhost, the same way it currently works for "user policies"
There can be cases when operator policies can affect application semantics if we simply replace the user provided value. Consider the following:
A user policy sets max queue length to 10
An operator policy sets max queue length to 1000
Semantically an app assumes there can be no more than 10 messages enqueued at any given moment
We already faced a similar decision when implementing per-message TTL. If there are two TTL values in effect (one for the queue and one for the message), we pick the lower value. Our team
believes the same idea should work well for queue length limits.
Therefore, the idea with policy type merging is this:
Only support a subset of policy-defined optional queue arguments: message-ttl, expires, max-length, and max-length-bytes.
When merging, pick the lower value.
Since the idea with operator policy overrides is usually limit the amount of resources that can be consumed by a vhost (e.g. for tiered pricing in hosted services), this subset should be enough. We can gradually expand the list as we come up with more reasonable and safe ways to merge values.
The text was updated successfully, but these errors were encountered:
So that e.g. queue limits can be enforced while retaining the ability of users to define their own policies. This is primarily relevant in hosted RabbitMQ scenarios.
Current thinking on how this should work is the following:
rabbitmqctl set_operator_policy_override
, that works almost likerabbitmqctl set_policy
but only supports a subset of queue keys (see below)There can be cases when operator policies can affect application semantics if we simply replace the user provided value. Consider the following:
We already faced a similar decision when implementing per-message TTL. If there are two TTL values in effect (one for the queue and one for the message), we pick the lower value. Our team
believes the same idea should work well for queue length limits.
Therefore, the idea with policy type merging is this:
message-ttl
,expires
,max-length
, andmax-length-bytes
.Since the idea with operator policy overrides is usually limit the amount of resources that can be consumed by a vhost (e.g. for tiered pricing in hosted services), this subset should be enough. We can gradually expand the list as we come up with more reasonable and safe ways to merge values.
The text was updated successfully, but these errors were encountered: