Skip to content

DO NOT MERGE: Peer discovery 4.1#1865

Draft
mkuratczyk wants to merge 2 commits intomainfrom
peer-discovery-4.1
Draft

DO NOT MERGE: Peer discovery 4.1#1865
mkuratczyk wants to merge 2 commits intomainfrom
peer-discovery-4.1

Conversation

@mkuratczyk
Copy link
Contributor

These changes can be merged when we decide to only support RabbitMQ 4.1+. It removes settings that 4.1 k8s peer discovery plugin ignores anyway and removes permissions that were only needed by the old k8s peer discovery.

mkuratczyk added 2 commits May 5, 2025 17:08
Not needed since k8s peer discovery doesn't
call the Kubernetes API
@mkuratczyk mkuratczyk added the never-stale Issue or PR marked to never go stale label May 5, 2025
lmiccini added a commit to lmiccini/infra-operator that referenced this pull request Mar 16, 2026
Two fixes for RabbitMQ 4.x peer discovery on OTP 26:

1. Include k8s.host, k8s.address_type, and k8s.service_name config
   options for all RabbitMQ versions (not just 3.x). While 4.x ignores
   these options, including them matches the current cluster-operator
   behavior (see rabbitmq/cluster-operator#1865).

2. Change inter-node TLS from verify_peer to verify_none. OTP 26
   enforces strict hostname verification with verify_peer, which breaks
   RabbitMQ 4.x peer discovery: the k8s plugin spawns a hidden Erlang
   peer via OTP's peer module that connects back via TLS distribution,
   but the ephemeral peer's node name doesn't match the certificate's
   SAN entries, causing the TLS handshake to fail. This is a known
   issue (rabbitmq/rabbitmq-server#11074). Certificate chain validation
   against the CA is still performed; only hostname matching is skipped.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

never-stale Issue or PR marked to never go stale

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant