-
Bug
-
Resolution: Done-Errata
-
Normal
-
rhos-18.0.0
-
0
-
False
-
-
False
-
Committed
-
No Docs Impact
-
OSPRH-4567 - TLSe improvements [FR1]
-
openstack-operator-container-1.0.4-6
-
Committed
-
No impact
-
None
-
-
-
0
-
Important
I started with a controlplane, which had TLS enabled (Rabbit had TLS enabled as expected). Then I disabled TLS in the control plane CR, but rabbit still runs behind TLS.
- related compose
- quay.io/openstack-k8s-operators/openstack-operator@sha256:c036f2eed4ad0c850bed365d7214a1b4145ce82456deb33698d8600347c91f6b
- quay.io/openstack-k8s-operators/rabbitmq-cluster-operator@sha256:396212f6cb378d54afbe6ff2401cca844f5d17c75a966b71f057aab0a4b32c86
- _How reproducible
_- Always
- Steps to reproduce
- Deploy a controlplane with TLS enabled
- Disable TLS on ingress and podLevel (I think podLevel should be enough)
- Curl the prometheus or management endpoint to see if it uses TLS (it does even though it shouldn't)
- _Expected result
_- The RabbitMQ endpoint is reachable through HTTP
- _Actual results
_- RabbitMQ endpoint still uses HTTPS
- Additional info:
- The deployed controlplane with TLS disabled
- _oscp.yaml
_
-
- Curl for RabbitMQ metrics
- _$ curl http://rabbitmq.openstack.svc:15691/metrics
curl: (1) Received HTTP/0.9 when not allowed_ - _$ curl https://rabbitmq.openstack.svc:15691/metrics --insecure 2> /dev/null | head
- TYPE erlang_mnesia_held_locks gauge
- HELP erlang_mnesia_held_locks Number of held locks.
erlang_mnesia_held_locks 0 - TYPE erlang_mnesia_lock_queue gauge
- HELP erlang_mnesia_lock_queue Number of transactions waiting for a lock.
erlang_mnesia_lock_queue 0 - TYPE erlang_mnesia_transaction_participants gauge
- HELP erlang_mnesia_transaction_participants Number of participant transactions.
erlang_mnesia_transaction_participants 0 - TYPE erlang_mnesia_transaction_coordinators gauge_
- links to
-
RHSA-2024:140345 RHOSO OpenStack Podified operator containers security update
- mentioned on