Policies containing QQ and CMQ rules are ignored

[adamncasey]

I'm noticing that policies containing definitions relating to both quorum and classic queues do not get applied at all. This is awkward because policies cannot target a specific queue type. Which ultimately makes it impossible to define a vhost with policies for safe-by-default CMQs and QQs.

On RabbitMQ 3.11.6 / Erlang 25.1 I have created the following policies:

rabbitmqctl list_policies output

$ rabbitmqctl list_policies --vhost rmq-vhost
Listing policies for vhost "rmq-vhost" ...
vhost   name    pattern apply-to        definition      priority
rmq-vhost    rmq-vhost-policy-2   qq.*    all     {"dead-letter-strategy":"at-least-once","delivery-limit":5,"max-length-bytes":10485760,"overflow":"reject-publish"}       0
rmq-vhost    rmq-vhost-policy-3   cmq.*   all     {"ha-mode":"all","ha-promote-on-failure":"always","ha-promote-on-shutdown":"always","max-length-bytes":10485760,"overflow":"reject-publish"}      0
rmq-vhost    rmq-vhost-policy     .*      all     {"dead-letter-strategy":"at-least-once","delivery-limit":5,"ha-mode":"all","ha-promote-on-shutdown":"always","ha-sync-mode":"automatic","max-length-bytes":10485760,"overflow":"reject-publish"}  1

To demonstrate this I created four queues with highly imaginative names

1. Quorum Queue named qq.blah - I'd expect this to match policy-2 above, and it does
2. Classic Queue named cmq.blah - I'd expect this to match policy-3 above, and it does.
3. Quorum Queue named blah - I'd expect this to match policy above, but it doesn't.
4. Classic Queue named blahblah - I'd also expect this to match policy above, but it doesn't. Note that in the screenshot below this queue has no mirrors.

It seems to be a problem when policies contain properties for both classic and quorum queues

I feel a more workable strategy here is to ignore parts of policies which are not relevant for this particular queue type.

[michaelklishin]

Oops, a browser crash has wiped out my long comment.

There are two types of validation performed on policies:

• Types of values of known keys
• Whether all keys are known

My best guess is that now the latter is performed by individual queue types. I'd expect log messages about this.

There is no such thing as "safe classic mirrored queues" and they are getting close to being removed, so I don't know how much sense it would make to change this many years old behavior of the second "type" of validation.

[mkuratczyk]

Targeting policies by queue type is something that we are interested in adding. @adamncasey would you be happy with such a solution for this use case?

Policy matching on queue-type discussion: #6217

[adamncasey]

Yes, having a policy per queue type would solve this problem for us.

Ignoring policy keys which are unknown also seems reasonable to me, but I might not have the full picture

[mkuratczyk]

Targeting policies at specific queue types will be possible in 3.12: #7601

[aaron-seo]

Reviving this discussion thread for sake of context (happy to move to a separate discussion, if preferred): what is the team's thoughts on the current state of validation for "Whether all keys are known"? As noted by @michaelklishin, it seems this validation is being performed by queues, and not at policy-creation.

Personally, I think it would be a better UX if we disallowed creation of policies with "unknown keys" for a particular queue type.

I.e. a policy with apply-to: quorum_queues should not be allowed to be created with ha-mode keys.

If the team tends to agree with that, and it's just been a low-priority task, I'd be happy to take a shot at it.

[SimonUnge]

What would be the UX experience for apply-to: all?

[aaron-seo]

IMO, ideally, if a policy has apply-to: all (or queues for that matter) and has both quorum-and-classic-specific keys, I think Rabbit should be able to assign those queue_type-specific keys accordingly and also apply queue_type-generic keys to both queue_types. (naive look: a queue looks at a policy and filters out those keys that doesn't apply to its type).

My thought rn is that the proposed validation at policy-creation should only be involved with apply-to values quorum_queues, classic_queues, and streams (perhaps even exchanges?).

Although, this would leave us in a world where policy-related validation is happening at both policy and queue layers; if that's a worry or not, not too sure tbh. And i'm also unaware if there are caveats that those more familiar with the codebase might be aware of.