Support for SAC definitions in policy about discussions

[pbillen]

Right. I did not take into account that policies are strictly used for features which can be safely undone. I can see why SAC does not fall into that group.
Thank you for your feedback & documentation addition.

[michaelklishin]

Thank you for your time.

Team RabbitMQ uses GitHub issues for specific actionable items engineers can work on. GitHub issues are not used for questions, investigations, root cause analysis, discussions of potential issues, etc (as defined by this team).

We get at least a dozen of questions through various venues every single day, often light on details.
At that rate GitHub issues can very quickly turn into a something impossible to navigate and make sense of even for our team. Because GitHub is a tool our team uses heavily nearly every day, the signal/noise ratio of issues is something we care about a lot.

Please post this to rabbitmq-users.

Thank you.

[michaelklishin]

Policies are not supproted by features that are impossible to "undo" at runtime, e.g. priority queues use a different on disk layout, queue type is not something that can be changed for an existing queue, and so on.

@acogoluegnes @kjnilsson does SAC have similar aspects to it?

[michaelklishin]

There are no policy definitions used in the test suite, so this increasingly looks like not a coincidence.

[acogoluegnes]

I think we discussed this topic already and came to the conclusion that it may not be such a good idea, as SAC is usually used when messages must be processed in the same order they arrive in the queue. Being able to disable SAC on some running queues could then be a disaster. This would also complicate the implementation.

This basically fits the definition of features that are impossible to "undo" at runtime.

I can add a note in the documentation about this.