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

[Operator] FSM of the operator breaks in case of an upgrade/update of existing deployment.

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Critical Critical
    • AMQ 7.10.0.OPR.3.GA
    • AMQ 7.10.0.OPR.1.GA
    • operator
    • None
    • False
    • None
    • False
    • Hide
      1. install operator 7.9.4-opr4 (OLM and 7.x channel used, but should not matter)
      2. deploy CR with basic broker deployment with persistence and message migration size 2 (size most likely doesn't matter) and upgrades enabled
      3. (probably optional step) Create an anycast queue
      4. (probably optional step) send couple of messages to second broker
      5. uninstall operator (remove subscription, operator group, install plan)
      6. install operator 7.10.0-opr1 (OLM and 7.10.x channel used, but should not matter)
      7. expectation: operator starts to upgrade broker pods (doesn't happen)
      8. scale down to trigger reconciliation process and message migration
      9. expectation: upgrade and scale down will happen as usual -> result: see the attached log.
      Show
      install operator 7.9.4-opr4 (OLM and 7.x channel used, but should not matter) deploy CR with basic broker deployment with persistence and message migration size 2 (size most likely doesn't matter) and upgrades enabled (probably optional step) Create an anycast queue (probably optional step) send couple of messages to second broker uninstall operator (remove subscription, operator group, install plan) install operator 7.10.0-opr1 (OLM and 7.10.x channel used, but should not matter) expectation: operator starts to upgrade broker pods (doesn't happen) scale down to trigger reconciliation process and message migration expectation: upgrade and scale down will happen as usual -> result: see the attached log.

      When broker 7.9.4 is deployed by it's corresponding operator, then the operator is removed and 7.10 operator is installed, it is unable to take over the previous deployment(s).

              gtully@redhat.com Gary Tully
              rvais Roman Vais (Inactive)
              Roman Vais Roman Vais (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved: