Uploaded image for project: 'AMQ Broker'
  1. AMQ Broker
  2. ENTMQBR-3514

Address not created if address CR is submitted before broker instantiated

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • None
    • AMQ 7.6.0.GA
    • operator
    • 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
    • Hide

      Apply the address CR only after the broker as started (user should not have to do this).

      Show
      Apply the address CR only after the broker as started (user should not have to do this).
    • Hide
      1. Apply the broker and address CR at the same time.
      2. Log into the broker admin console and inspect to see that the address is not present in the broker.
      3. Remove and apply the address CR again, inspect to see that the address is then created.
      Show
      Apply the broker and address CR at the same time. Log into the broker admin console and inspect to see that the address is not present in the broker. Remove and apply the address CR again, inspect to see that the address is then created.

    Description

      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.

      Attachments

        Issue Links

          relates to

          Story - Created by Jira Software - do not edit or delete. Issue type for a user story. ENTMQBR-3526 Broker operator should reconcile client/broker API driven broker configuration changes

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • New

          Bug - A problem that impairs or prevents the functions of the product. ENTMQBR-3999 Operator restart with existing statefulset results in non-responsive operator

          • Blocker - To be worked above all other priorities. This term is chosen when the severity of the issue is very high, has no workaround, or the effort for the change is comparatively low. Issues that may be very publicly visible and could generate significant media attention may also drive a higher priority.
          • Closed

          Story - Created by Jira Software - do not edit or delete. Issue type for a user story. ENTMQBR-3137 Operator does not automatically deploy CRD created addresses on scale-up

          • Critical - To be worked on immediately following BLOCKER issues.
          • Closed

          Activity

            People

              gaohoward Howard Gao
              jowest@redhat.com Josh West
              Mikhail Krutov Mikhail Krutov
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: