Assert that quorum queues are always durable and non-autodelete on initialization

[Ayanda-D]

Proposed Changes

Hi folks, the code path for QQ declaration in start_cluster/1 can make it seem like durability is variable (i.e. check is already done by rabbit_queue_type_util:check_non_durable/1). Just adding this assertion/cosmetic change to make things a bit more clear that Durable is always true.

Types of Changes

What types of changes does your code introduce to this project?
Put an x in the boxes that apply

• Bug fix (non-breaking change which fixes issue #NNNN)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause an observable behavior change in existing systems)
• Documentation improvements (corrections, new content, etc)
• Cosmetic change (whitespace, formatting, etc)
• Build system and/or CI

Checklist

Put an x in the boxes that apply.
You can also fill these out after creating the PR.
If you're unsure about any of them, don't hesitate to ask on the mailing list.
We're here to help!
This is simply a reminder of what we are going to look for before merging your code.

• I have read the CONTRIBUTING.md document
• I have signed the CA (see https://cla.pivotal.io/sign/rabbitmq)
• I have added tests that prove my fix is effective or that my feature works
• All tests pass locally with my changes
• If relevant, I have added necessary documentation to https://github.com/rabbitmq/rabbitmq-website
• If relevant, I have added this change to the first version(s) in release-notes that I expect to introduce it

Further Comments

If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution
you did and what alternatives you considered, etc.

[Ayanda-D]

Likewise AutoDelete = false, checked in rabbit_queue_type_util:check_auto_delete/1.

[michaelklishin]

@Ayanda-D before we can accept this contribution, can you please ask your employer to sign our CLA? Thanks.

[Ayanda-D]

@michaelklishin ok, I sent to the relevant people. waiting for feedback (not sure how long it'll take 👀 ).

cc: @willhoy @mlongob

[michaelklishin]

@Ayanda-D sure, I understand that it will take some time.

Fortunately, it has to be done once per company, not once per employee.

[justaugustus]

@Ayanda-D before we can accept this contribution, can you please ask your employer to sign our CLA? Thanks.

[Bloomberg Open Source Program Office here]

Hey @michaelklishin — can you confirm the instructions for signing the CLA?

• https://github.com/rabbitmq/cla makes reference to teamrabbitmq [at] gmail dot com
• the PR template suggests https://cla.pivotal.io/sign/rabbitmq, which [no longer] routes anywhere
• the CLA itself makes mention of opensource [at] broadcom dot com

In all likelihood, we have previously signed a Pivotal CCLA. Could you confirm if that qualifies here?
Feel free to reach out to me either here or at opensource [at] bloomberg dot net.

[michaelklishin]

@justaugustus the PR template is out of date. Please use https://github.com/rabbitmq/cla.

As for opensource [at] broadcom, we don't yet know how legal would prefer us to collect the signed documents, so I've specified our team's address that is publicly available (Broadcom mailing lists are often not, sadly).

We will pass the signed document to legal one way or another.

[justaugustus]

Sounds good, @michaelklishin! We'll keep you posted.

---

Opened an issue for fixing the stale CLA instructions: #14327

[michaelklishin]

@justaugustus I don't know if this piece of news can speed up the process but we now have an alternative: if you email teamrabbitmq </> gmail, we can send you a document link for signing with Box Sign.

Once you do, the document will be automatically moved on our end and we will be notified.

Let me know if you'd prefer to try to option. I am yet to document it because it's has barely been approved after being developed a few weeks ago :)