Add RabbitMQ federation support for multi-region deployments#533
Draft
xek wants to merge 2 commits intoopenstack-k8s-operators:mainfrom
Draft
Add RabbitMQ federation support for multi-region deployments#533xek wants to merge 2 commits intoopenstack-k8s-operators:mainfrom
xek wants to merge 2 commits intoopenstack-k8s-operators:mainfrom
Conversation
Contributor
|
Skipping CI for Draft Pull Request. |
Contributor
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: xek The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
4 tasks
xek
added a commit
to xek/openstack-operator
that referenced
this pull request
Feb 12, 2026
Extend the RabbitmqSection in OpenStackControlPlane with an optional Federation map that allows configuring RabbitMQ exchange federation between clusters in multi-region deployments. Each federation entry creates a RabbitMQFederation CR (from infra-operator) that configures the local RabbitMQ cluster to replicate matching exchanges from a remote upstream. This enables services like barbican-keystone-listener in regionTwo to consume Keystone notifications from their local broker, with federation handling replication transparently. Includes a sample configuration showing how to set up federation for Keystone notifications in a two-region deployment. Depends-On: openstack-k8s-operators/infra-operator#533 Closes: OSPRH-25296 Co-authored-by: Cursor <cursoragent@cursor.com>
2fe6d7d to
e3830a6
Compare
xek
added a commit
to xek/openstack-operator
that referenced
this pull request
Feb 12, 2026
Extend the RabbitmqSection in OpenStackControlPlane with an optional Federation map that allows configuring RabbitMQ exchange federation between clusters in multi-region deployments. Each federation entry creates a RabbitMQFederation CR (from infra-operator) that configures the local RabbitMQ cluster to replicate matching exchanges from a remote upstream. This enables services like barbican-keystone-listener in regionTwo to consume Keystone notifications from their local broker, with federation handling replication transparently. Includes a sample configuration showing how to set up federation for Keystone notifications in a two-region deployment. Depends-On: openstack-k8s-operators/infra-operator#533 Closes: OSPRH-25296 Assisted-by: Claude 4.6 Opus (Anthropic AI) Co-authored-by: Cursor <cursoragent@cursor.com>
c4ada72 to
e1c424c
Compare
Introduces the RabbitMQFederation CRD and controller for configuring RabbitMQ exchange/queue federation between clusters. Supports both same-namespace federation (via UpstreamClusterName) and cross-region federation (via UpstreamSecretRef with AMQP URIs). Key features: - RabbitMQFederation CRD with comprehensive spec (ack mode, expires, max hops, prefetch count, reconnect delay, trust user ID, policy pattern, queue type, priority, etc.) - Controller with full lifecycle management: upstream creation, policy creation, plugin auto-enablement, finalizer-based cleanup - Upstream cluster protection via per-federation finalizers on the upstream RabbitMq CR - Webhook validation (immutable fields, mutual exclusivity, upstream existence checks, regex validation) - Management API client extensions for federation upstreams and policies - Functional tests for controller and webhook Co-authored-by: Luca Miccini <lmiccini@redhat.com> Assisted-by: Claude 4.6 Opus
8574146 to
d3523b2
Compare
xek
added a commit
to xek/openstack-operator
that referenced
this pull request
Feb 12, 2026
Extend the RabbitmqSection in OpenStackControlPlane with an optional Federation map that allows configuring RabbitMQ exchange federation between clusters in multi-region deployments. Each federation entry creates a RabbitMQFederation CR (from infra-operator) that configures the local RabbitMQ cluster to replicate matching exchanges from a remote upstream. This enables services like barbican-keystone-listener in regionTwo to consume Keystone notifications from their local broker, with federation handling replication transparently. Includes a sample configuration showing how to set up federation for Keystone notifications in a two-region deployment. Depends-On: openstack-k8s-operators/infra-operator#533 Closes: OSPRH-25296 Assisted-by: Claude 4.6 Opus Co-authored-by: Cursor <cursoragent@cursor.com>
When a RabbitMQFederation is reconciled, the controller now ensures that rabbitmq_federation and rabbitmq_federation_management plugins are enabled on the target RabbitmqCluster CR's additionalPlugins. When the plugins are first added, reconciliation is requeued for 30s to allow RabbitMQ to load them before configuring upstreams/policies. On deletion, if no other RabbitMQFederation CRs reference the same cluster, the federation plugins are removed from additionalPlugins. Plugin removal uses the Kubernetes API and is always attempted even when the RabbitMQ management API is unavailable. This ensures a clean state. Adds functional tests for plugin addition, removal, preservation when multiple federations exist, and status condition initialization. Assisted-by: Claude 4.6 Opus Co-authored-by: Cursor <cursoragent@cursor.com>
d3523b2 to
638f18b
Compare
xek
added a commit
to xek/openstack-operator
that referenced
this pull request
Feb 12, 2026
Extend the RabbitmqSection in OpenStackControlPlane with an optional Federation map that allows configuring RabbitMQ exchange federation between clusters in multi-region deployments. Each federation entry creates a RabbitMQFederation CR (from infra-operator) that configures the local RabbitMQ cluster to replicate matching exchanges from a remote upstream. This enables services like barbican-keystone-listener in regionTwo to consume Keystone notifications from their local broker, with federation handling replication transparently. Includes a sample configuration showing how to set up federation for Keystone notifications in a two-region deployment. Depends-On: openstack-k8s-operators/infra-operator#533 Closes: OSPRH-25296 Assisted-by: Claude 4.6 Opus Co-authored-by: Cursor <cursoragent@cursor.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
RabbitMQFederationCRD and controller to configure RabbitMQ exchange federation via the Management HTTP APIbarbican-keystone-listenercan consume them from their local brokermax-hops,prefetch-count,reconnect-delayper the RabbitMQ federation reference)The upstream connection can be specified either by referencing a
RabbitmqClusterCR in the same namespace (for testing) or via a Secret containing the AMQP URI (for cross-region deployments).The controller:
federation-upstreamparameter on the local clusterapply-to: exchanges)Closes: OSPRH-25296
Assisted-by: Claude 4.6 Opus (Anthropic AI)
Test plan
upstreamSecretRef