VMware Tanzu RabbitMQ for Kubernetes release notes include detailed release information for VMware Tanzu RabbitMQ for Kubernetes version 1.2.x, 1.3.x, 1.4.x, 1.5.x, and 3.13.x releases.
VMware Tanzu RabbitMQ for Kubernetes software is available for download from the Broadcom Support Portal. For instructions, go to Access the VMware Tanzu RabbitMQ for Kubernetes Docker Images.
Important Notes before Continuing
The current VMware Tanzu RabbitMQ for Kubernetes release is 3.13 (the latest patch release is 3.13.3). For users who are currently using 1.5 releases, note that 3.13 is the next release after 1.5. This is different from the expectation that the next release would be 1.6. The reason for this change is to align product version numbers between open source RabbitMQ and commercial VMware Tanzu RabbitMQ product versions.
VMware Tanzu RabbitMQ for Kubernetes was formerly known as VMware RabbitMQ for Kubernetes. To avoid confusion, all releases listed in this release notes information are referred to using the current product offering name VMware Tanzu RabbitMQ for Kubernetes. If the specific release that you are using is called VMware RabbitMQ for Kubernetes and it is referred to as VMware Tanzu RabbitMQ for Kubernetes in these release notes, note that this is the same product offering, it's naming has just varied over time.
You can also avail of documentation for the Open Source RabbitMQ product. As the Tanzu RabbitMQ for Kubernetes product offering is built from the open source RabbitMQ product, open source RabbitMQ documentation is a core part of the Tanzu RabbitMQ for Kubernetes offering documentation. When you are using this Tanzu RabbitMQ for Kubernetes documentation, you will be redirected to the open source RabbitMQ documentation as required.
VMware Tanzu RabbitMQ for Kubernetes 3.13.3 contains the following packages and changes:
Open-source RabbitMQ version 3.13.2 is a maintenance release in the 3.13.x release series.
For details on the changes in the core broker, CLI tools, Management Plugin, and so on, review the 3.13.2 release notes.
To review the release notes for the entire 3.13.x release series, go to all open-source RabbitMQ release notes and choose the specific version of the release notes that you want.
The main changes are:
ImportantUpgrading the cluster operator to version 2.9.0 causes a rolling update of the underlying StatefulSets. If you want to control when a RabbitMQ cluster gets updated ("updated" here means updating the RabbitMQ cluster resources, it does not mean the RabbitMQ version gets updated), you must pause reconciliation before you upgrade the cluster operator. After the cluster operator upgrade is complete, resume reconciliation whenever it is safe to update the RabbitMQ cluster.
For more details of 2.9.0 changes, review What's Changed.
The main changes are:
if-empty
and if-unused
parameters when you are deleting queues.all
category is removed from the custom resource definitions (CRDs).For more details of 1.14.1 changes, review What's Changed.
The following Warm Standby Replication improvements are now available in the 3.13.3 Tanzu RabbitMQ for Kubernetes release.
rabbitmq.conf
.rabbitmqctl promote_warm_standby command
, which completes all promotion tasks in one step.One of the key features exclusive to this 3.13.3 Tanzu RabbitMQ for Kubernetes release is compliance with the Federal Information Processing Standard (FIPS) 140-2. This compliance provides another level of security to RabbitMQ messaging using OpenSSL 3. Security of financial and governmental systems is essential for organizations. Setting up the correct configuration can be challenging enough without having to setup FIPS compliance (which is built into Erlang) also. Now with the Tanzu RabbitMQ for Kubernetes 3.13.3 release, this FIPS configuration is provided ‘out of the box’.
NoteIf you are using FIPS, you must pull the FIPS variant images from the Broadcom Support Portal. For instructions on how to get those images, go to Install Tanzu RabbitMQ for Kubernetes.
The previous 1.5.x releases of Tanzu RabbitMQ included some significant improvements to the performance of the MQTT (Message Queuing Telemetry Transport) protocol, which is used extensively in IoT applications. For more details, refer to this blog.
RabbitMQ now supports MQTTv5 and significantly more connections per node. MQTT 5.0 provides improved session management, support for user properties, and extended error reporting. More fine-grained control over message properties and behaviors is also supported, which makes it a more versatile and extensible protocol compared to MQTT 3.1.1.
For a deeper dive into MQTT 5.0 support, its specifics with RabbitMQ, and the list of features you can avail of, go through the MQTT 5.0 blog post.
Since the launch of streams in RabbitMQ, there is a steady growth in the adoption of this highly performant message transport mechanism. Streams not only provide the ability to route high volumes of data, they can also be partitioned into topics to make the consumption easier for client applications using super streams. Now in this Tanzu RabbitMQ for Kubernetes 3.13.3 release, users can filter a stream. This feature lightens the load on client applications while at the same time saving network bandwidth. In high throughput message topologies, it is common for microservices to become overburdened and in extreme cases cease to be micro at all. Filtering for streams is very helpful in this type of application. Visit the Stream Filtering documentation for more information.
Message containers are now introduced in the Tanzu RabbitMQ for Kubernetes 3.13.3 release. This change is not obvious to users, it is an internal update in the way messages are handled internally. Why are they introduced? RabbitMQ was originally built as an AMQP 0-9-1 broker. However, over the years, support for AMQP 1.0, MQTT, STOMP, and streams was added, which has led to internal message format conversions since different protocols have mostly similar concepts, but differ in the details such as available data types.
Message containers use the AMQP 1.0 data format. Message containers modernize internal message representation with today's multi-protocol assumptions and makes all the conversions between protocols explicit. Message containers offer greater flexibility for users looking to leverage protocols other than AMQP 0.9.1. Previously all non AMQP 0.9.1 messages were handled via a translation layer which increased the processing overhead and had the potential to lose some metadata. With message containers, messages are wrapped and preserved throughout the routing of Tanzu RabbitMQ and only reconstructed back into their original format when consumed. Metadata is preserved where possible, Obviously if consuming in a different protocol to that which published a message, a compromise in metadata mapped is needed. Integrating event driven architectures across disparate systems can be very complex especially if earlier versions of protocols (such as MQTTv3) are being used. Message containers allow users to consume messages from earlier versions of protocols and integrate them into a more modern microservice architecture without having to rewrite consuming clients from the beginning.
To summarize, message containers have helped Tanzu RabbitMQ for Kubernetes become even more flexible and has the potential to adopt many more protocols in the future.
This 3.13.3 release of Tanzu RabbitMQ for Kubernetes is an important milestone in the roll out plan for a new storage backend for RabbitMQ metadata: Khepri. It is designed to replace the current Mnesia metadata store in a future release. This should significantly improve RabbitMQ's tolerance to network partitions. Once Khepri is in use, there will be no partition handling strategy configuration (pause_minority
, autoheal
, and so on). Just like quorum queues, Khepri is also based on the Raft protocol therefore the semantics of what to do when a partition occurs are well defined and not configurable. In this 3.13.3 release users can try out Khepri but note that Mnesia is still the default metadata store until Khepri is implemented in a future Tanzu RabbitMQ for Kubernetes release.
The memory footprint for the robust quorum queue and conventional classic queues v2 is greatly improved in the VMware Tanzu RabbitMQ for Kubernetes 3.13.3 release. As a result of these improvements, the benefits include better resource efficiency, cost savings, enhanced performance, and greater stability overall.
VMware Tanzu RabbitMQ for Kubernetes 1.5.3 contains the following packages and changes:
Open-source RabbitMQ version 3.12.12 is a maintenance release in the 3.12.x release series.
ImportantThe VMware Tanzu RabbitMQ for Kubernetes 1.5.3 release includes a RabbitMQ version that is based on the RabbitMQ open-source version 3.12.12 so similiar to the previous VMware Tanzu RabbitMQ for Kubernetes 1.5.2, 1.5.1. and 1.5.0 releases, the same scenario applies to feature flags. Open-source RabbitMQ 3.12.x packages require all feature flags from the 3.11.x release series to be turned on before upgrading so you must turn on feature flags now on all the RabbitMQ clusters deployed by the RabbitMQ cluster operator that you want to upgrade from VMware Tanzu RabbitMQ for Kubernetes version 1.4.3. If you are coming from a VMware Tanzu RabbitMQ for Kubernetes version that is before 1.4.3 (such as version 1.4.2) and you want to upgrade to VMware Tanzu RabbitMQ for Kubernetes version 1.5.3, you must upgrade your RabbitMQ clusters to VMware Tanzu RabbitMQ for Kubernetes version 1.4.3 first. To upgrade VMware Tanzu RabbitMQ for Kubernetes versions, go to Upgrading your VMware Tanzu RabbitMQ for Kubernetes Version.
Core Server: Bug Fixes
client_id
that are required during the authentication of MQTT were not passed to the authentication backends used to authenticate the user. As a result, when MQTT users accessed RabbitMQ via the MQTT protocol, they could not login because the client_id
parameter that was used during the authentication to open an MQTT connection was not passed down to the http authentication backend that RabbitMQ uses to authenticate the user. The configured http backend expected the client_id
parameter. This issue should now be resolved. Refer to Github pull request 10230 for more information.Stream Plugin: Bug Fixes
Return expected internal error code in stream metadata lookup: When a RabbitMQ node is unavailable, this fix ensures the metadata stream protocol operation does not fail. Refer to Github pull request 10277 for more information.
Allow MQTT QoS 0 subscribers to reconnect: In the VMware Tanzu RabbitMQ for Kubernetes 1.5.2 release (and previous releases), the following issue existed:
CleanSession=true
and subscribes with QoS=0
. (Internally, RabbitMQ creates a queue with a rabbit_mqtt_qos0_queue
type).QoS=0
.Step 4 fails with a Failed to declare queue <queue name>: {absent, AmqQueue, nodedown}
error message. This issue should now be fixed in this VMware Tanzu RabbitMQ for Kubernetes 1.5.3 release. Clients can re-connect and re-subscribe to a RabbitMQ live node if the original node hosting the MQTT connection crashed. Refer to Github pull request 10244 for more information.
CLI Tools: Bug Fix
Some CLI commands (like rabbitmq-diagnostics observer
) were failing to accept input since this Github pull request was included in the open-source RabbitMQ 3.12.11 release. This issue should now be fixed in the current RabbitMQ 3.12.12 release. Refer to Github pull requests 10270 and 10258 for more information.
Support for Erlang INET configuration was added, and stream ports to inter-node-traffic network-policy were also added. For a full list of 2.7.0 changes, review What's Changed.
For more information about other features and fixes introduced in open-source RabbitMQ 3.12.12, review the release notes or to review release notes for open-source RabbitMQ versions from 3.12.10 (3.12.10 was the RabbitMQ version that was included in the previous VMware Tanzu RabbitMQ for Kubernetes V1.5.2 release) to the current 3.12.12, go here and select the particular release notes version that you want.
VMware Tanzu RabbitMQ for Kubernetes 1.5.2 contains the following packages and changes:
Open-source RabbitMQ version 3.12.10 is a maintenance release in the 3.12.x release series.
ImportantThe VMware Tanzu RabbitMQ for Kubernetes 1.5.2 release includes a RabbitMQ version that is based on the RabbitMQ open-source version 3.12.10 so similiar to the previous VMware Tanzu RabbitMQ for Kubernetes 1.5.1 and 1.5.0 releases, the same scenario applies to feature flags. Open-source RabbitMQ 3.12.x packages require all feature flags from the 3.11.x release series to be turned on before upgrading so you must turn on feature flags now on all the RabbitMQ clusters deployed by the RabbitMQ cluster operator that you want to upgrade from VMware Tanzu RabbitMQ for Kubernetes version 1.4.3. If you are coming from a VMware Tanzu RabbitMQ for Kubernetes version that is before 1.4.3 (such as version 1.4.2) and you want to upgrade to VMware Tanzu RabbitMQ for Kubernetes version 1.5.2, you must upgrade your RabbitMQ clusters to VMware Tanzu RabbitMQ for Kubernetes version 1.4.3 first. To upgrade VMware Tanzu RabbitMQ for Kubernetes versions, go to Upgrading your VMware Tanzu RabbitMQ for Kubernetes Version.
Shovel Plugin Enhancement:
Previously, after upgrading to 3.12.9 from 3.12.6 or an older version, two Shovels were started. Two Shovels running concurrently can still transfer messages but because they act as competing consumers (and publishers), message ordering in the target queue is affected.
Now with this enhancement, if you upgrade from 3.12.6 to a newer version of RabbitMQ such as 3.12.9 or 3.12.10 this scenario no longer occurs. Refer to Github pull request 9965 for more information.
This operator now adds classic queues, quorum queues, and streams types to the list of supported values for the ApplyTo
field of Policy
.
For a full list of 1.12.2 changes, review What's Changed.
For more information about other features and fixes introduced in open-source RabbitMQ 3.12.10, review the release notes or to review release notes for open-source RabbitMQ versions from 3.12.4 (3.12.4 was the RabbitMQ version that was included in the previous VMware Tanzu RabbitMQ for Kubernetes V1.5.1 release) to the current 3.12.10, go here and select the particular release notes version that you want.
VMware Tanzu RabbitMQ for Kubernetes 1.5.1 contains the following packages and changes:
Open-source RabbitMQ version 3.12.4 is a maintenance release in the 3.12.x release series.
ImportantThe VMware Tanzu RabbitMQ for Kubernetes 1.5.1 release includes a RabbitMQ version that is based on the RabbitMQ open-source version 3.12.4 so similiar to the previous VMware Tanzu RabbitMQ for Kubernetes 1.5.0 release, the same scenario applies to feature flags. Open-source RabbitMQ 3.12.x packages require all feature flags from the 3.11.x release series to be turned on before upgrading so you must turn on feature flags now on all the RabbitMQ clusters deployed by the RabbitMQ cluster operator that you want to upgrade from VMware Tanzu RabbitMQ for Kubernetes version 1.4.3. If you are coming from a VMware Tanzu RabbitMQ for Kubernetes version that is before 1.4.3 (such as version 1.4.2) and you want to upgrade to VMware Tanzu RabbitMQ for Kubernetes version 1.5.1, you must upgrade your RabbitMQ clusters to VMware Tanzu RabbitMQ for Kubernetes version 1.4.3 first. To upgrade VMware Tanzu RabbitMQ for Kubernetes versions, go to Upgrading your VMware Tanzu RabbitMQ for Kubernetes Version.
Core Server Bug Fix:
Consumer churn on quorum queues can result in some messages not being delivered to consumers in some cases. This issue mostly affected queue federation links. Refer to Github pull request 9158 for more information.
Management Plugin Bug Fix:
Quorum queue replica management operations over the HTTP API can now be turned off (deactivated). This functionality is useful in environments where replica management is completed by the platform team and tooling, and should not be exposed to cluster users. Refer to Github pull request 9151 for more information.
Federation Plugin Bug Fix:
Queue federation links that connected quorum queues could get stuck (stop transferring messages even when there were no other consumers on the upstream). Refer to Github pull request 9158 for more information.
LDAP Plugin (AuthN/AuthZ Backend) Bug Fix:
Previously, the LDAP plugin did not interpolate values with non-ASCII characters correctly. Refer to Github issue 9059 for more information.
For a full list of 2.5.0 changes, review What's Changed.
For more information about other features and fixes introduced in open-source RabbitMQ 3.12.4, review the release notes or to review release notes for open-source RabbitMQ versions from 3.12.2 to the current 3.12.4, go here and select the version that you want to display its release notes.
VMware Tanzu RabbitMQ for Kubernetes 1.5.0 contains the following packages and changes:
Open-source RabbitMQ version 3.12.2 is a maintenance release in the 3.12.x release series.
ImportantThe VMware Tanzu RabbitMQ for Kubernetes 1.5.0 release includes a RabbitMQ version that is based on the RabbitMQ open-source version 3.12.2. Open-source RabbitMQ 3.12.x packages require all feature flags from the 3.11.x release series to be turned on before upgrading so you must turn on feature flags now on all the RabbitMQ clusters deployed by the RabbitMQ cluster operator that you want to upgrade from VMware Tanzu RabbitMQ for Kubernetes version 1.4.3. If you are coming from a VMware Tanzu RabbitMQ for Kubernetes version that is before 1.4.3 (such as version 1.4.2) and you want to upgrade to VMware Tanzu RabbitMQ for Kubernetes version 1.5.0, you must upgrade your RabbitMQ clusters to VMware Tanzu RabbitMQ for Kubernetes version 1.4.3 first. To upgrade VMware Tanzu RabbitMQ for Kubernetes versions, go to Upgrading your VMware Tanzu RabbitMQ for Kubernetes Version.
Core Server: Bug Fixes
file_handle_cache
operations are now safer when handling non-existent keys. Refer to Github issue 8784 for more information.CLI Tools: Enhancements
A new command, rabbitmqctl deactivate_free_disk_space_monitoring
, can be used to (temporarily or permanently) deactivate free disk space monitoring on a node. To re-activate it, use rabbitmqctl activate_free_disk_space_monitoring
. Refer to Github pull request 8801 for more information.
AMQP 1.0 Plugin: Bug Fixes
AMQP 1.0 clients that try to publish a message in a way that results in that message not being routed anywhere are now notified with a status "released" for that message. Refer to Github issue 7823 for more information.
Prometheus Plugin: Enhancements
undefined
or NaN
by excluding these values from the API endpoint response. Previously, if a metric was not computed for any reason (for example: free disk space monitor was turned off on the node), its value could end up being rendered as undefined
or NaN
, which are two values that Prometheus scrapers cannot handle (for numerical types such as gauges). Refer to Github issue 8740 for more information.Management Plugin: Bug Fixes
Previously, it was not possible to close a table column selection pane on screens with minimal vertical space. Refer to Github issue 8660 for more information.
STOMP Plugin: Bug Fixes
The plugin now enforces a maximum STOMP frame size. Frames larger than the maximum STOMP frame size size are rejected. The default maximum size is 4 MiB. It can be increased or decreased. To increase the maximum supported STOMP frame size to 10 MiB, set the value: stomp.max_frame_size = 10485760
. To decrease the default 4 MiB to 2 MiB, set the value stomp.max_frame_size = 2097152
.
Shovel Plugin: Bug Fixes
Shovel stop when its destination (target) does not exist. Such shovels are then periodically restarted to retry. Refer to Github issue 8697 for more information.
Web MQTT Plugin: Enhancements
It is now possible to opt in to deactivate file handle cache use in the plugin by setting web_mqtt.use_file_handle_cache = false
. Refer to Github pull request 8790 for more information.
Web STOMP Plugin: Enhancements
It is now possible to opt in to deactivate file handle cache use in the plugin by setting web_stomp.use_file_handle_cache = false
. Refer to Github pull request 8790 for more information.
Open Source RabbitMQ 3.12.0 is a new feature release which RabbitMQ 3.12.2 is part of. RabbitMQ 3.12.0 includes new features, optimizations, and also implements functionality where a number of feature flags are now mandatory.
The following lists the user-facing areas that have biggest improvements:
This release also includes many internal API improvements in preparation for the upcoming new major RabbitMQ 4.0 release (coming in the future) with Khepri. For more information, review the 3.12.0 release notes.
ra
was upgraded to 2.6.3
For a full list of 2.4.0 changes, review What's Changed.
Supports custom connect uri through annotation on rabbitmqcluster. For a full list of 1.12.0 changes, review What's Changed.
For more information about other features and fixes introduced in open-source RabbitMQ 3.12.2, review the release notes or to review release notes for open-source RabbitMQ version 3.12.0, which is the new feature release that RabbitMQ 3.12.2 is part of, go here.
VMware Tanzu RabbitMQ for Kubernetes 1.4.5 contains the following packages and changes:
RabbitMQ 3.11.25 is a maintenance release in the 3.11.x release series.
Core Server Bug Fix:
A fix is implemented to handle the autoheal winner_waiting
state with a chosen winner notification received. This solution handles this case in the same way as all other {winner_is, Winner}
messages, it restarts the loser and updates the autoheal state to avoid crashing the node monitor process. Refer to Github pull request 9819 for more information.
Core Server Enhancement:
raft.segment_max_entries
is now validated to prevent the value from overflowing its 16-bit segment file field. Maximum supported value is now 65535
. Refer to Github pull request 9748 for more information.
Shovel Plugin Enhancement:
Much faster Shovel startup in environments where many shovels exist (one thousand or more). Refer to Github pull request 9800 for more information.
AMQP 1.0 Erlang Client Enhancement:
Previously, credentials could be logged in a small number of failure scenarios and only for Shovels that used AMQP 1.0. Now, shovels that use AMQP 1.0 will avoid logging sensitive data in case in certain failure scenarios. Refer to Github pull request 9778 for more information.
This operator now adds classic queues, quorum queues, and streams types to the list of supported values for the ApplyTo
field of Policy
.
For a full list of 1.12.2 changes, review What's Changed.
For more information about other features and fixes introduced in open-source RabbitMQ 3.11.0, review the release notes or to review release notes for open-source RabbitMQ versions from 3.11.22 (3.11.22 was the RabbitMQ version that was included in the previous VMware Tanzu RabbitMQ for Kubernetes V1.4.4 release) to the current 3.11.25, go to here and select the particular release notes version that you want.
VMware Tanzu RabbitMQ for Kubernetes 1.4.4 contains the following packages and changes:
RabbitMQ 3.11.22 is a maintenance release in the 3.11.x release series.
Management Plugin Bug Fix:
Quorum queue replica management operations over the HTTP API can now be turned off (deactivated). This functionality is useful in environments where replica management is completed by the platform team and tooling, and should not be exposed to cluster users. Refer to Github pull request 9151 for more information.
LDAP Plugin (AuthN/AuthZ Backend) Bug Fix:
Previously, the LDAP plugin did not interpolate values with non-ASCII characters correctly. Refer to Github issue 9059 for more information.
For a full list of 2.5.0 changes, review What's Changed.
Support for custom connect uri through annotation on rabbitmqcluster
. For more information, refer to Custom Connection URI.
For a full list of 1.12.0 changes, review What's Changed.
For more information about other features and fixes introduced in open-source RabbitMQ 3.11.0, review the release notes or to review release notes for open-source RabbitMQ versions from 3.11.18 to the current 3.11.22, go to here and select the release notes file for the particular version that you want.
VMware Tanzu RabbitMQ for Kubernetes 1.4.3 contains the following packages and changes:
Open-source RabbitMQ version 3.11.18 is a maintenance release in the 3.11.x release series.
Core Server: Bug Fixes
rabbitmq-upgrade drain
failed with an exception in environments where the management plugin (HTTP API) plugin listener was bound to a specific interface. This issue is now resolved.OAuth 2 Plugin: Enhancements
The OAuth 2 plugin now accepts JWT tokens without a scope. These tokens are useful only when the plugin is used exclusively for authentication and not authorization.
The cluster operator now supports scoping the cache namespace to more than 1 namespace if the OPERATOR_SCOPE_NAMESPACE
is a comma delimited list.
For a full list of 2.3.0 changes, review What's Changed.
The default queue type for a vhost can be now set to quorum
, classic
or stream
.
For a full list of 1.11.0 changes, review What's Changed.
For more information about other features and fixes introduced in open-source RabbitMQ 3.11.0, review the release notes or to review release notes for open-source RabbitMQ versions from 3.11.11 to the current 3.11.18, go to here and select the release notes file for the particular version you want.
VMware Tanzu RabbitMQ for Kubernetes 1.4.2 contains the following packages and changes:
Open-source RabbitMQ version 3.11.11 is a maintenance release in the 3.11.x release series.
Core Server: Enhancements
There is now a way to pre-configure users and their permissions for newly created virtual hosts:
default_users.qa_user.vhost_pattern = qa.*
default_users.qa_user.tags = policymaker,monitoring
default_users.qa_user.password = fd237824441a78cd922410af4b83f0888186a8d7
default_users.qa_user.read = .*
default_users.qa_user.write = .*
default_users.qa_user.configure = .*
This is primarily useful in environments where RabbitMQ is provided as a service but customers (clients) have control over virtual hosts.
Core Server: Bug Fixes
rabbit_stream_coordinator
) was reported asother
. This issue is now resolved and the stream coordinator process memory footprint is now reported correctly (and classified differently).STOMP Plugin
/queue/
destinations that consume from streams can now specify the x-stream-max-segment-size-bytes
setting using SUBSCRIBE
frame headers.etcd Peer Discovery Plugin
RabbitMQ clusters deployed by the operator now support PersistentVolumeClaimRetentionPolicy
functionality.
For a full list of 2.2.0 changes, review What's Changed.
For a full list of 1.10.2 changes, review What's Changed.
For more information about other features and fixes introduced in open-source RabbitMQ 3.11.0, review the release notes or to review release notes for RabbitMQ versions from 3.11.8 to the current 3.11.11, go to here and select the release notes file for the particular version you want.
VMware Tanzu RabbitMQ for Kubernetes 1.4.1 contains the following packages and changes:
audit-logger
package to audit events that are triggered by RabbitMQ clusters is included in this release. Go to the Install, Configure and Use the VMware RabbitMQ audit-logger Package documentation to install and use it.RabbitMQ version 3.11.8 is a maintenance release in the 3.11.x release series. The main fixes in this release are:
Core Server
Stream throughput improvements are implemented for workloads, which have a lot of smaller size messages (messages less than 10 bytes).
CLI Tools Features
rabbitmqctl hash_password
is a new command that produces a hashed value for the password that is provided.
rabbitmq-diagnostics check_port_connectivity
now supports a new optional --address
flag where the user can now enter an IP address for the node and test it's connectivity. Previously, only hostname resolution was allowed. This is useful when the target node is configured to only listen for connections on one interface but not others. The following example shows how to provide the IP address with the --address
flag.
rabbitmq-diagnostics check_port_connectivity --address 127.0.0.1
rabbitmq-diagnostics check_port_connectivity --address "::1"
Management Plugin
The bug fixes are:
AMQP 1.0 Plugin
STOMP Plugin
For more information about other features and fixes introduced in open-source RabbitMQ 3.11.0, review the release notes or to review release notes for RabbitMQ versions from 3.11.2 to the current 3.11.8, go to here and select the release notes file for the particular version you want.
VMware Tanzu RabbitMQ for Kubernetes 1.4.0 contains the following packages and changes:
RabbitMQ version 3.11.2 is a maintenance release in the 3.11.x release series. The main fixes in this release are:
Core Server
MQTT Plugin
When a node was put into maintenance mode, it closed all MQTT client connections for the entire cluster instead of just local client connections.
Open Source RabbitMQ 3.11.x contains some great features, which you can avail of. The main features in RabbitMQ 3.11.x are:
Streams
Single Active Consumer: RabbitMQ 3.11 introduced the single active consumer feature for streams. With this feature, several consumer instances can be attached to a stream with one consumer instance active at a time. If the active consumer instance goes down, the next instance automatically take over ensuring processing continues with minimal interuption. To summarize, this features provides exclusive consumption and consumption continuity on a stream. For more information, refer to the Single Active Consumer for Streams blog.
OAuth 2 support
implicit flow
. It now only supports the much safer authorization code with PKCE
.scopes
. Now, in addition, RabbitMQ supports a new permission model called called Rich Authorization Request.For more information about other features and fixes introduced in open-source RabbitMQ 3.11.0, review the release notes or to review release notes for RabbitMQ versions from 3.10.6 to the current 3.11.2, go to here and select the release notes file for the particular version you want.
Clusters now have the value of the cluster_formation.target_cluster_size_hint
configuration parameter set automatically. This value is adjusted by the Cluster Operator if the size of the cluster changes. Currently, this value is used by RabbitMQ at start up to wait for all nodes to join the cluster and before specific operations such importing definitions.
The main changes are:
TopicPermission
objects using the Messaging Topology Operator. Topic authorisation targets topic-orientated protocols such as STOMP and MQTT.management.path_prefix
is set in the spec.rabbitmq.additionalConfig
of a RabbitmqCluster, the Messaging Topology Operator now successfully connects to that cluster.VMware Tanzu RabbitMQ for Kubernetes 1.3.2 is a security release which has one change. Erlang is now updated to version 24.3.4.4 to include the fix for CVE-2022-37026. Everything else remains the same as the 1.3.1 release.
VMware Tanzu RabbitMQ for Kubernetes 1.3.1 contains the following packages and changes:
RabbitMQ version 3.10.6 is a maintenance release in the 3.10.x release series. The main changes in this release are:
For a full list of changes, review the RabbitMQ 3.10.6 release notes. Release notes for previous RabbitMQ versions 3.10.2 to 3.10.5 are here.
For a full list of changes, review the Cluster Operator 1.14.0 release note.
Release notes for previous Cluster Operator versions can be reviewed here.
For a full list of changes, review the Messaging Topology Operator 1.7.1 release note.
Release notes for previous Messaging Topology Operator versions can be reviewed here.
This operator now supports getting credentials from Vault when configuring a downstream RabbitMQ cluster.
VMware Tanzu RabbitMQ for Kubernetes 1.3.0 contains the following packages and changes
Quorum Queue Features
Classic Queues
Streams Support
Scope Aliases in the OAuth 2 Plugin
Performance Improvements
Find out more about these performance improvements in the RabbitMQ 3.10.0 Performance Improvements blog.
To review release notes for RabbitMQ versions 3.10.0 to 3.10.2, access the following links:
The main changes are:
RabbitmqCluster
status when Vault integration is setup. Service binding was supported in previous versions but it is now supported when Vault integration is setup.For a full list of changes, review the Cluster Operator 1.13.1 release note.
Release notes for previous Cluster Operator versions can be reviewed here.
The main changes are:
For a full list of changes, review the Messaging Topology Operator 1.6.0 release note.
Release notes for previous Messaging Topology Operator versions can be reviewed here.
You can now import definitions from a URL accessible over HTTPS on node boot. Set the definitions.import_backend
and definitions.https.url
config keys to https
and a valid URL where a JSON definition is located. More details here.
VMware Tanzu RabbitMQ for Kubernetes 1.2.3 is a security release which has two changes only. Erlang is now updated to version 24.3.4.4 to include the fix for CVE-2022-37026 and RabbitMQ is now updated to 3.9.23. Everything else remains the same as the 1.2.2 release.
VMware Tanzu RabbitMQ for Kubernetes 1.2.2 contains the following packages and changes:
Release notes for individual RabbitMQ versions from 3.9.9 to 3.9.13:
Check the release note for Cluster Operator 1.11.1 here.
VMware RabbitMQ 1.2.1 contains the following packages and changes:
disableNonTLSListeners
is true
and TLS has not been configuredVMware Tanzu RabbitMQ for Kubernetes 1.2.0 contains the following packages and changes:
Bug Fixes
rabbitmq-diagnostics memory_breakdown
failed to read memory of connection reader, writer and channel processes.Prometheus Plugin
Management Plugin
Web STOMP Plugin
Warm Standby Replication
Schema Definition Replication
Standby Replication Operator is included in this release. This allows for an 'Active Passive toplogy to be configured for VMware Tanzu RabbitMQ for Kubernetes 1.2.0.
Issue Description | Release Found In |
---|---|
Warm Standby Replication: Users can now configure credentials using rabbitmq.conf . One limitation around this is these credentials are listed in rabbitmq.conf . A method for storing them in a suitable secret store will be implemented in a future VMware Tanzu RabbitMQ for Kubernetes release. Note, prior to the 3.13.3 release, this was not an issue because configuring credentials in rabbitmq.conf was only introduced in the 3.13.3 VMware Tanzu RabbitMQ for Kubernetes release. |
3.13.3 |
Warm Standby Replication: When schema_definition_sync.downstream.locals.users.* is used (this feature is optional), the schema definition replication leaves warnings about failed permission import attempts in the downstream logs. You can ignore these warnings. This does not affect promoting the downstream (standby) cluster in any way. |
3.13.3 |
Issue Description | Release Found In | Release Resolved In |
---|---|---|
Messaging topology operator fails to delete correct bindings | 1.4.1 | 1.4.2 |
Admin page does not render correctly in the RabbitMQ Management UI. There are errors with limits/users/virtual hosts. | 1.4.1 | 1.4.2 |
VMware Tanzu RabbitMQ prints incorrect version in the logs. | 1.2.1 | 1.2.2 |
Warm Standby Replication downstream (standby) worker does not load TLS settings correctly. | 1.2.1 | 1.2.2 |
In-cluster stream replication over TLS does not work in the case where the inter-node TLS configuration uses the {match_fun, ...} key. This prevents the use of wildcard certificates for Erlang distribution port over TLS. |
1.3.1 | 1.4.0 |
Invalid default LDAP configuration for the user_dn_pattern . |
1.4.0 | 1.4.1 |
The command delete_internal_streams_on_standby_replication_upstream_cluster does not seem to work. |
1.4.0 | 1.4.1 |
Vhosts created with the standby_replication tag using the cli crashes the Standby Message Replication (rabbitmq_standby_replication ) plugin. |
1.4.0 | 1.4.1 |
Standby replication plugin bug fix: corrected an issue where changing the value of the standby.replication.operating_mode and restarting the node failed to fully adopt the intended mode. |
1.4.3 and in 1.5.0 | 1.4.4 and in 1.5.1 |