Make sure rabbitmq set up properly and test env allows reproducibility

[ikavgo]

See rabbitmq/cluster-operator#959

Unfortunately docker doesn't give enough isolation/reproducability and kernel's fs.max-fds makes into containers. Which means our tests/samples can't run on arbitrary systems - i.e. test env not sealed. Please take a look inside linked operator issue.

TODO: Let's decide what are the good values for samples and performance cluster.

cc @coro

Changes

• 🐛 Limit ERL_MAX_PORTS explicitly, since host's fs.fd-max leaks into containers.

/kind bug

Release Note

Limit ERL_MAX_PORTS explicitly in tests, since host's fs.fd-max leaks into containers. the values provided in samples might be too concervative, please adjust to the taste. 

[codecov]

Codecov Report

Merging #825 (6173c52) into main (ef40a92) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #825   +/-   ##
=======================================
  Coverage   71.71%   71.71%           
=======================================
  Files          40       40           
  Lines        2599     2599           
=======================================
  Hits         1864     1864           
  Misses        667      667           
  Partials       68       68           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ef40a92...6173c52. Read the comment docs.

[coro]

This change looks correct from the operator's point of view, and is the workaround that we recommend in rabbitmq/cluster-operator#959. We can't prevent the host from leaking into the RabbitMQ Pods on an operator level, so it's down to the user to limit the max ports on their system via the very widely-used override interface.

[gabo1208]

Also:

• test/e2e/config/rabbitmqvhost
• test/performance source and brokers
• samples/

should be updated right? and the .mds so the user have a doc reference on why this (?)

[ikavgo]

Added more. Decided to keep performance tests as is, since 1) they work 2) it's hard to predict what makes sense here, since folks likely would want to play with concurrency parameter.

[gab-satchi]

/lgtm

[knative-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: gab-satchi, ikvmw

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [gab-satchi,ikvmw]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment