-
Bug
-
Resolution: Done
-
Major
-
None
-
AMQ 7.6.0.GA
-
None
-
Previously, for an Operator-based broker deployment, if you created a Custom Resource (CR) instance for addresses before the brokers had been instantiated, the Operator failed to create the addresses. This issue is now resolved.
-
Documented as Resolved Issue
-
Workaround Exists
-
-
When deploying the AMQ Broker via the operator, if the address CR is created before the broker instance is fully instantiated, the address is never created in the broker.
The address controller fails to create the address due to the Pod IP not being available yet. The address controller swallows the error while trying to connect to the broker via jolokia, and/or may fail to create the address is a user/pass other than admin/admin is configured on the broker. The operator assumes the address was created successfully, and doesn't try to create the address in the broker again.
The operator should be watching the current state of the broker, versus the desired state in the CR. The operator is keeping internal state that assumes it matches the state of the actual broker. The event loop needs to treat the state of the broker as the actual state instead. The error handling needs to be improved as well to ensure such errors/faults are detected and cause the operator to retry.
- relates to
-
ENTMQBR-3526 Broker operator should reconcile client/broker API driven broker configuration changes
- New
-
ENTMQBR-3999 Operator restart with existing statefulset results in non-responsive operator
- Closed
-
ENTMQBR-3137 Operator does not automatically deploy CRD created addresses on scale-up
- Closed