| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Separate workflows for min & max supported OTP version
- Multiple groups for clustering_management (run in parallel & finish quicker)
- Store CT logs as artefacts on failure
- Tests badge in README
- Store in S3 the version of the RabbitMQ components used while testing
We have decided to not not run tests for RabbitMQ components that we
depend on: rabbitmq-cli, rabbitmq-erlang-client & rabbitmq-common.
rabbitmq-cli & rabbitmq-erlang-client depend on rabbitmq-server
(recursive dependency) meaning that they will clone rabbitmq-server
again, inside the deps dir. We will continue to run these in Concourse,
until we merge all repositories into a single one. Let's be honest, it's
a monolith!
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A large part of the rabbitmq-server(8) and CLI scripts, both
Bourne-shell and Windows Batch versions, was moved to Erlang code and
the RabbitMQ startup procedure was reorganized to be closer to a regular
Erlang application.
A new application called `rabbitmq_prelaunch` is responsible for:
1. Querying the environment variables to initialize important
variables (using the new `rabbit_env` module in rabbitmq-common).
2. Checking the compatibility with the Erlang/OTP runtime.
3. Configuring Erlang distribution.
5. Writing the PID file.
The application is started early (i.e. it is started before `rabbit`).
The `rabbit` application runs the second half of the prelaunch sequence
at the beginning of the application `start()` function. This second
phase is responsible for the following steps:
1. Preparing the feature flags registry.
2. Reading and validating the configuration.
3. Configuring logging.
4. Running the various cluster checks.
In addition to this prelaunch sequence, the `rabbit` application start
procedure ends with a "postlaunch" sequence which takes care of
starting enabled plugins.
Thanks to this, RabbitMQ can be started with `application:start(rabbit)`
as any other Erlang application. The only caveats are:
* Mnesia must be stopped at the time `rabbit_prelaunch` is started,
and must remain stopped when `rabbit` is started, to allow the
Erlang distribution setup and cluster checks. `rabbit` takes care of
starting Mnesia.
* Likewise for Ra, because it relies on the `ra` application
environment to be configured.
Transitioning from scripts to Erlang code has the following benefits:
* RabbitMQ start behavior should be identical between Unix and
Windows. Also, features should be on par now. For instance, RabbitMQ
now writes a PID file on Windows, like it always did on Unix-based
systems.
* The difference between published packages and a development
environment are greatly reduced. In fact, we removed all the "if
this is a dev working copy, then ..." blocks.
As part of that, the `rabbit` application is now treated like its
plugins: it is packaged as an `.ez` archive and written to the
`plugins` directory (even though it is not technically a plugin).
Also in a development copy, the CLI is copied to the top-level
project. So when testing a plugin for instance, the CLI to use is
`sbin/rabbitmqctl` in the current directory, not the master copy in
`rabbit/scripts`.
* As a consequence of the previous two points, maintaining and testing
on Windows is now made easy. It should even be possible to setup CI
on Windows.
* There are less issues with paths containing non-US-ASCII characters,
which can happen on Windows because RabbitMQ stores its data in user
directories by default.
This process brings at least one more benefit: we now have early logging
during this prelaunch phase, which eases diagnostics and debugging.
There are also behavior changes:
* The new format configuration files used to be converted to an
Erlang-term-based file by the Cuttlefish CLI. To do that,
configuration schemas were copied to a temporary directory and the
generated configuration file was written to RabbitMQ data directory.
Now, Cuttlefish is used as a library: everything happens in memory.
No schemas are copied, no generated configuration is written to
disk.
* The PID file is removed when the Erlang VM exits.
* The `rabbit_config` module was trimmed significantly because most of
the configuration handling is done in `rabbit_prelaunch_conf` now.
* The RabbitMQ nodename does not appear on the command line, therefore
it is missing from ps(1) and top(1) output.
* The `rabbit:start()` function will probably behave differently in
some ways because it defers everything to the Erlang application
controller (instead of reimplementing it).
|
| |\
| |
| |
| |
| |
| | |
Conflicts:
src/rabbit_queue_location_random.erl
test/queue_master_location_SUITE.erl
|
| | |
| |
| |
| | |
pids are started
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Writing those manpages directly in the target markup language allows to
use its full expressiveness, unlike the generated output from DocBook.
To create their HTML versions, we use mandoc(1), plus a small awk script
to adapt the generated HTML to our needs. I tried groff(1) and
man2html(1) but the former transforms nearly everything to simple <p>
and the later tries to reproduce the rendering of a manpage in a
terminal.
Manpages in section 1 are moved to section 8 because they are commands
to manage a system service, not general purpose commands.
This commits requires a change in the website to integrate the new
generated HTML manpages.
[#143563295]
|
| |\ \
| |/
| |
| |
| |
| |
| |
| | |
Conflicts:
src/rabbit_control_main.erl
src/rabbit_error_logger_file_h.erl
src/rabbit_registry.erl
src/rabbit_sasl_report_file_h.erl
|
| | |
| |
| |
| | |
Signed-off-by: Gerhard Lazu <gerhard@rabbitmq.com>
|
| | | |
|
| | | |
|
| |\ \
| |/ |
|
| | |
| |
| |
| | |
[#130659985]
|
| |\ \
| |/ |
|
| | | |
|
| | | |
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The migrated tests are the external ones executed from
`rabbit_tests.erl`:
o credit_flow_test
o gm_tests
o mirrored_supervisor_tests
o on_disk_store_tunable_parameter_validation_test
o password_hashing_tests
o rabbit_ctl_timeout_tests
o rabbit_resource_monitor_misc_test
o supervisor2_tests
o truncate
o vm_memory_monitor_tests
References #725.
[#116526487]
|
| |\ \
| |/ |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
