Add ability to set default vhost limits by pattern

[illotum]

Proposed Changes

A fairly straightforward implementation of #4999. Per ticket, vhost limit defaults can be set up with regex patterns in config, and the first matching is applied during vhost creation. Defaults come from a file and are not synced between cluster members.

Unlike the ticket, I do not allow negative limits in favor of omission.

Types of Changes

• 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

• 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

This change is not documented, nor added to release-notes. LMK if this needs to be addressed.

Before I'm happy with it, several concerns and questions:

• I'll admit I'm confused about the two places to store VHost limits: the record and the runtime params. Is one deprecated?
• In my manual tests validators didn't error nor log anything on bad config inputs. Any advice?

[illotum]

Right, I see I failed to follow the breadcrumbs deep enough. Let me fix the snippets.

[illotum]

This time it feels like flaky tests.

[michaelklishin]

@rin and I have noticed a genuine failure on this branch:

bazel test --config=local //deps/rabbitmq_management:rabbit_mgmt_rabbitmqadmin_SUITE

fails with

=== Ended at 2022-10-19 08:47:05
=== Location: [{rabbit_mgmt_rabbitmqadmin_SUITE,parameters,319]},
              {test_server,ts_tc,1782},
              {test_server,run_test_case_eval1,1291},
              {test_server,run_test_case_eval,1223}]
=== === Reason: no match of right hand side value 
                 {ok,[["test","good","/","123"],
                      ["vhost-limits","limits","/"]]}
  in function  rabbit_mgmt_rabbitmqadmin_SUITE:parameters/1 (rabbit_mgmt_rabbitmqadmin_SUITE.erl, line 319)

so the HTTP API response must have changed but the test hasn't.

[michaelklishin]

There is also a CLI suite test failure:

bazel test --config=local //deps/rabbitmq_cli:all

SetParameterCommandTest [test/ctl/set_parameter_command_test.exs]
  * test banner [L#133]
  * test banner (0.4ms) [L#133]
  * test run: an invalid component_name returns a validation failed error [L#88]
  * test run: an invalid component_name returns a validation failed error (1.8ms) [L#88]

  1) test run: an invalid component_name returns a validation failed error (SetParameterCommandTest)
     test/ctl/set_parameter_command_test.exs:88
     Assertion with == failed
     code:  assert list_parameters(context[:vhost]) == []
     left:  [[component: "vhost-limits", name: "limits", value: "[]"]]
     right: []
     stacktrace:
       test/ctl/set_parameter_command_test.exs:96: (test)

--max-failures reached, aborting test suite
Finished in 228.4 seconds (14.6s async, 213.7s sync)
642 tests, 1 failure

[illotum]

Addressed comments, squashed & rebased.

[michaelklishin]

The example in the commit uses default_limits.vhosts. but the actual schema uses default_limits.vhost. which has resulted some head scratching on my end.

I will rename "vhosts" to be plural because this is a collection.

[michaelklishin]

I have also noticed that if there are multiple patterns that match, the effective one is picked undeterministically. I suspect that it depends on collection iteration ordering. There are
other places in RabbitMQ that works this way, namely policies with equal priorities.

[illotum]

I could sort them, e.g. by the pattern hash, if you think it's worth it.

I feel the config file mismatch (between instances) makes this a minor issue by comparison.

[illotum]

I had two extra questions in the description: most importantly, I was able to boot with config values that violate cuttlefish validators. Should I file a separate issue?

[michaelklishin]

If you can reproduce this outside of RabbitMQ, then sure. Cuttlefish is at Kyorai/cuttlefish.