summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Logging: Add `single_line` flag support to $RABBITMQ_LOGenable-single_line-logging-from-env-varJean-Sébastien Pédron2021-08-243-4/+18
| | | | | | | | | | | | | A user could already enable single-line logging (the `single_line` option of `logger_formatter` or RabbitMQ internal formatters) from the configuration file. For example: log.console.formatter.single_line = on With this patch, the option can be enabled from the `$RABBITMQ_LOG` environment variable as well: make run-broker RABBITMQ_LOG=+single_line
* Merge pull request #3333 from ↵Michael Klishin2021-08-243-6/+92
|\ | | | | | | | | rabbitmq/mk-definition-import-of-vhost-with-metadata Correctly import virtual host metadata
| * Commit definition import case16 fileMichael Klishin2021-08-241-0/+58
| |
| * Definition import: correctly import vhost metadataMichael Klishin2021-08-242-6/+34
| |
* | Merge pull request #3332 from ↵Michael Klishin2021-08-231-1/+1
|\ \ | |/ |/| | | | | rabbitmq/dependabot/github_actions/lewagon/wait-on-check-action-1.0.0 Bump lewagon/wait-on-check-action from 0.2 to 1.0.0
| * Bump lewagon/wait-on-check-action from 0.2 to 1.0.0dependabot[bot]2021-08-231-1/+1
|/ | | | | | | | | | | | | | Bumps [lewagon/wait-on-check-action](https://github.com/lewagon/wait-on-check-action) from 0.2 to 1.0.0. - [Release notes](https://github.com/lewagon/wait-on-check-action/releases) - [Commits](https://github.com/lewagon/wait-on-check-action/compare/v0.2...1.0.0) --- updated-dependencies: - dependency-name: lewagon/wait-on-check-action dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
* Update a mock expectationMichael Klishin2021-08-211-2/+2
|
* rabbitmq_aws: drop trailing dot in some log messagesMichael Klishin2021-08-211-5/+5
|
* Started using function headsBilal Acar2021-08-212-7/+7
|
* Addressing PR commentsBilal Acar2021-08-211-5/+5
|
* Adding retries to AWS API callsBilal Acar2021-08-213-3/+34
| | | Adding retries to AWS API calls
* Don't run #3319 assertions in mixed version clustersMichael Klishin2021-08-191-20/+26
|
* Merge pull request #3328 from ↵Michael Klishin2021-08-193-3/+3
|\ | | | | | | | | rabbitmq/dependabot/github_actions/erlef/setup-beam-1.9 Bump erlef/setup-beam from 1.8 to 1.9
| * Bump erlef/setup-beam from 1.8 to 1.9dependabot[bot]2021-08-193-3/+3
|/ | | | | | | | | | | | | | Bumps [erlef/setup-beam](https://github.com/erlef/setup-beam) from 1.8 to 1.9. - [Release notes](https://github.com/erlef/setup-beam/releases) - [Commits](https://github.com/erlef/setup-beam/compare/v1.8...v1.9) --- updated-dependencies: - dependency-name: erlef/setup-beam dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
* Merge pull request #3324 from ↵Michael Klishin2021-08-192-2/+27
|\ | | | | | | | | rabbitmq/fix-race-condition-in-connection-channel-tracking-list-function rabbit_{connection,channel}_tracking: Fix race condition in list()
| * rabbit_{connection,channel}_tracking: Fix race condition in list()Jean-Sébastien Pédron2021-08-192-2/+27
|/ | | | | | | | The table might not exist yet (or is already gone) between the time rabbit_nodes:all_running() runs and returns a specific node, and mnesia:dirty_match_object() is called for that node's table. This seems to happen frequently in CI.
* Merge pull request #3319 from ↵Michael Klishin2021-08-183-3/+59
|\ | | | | | | | | rabbitmq/mk-http-api-put-vhost-updates-tags-and-description Make PUT /api/vhosts/{name} update tags and/or description for existing virtual hosts
| * Make PUT /api/vhosts/{name} update tags and/or descriptionmk-http-api-put-vhost-updates-tags-and-descriptionMichael Klishin2021-08-183-3/+59
|/
* Update 3.9.4.mdMichael Klishin2021-08-181-1/+1
|
* Merge pull request #3312 from rabbitmq/alarms-metric1Michael Klishin2021-08-173-1/+91
|\ | | | | Expose alarms as Prometheus metrics
| * Change metric names in release notes tooIliia Khaprov2021-08-171-2/+2
| |
| * Prometheus: alarm-related metric namingMichael Klishin2021-08-171-4/+4
| |
| * Add alarms prometheus collector.Ilya Khaprov2021-08-163-1/+91
| | | | | | | | close #2653
* | Merge pull request #3311 from rabbitmq/rabbitmq-server-3249Michael Klishin2021-08-177-61/+596
|\ \ | |/ |/| Definition import: allow for arbitrary (and pluggable) sources
| * 3.9.4 release notes wordingMichael Klishin2021-08-171-2/+3
| |
| * Introduce TLS-related rabbitmq.conf settings for definition importMichael Klishin2021-08-175-6/+207
| | | | | | | | | | currently only used by the HTTPS mechanism but can be used by any other.
| * Refactor definition import to allow for arbitrary sourcesMichael Klishin2021-08-147-58/+391
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The classic local filesystem source is still supported using the same traditional configuration key, load_definitions. Configuration schema follows peer discovery in spirit: * definitions.import_backend configures the mechanism to use, which can be a module provided by a plugin * definitions.* keys can be defined by plugins and contain any keys a specific mechanism needs For example, the classic local filesystem source can now be configured like this: ``` ini definitions.import_backend = local_filesystem definitions.local.path = /path/to/definitions.d/definition.json ``` ``` ini definitions.import_backend = https definitions.https.url = https://hostname/path/to/definitions.json ``` HTTPS may require additional configuration keys related to TLS/x.509 peer verification. Such extra keys will be added as the need for them becomes evident. References #3249
* Merge pull request #3309 from rabbitmq/mk-3.9.4-release-notesMichael Klishin2021-08-131-0/+33
|\ | | | | Initial 3.9.4 release notes
| * Initial 3.9.4 release notesMichael Klishin2021-08-131-0/+33
|/
* Merge pull request #3299 from ↵Michael Klishin2021-08-114-4/+157
|\ | | | | | | | | rabbitmq/add-env-vars-to-set-default-user-pass-vhost-and-erlang-cookie Add support to override `default_{user,pass,vhost}` and the Erlang cookie from the environment
| * Log a warning when Erlang cookie is overriden using an env variableMichael Klishin2021-08-111-2/+2
| | | | | | | | as it can be really difficult to troubleshoot such cookie changes
| * Add support for $RABBITMQ_ERLANG_COOKIE env varJean-Sébastien Pédron2021-08-111-1/+17
| | | | | | | | | | | | | | | | | | | | It is the equivalent of the content of the Erlang cookie file. Note this variable IS the cookie value, NOT the path to a cookie file. If it is set, it will take precedence over the content of the Erlang cookie file. Fixes docker-library/rabbitmq#508.
| * Add support for $RABBITMQ_DEFAULT_{USER,PASS,VHOST} env varsJean-Sébastien Pédron2021-08-111-3/+16
| | | | | | | | | | | | | | | | They are the equivalent of the `default_{user,pass,vhost}` configuration settings. Each set environment variable will take precedence over its configuration file counterpart. Fixes docker-library/rabbitmq#508.
| * rabbit_env: Add $RABBITMQ_DEFAULT_{USER,PASS,VHOST} and ↵Jean-Sébastien Pédron2021-08-112-0/+124
| | | | | | | | | | | | | | | | | | $RABBITMQ_ERLANG_COOKIE vars Those environment variables are unset by default. The default values are set in the `rabbit` application environment and can be configured in the configuration file. However, the environment variables will take precedence over them respectively if they are set.
* | Merge pull request #3300 from ↵Jean-Sébastien Pédron2021-08-111-0/+7
|\ \ | |/ |/| | | | | rabbitmq/comment-why-logging-burst-limit-is-disabled Logging: Add comments explaining when burst limit is disabled
| * Logging: Add comments explaining when burst limit is disabledJean-Sébastien Pédron2021-08-111-0/+7
|/ | | | Follow-up to rabbitmq/rabbitmq-server#3298.
* Merge pull request #3298 from ↵Jean-Sébastien Pédron2021-08-111-3/+19
|\ | | | | | | | | rabbitmq/disable-logging-burst-limit-with-debug-level Logging: Disable burst limit if the log level is set to `debug`
| * Logging: Disable burst limit if the log level is set to `debug`Jean-Sébastien Pédron2021-08-111-3/+19
|/ | | | | | | | Otherwise, messages are being dropped, in particular during RabbitMQ startup because of the amount of debug messages logged in that phase. Burst limit is enabled again if the log level is set to `info` or higher.
* Break down metrics by node in all RabbitMQ-Stream pie chartsGerhard Lazu2021-08-111-5/+5
| | | | | | Otherwise we won't be able to see which nodes are running "hot" Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
* Merge pull request #3295 from rabbitmq/lh-test-dropwhile-restart-bugLoïc Hoguin2021-08-111-1/+94
|\ | | | | Add tests for the regression introduced in #3041
| * Add tests for the regression introduced in #3041Loïc Hoguin2021-08-111-1/+94
| |
* | 3.9.3 release notesMichael Klishin2021-08-111-0/+51
| |
* | 3.8.21 release notesMichael Klishin2021-08-111-0/+62
| |
* | Manually apply rabbitmq/rabbitmq-website#1241 by @lushndmMichael Klishin2021-08-111-1/+1
|/
* Merge pull request #3280 from rabbitmq/do-not-report-stopping-state-to-systemdJean-Sébastien Pédron2021-08-102-5/+9
|\ | | | | Do not report stopping state to systemd
| * rabbit_boot_state: Wrap boot_state() type definition lineJean-Sébastien Pédron2021-08-101-1/+5
| | | | | | | | ... to fit in 80 columns.
| * systemd: Enclose status description inside quotesJean-Sébastien Pédron2021-08-101-1/+2
| | | | | | | | ... in the log message.
| * systemd: Do not report "stopping" state to systemdJean-Sébastien Pédron2021-08-101-3/+2
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem is we only know about the state of the `rabbit` Erlang application — when it is started and stopped. But we can't know the fate of the Erlang VM, except if `rabbit:stop_and_halt()` is called. This function is not called if `init:stop()` or a SIGTERM are used for instance. systemd is interested in the state of the system process (the Erlang VM), not what's happening inside. But inside, we have multiple situations where the Erlang application is stopped, but not the Erlang VM. For instance: * When clustering, the Erlang application is stopped before the cluster is created or expanded. The application is restarted once done. This is controled either manually or using the peer discovery plugins. * The `pause_minority` or `pause_if_all_down` partition strategies both stop the Erlang application for an indefinite period of time, but RabbitMQ as a service is still up (even though it is managing its own degraded mode and no connections are accepted). In both cases, the service is still running from the system's service manager's point of view. As said above, we can never tell "the VM is being terminated" with confidence. We can only know about the Erlang application itself. Therefore, it is best to report the latter as a systemd state description, but not reporting the "STOPPING=1" state at all. systemd will figure out itself that the Erlang VM exited anyway. Before this change, we were reporting the "STOPPING=1" state to systemd every time the Elang application was stopped. The problem was that systemd expected the system process (the Erlang VM) to exit within a configured period of time (90 seconds by default) or report that's it's ready again ("READY=1"). This issue remained unnoticed when the cluster was created/expanded because it probably happened within that time frame. However, it was reported with the partition healing strategies because the partition might last longer than 90 seconds. When this happened, the Erlang VM was killed (SIGKILL) and the service restarted. References #3262. Fixes #3289.
* Merge pull request #3283 from rabbitmq/use-colon-as-verbosity_map-separatorJean-Sébastien Pédron2021-08-101-4/+4
|\ | | | | Logging: Use `:` as the separator in verbosity mapping
| * Logging: Use `:` as the separator in verbosity mappingJean-Sébastien Pédron2021-08-101-4/+4
|/ | | | | | This is the same separator as the field mapping. I don't remember why I picked a different character... Now, it feels awkward and non-intuitive for users.
View Lorry Controller Status