This undocumented key used to use a simple date-based
formula and used to help support and the core
team.
Nodes no longer have the context to return
a correct response, so all we can do is drop this
key.
In a mixed cluster environment,
'rabbitmq-diagnostics status' can hit a node
that does not return any node tags.
Be more defensive and handle such cases
by simply displaying "(none)" for such
values.
[Why]
The previous implementation bypassed the deprecated features subsystem.
It only cared about classic mirrored queues and called some
queue-related code directly to determine if this specific feature was
used.
[How]
The command code is simplified by calling the deprecated subsystem to
list used deprecated features instead.
References #12619.
--experimental is no longer particularly fair to Khepri,
which is not enabled by default because of its enormous
scope, and because once enabled, it cannot be disabled.
--opt-in would be a better name but --experimental
remains for backwards compatiblity.
When both are specified, we consider that the
user opts in if at least one of the flags is
set to true.
When khepri_db feature flag is disabled, Khepri servers
are running but are not clustered. In this case `rabbit_khepri:status/0`
shows that all nodes are leaders, which is confusing and scary
(even though actually harmless). Instead, we now just print that mnesia
is in use.
With the prior behavior it can be unclear whether the text was a warning
and the feature flag was enabled anyways. We can use a non-zero exit
code and the `{:error, code, text}` return value to make it clear that
the flag wasn't enabled.
'ctl encode' is unfortunately name and targets
advanced.config commands.
This introduce a command that targets 'rabbitmq.conf'
values and has a more specific name.
Eventually 'ctl encode' will be aliased and deprecated,
although we still do not have an aliasing mechanism
and it won't be in scope for 4.0.
Make `check_if_node_is_mirror_sync_critical` a no-op
with a deprecation warning. Since this command is commonly used
as part of the node shutdown process (eg. by Cluster Operator),
making it a no-op instead of removing completly will make the
transition to 4.0 easier for users.
The FD limits are still valuable.
The FD used will still show some information during CQv1
upgrade to v2 so it is kept for now. But in the future
it will have to be reworked to query the system, or be
removed.
Stats were not removed, including management UI stats
relating to FDs.
Web-MQTT and Web-STOMP configuration relating to FHC
were not removed.
The file_handle_cache itself must be kept until we
remove CQv1.
Since commit c0187ec15 the value of `running_version` is converted
to_string (`nil` would become the empty string). But the formatter
expected `running_version` to be `nil` if the plugin is not
running. This did not match and not running/not enabled plugins were
marked incorrectly as "pending upgrade to...".
For example:
```
$ rabbitmq-plugins list trust -q
[ ] rabbitmq_trust_store (pending upgrade to 3.13.0+51.g9145b53)
$ rabbitmq-plugins list trust --formatter erlang -q
#{status => running,format => normal,
plugins =>
[#{enabled => not_enabled,name => rabbitmq_trust_store,running => false,
version => <<"3.13.0+51.g9145b53">>,running_version => <<>>}]}
```
In the rabbitmqctl docs for list_unresponsive_queues, `type` is listed as
a queueinfoitem parameter, but this is not reflected in the source code.
This commit adds `type` as a queueinfoitem parameter for list_unresponsive_queues.
the original paths, e.g. /streams.html, do have redirects
in place but it turned out to be a surprisingly fragile
Cloudflare feature when there are hundreds of them,
so we better switch now.
* Remove unused aliases/imports
* Remove or underscore unused bindings
* Fix variables that should be atoms (`unavailable` -> `:unavailable`)
Also, `Logger.warn/1` has been replaced by `Logger.warning/1`. It should
be safe to just replace the call with `Logger.warning/1` since it's
been in the standard library since Elixir 1.11.