On tar(1) command line, `--recursion` and `--no-recursion` are
applicable to directories/files/files list following them, not before
them. Therefore we need to specify the files list (`-T`) after
`--no-recursion`.
Before this change, the default mode was used for everything in the
files list, which is `--recursion`. And because the files list was
listing all directories and files, files were stored multiple times in
the resulting tar archive: once for their entry in the files list and
once for each parent directories.
This fix greatly reduce the size of the source archive: it goes from 7.1
MiB to 2.4 MiB for the xz-compressed tar.
In is_clustered_with(), commands that we run to check if the node is
clustered with us, or partitioned with us may fail. When they fail, it
actually doesn't tell us anything about the remote node.
Until now, we were considering such failures as hints that the remote
node is not in a sane state with us. But doing so has pretty negative
impact, as it can cause rabbitmq to get restarted on the remote node,
causing quite some disruption.
So instead of doing this, ignore the error (it's still logged).
There was a comment in the code wondering what is the best behavior;
based on experience, I think preferring stability is the slightly more
acceptable poison between the two options.
Adm should be group owner of everything in /var/log according to Debian/Ubuntu guidelines. Makes it possible for users in the adm group to read logs without sudo:ing.
It may happen that two nodes have the same start time, and one of these
is the master. When this happens, the node actually gets the same score
as the master and can get promoted. There's no reason to avoid being
stable here, so let's keep the same master in that scenario.
(cherry picked from commit 62a4f75611)
(cherry picked from commit 861f2a57f916a9829e9a11092ada2bb52bdaf028)
Right now, every time we get a start notification, all nodes will ensure
the rabbitmq app is started. This makes little sense, as nodes that are
already active don't need to do that.
On top of that, this had the sideeffect of updating the start time for
each of these nodes, which could result in the master moving to another
node.
If there's nothing starting and nothing active, then we do a -z " ",
which doesn't have the same result as -z "". Instead, just test for
emptiness for each set of nodes.
It may happen that two nodes have the same start time, and one of these
is the master. When this happens, the node actually gets the same score
as the master and can get promoted. There's no reason to avoid being
stable here, so let's keep the same master in that scenario.
mix(1) doesn't seem to provide a nice way to provide dependencies'
sources ourselves. The "solution" is to override HOME and set it to
$(DEPS_DIR), call mix `deps.get` and remove the fetched dependencies.
The goal is to populate the Hex cache and bundle it in the source
archive. No worries, you can thank me later.
Later, when we build the source archive, we override HOME again to point
mix(1) to the Hex cache: it is now happy to "fetch" dependencies. This
part is managed by `rabbitmq-mix.mk` which is copied `rabbitmq-mix.mk`
from rabbit_common to the Elixir components (e.g. rabbitmq_cli) in the
source archive.
References rabbitmq/rabbitmq-server-release#61.
[#153358632]
... under the server-release/scripts/upgrade subdirectory.
The testsuite will remain standalone, i.e. usable outside of CI. The
reason it is moved out of rabbitmq-server-release is that this
repository is dedicated to release building files only. Furthermore this
repository is tagged.
Jean-Sébastien Pédron
Michael Klishin
Jean-Sébastien Pédron
Luke Bakken
Diana Corbacho
Vincent Untz
Carl Hörberg
RabbitMQ CI
Luke Bakken
Daniil Fedotov
Daniil Fedotov