Uploaded image for project: 'Red Hat 3scale API Management'
  1. Red Hat 3scale API Management
  2. THREESCALE-10010

PodDisruptionBudget.v1beta1.policy API is being used which causes upgrade path difficulties

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Blocker Blocker
    • None
    • 2.11.3 GA, 2.12.2 GA
    • 3scale Operator
    • False
    • None
    • False
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Workaround Exists
    • Hide

      Option 1

      1. Uninstall the operator ({}DO NOT delete the APIManager CRD{})
      2. Follow the backup section chapter 9.4 of the backup & restore guide
      3. Install a OCP 4.10 cluster, it's the latest supported minor for 3scale 2.11 per the supported configurations
      4. Follow the restore section chapter 9.5
      5. Upgrade 2.11 to 2.12 after taking a backup via the operator
      6. Perform another backup now of 3scale 2.12
      7. Upgrade 2.12 to 2.13
      8. Take a backup of 2.13. This uses the 2.12 documentation because the 2.13 documentation is missing this chapter.
      9. Delete all 3scale resources & objects from the 3scale namespace on the 4.12 cluster
      10. Restore 2.13 backup on their OCP 4.12 cluster

      Option 2

      1. Patch the APIManager YAML with the following image references:

       

      apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
  name: 3scale-apimanager
  namespace: 3scale
spec: 
  wildcardDomain: {{DOMAIN}}
  resourceRequirementsEnabled: false
  imageStreamTagImportInsecure: true
  apicast: 
    productionSpec: 
      logLevel: debug
    stagingSpec: 
      logLevel: debug
    image: registry.redhat.io/3scale-amp2/apicast-gateway-rhel8@sha256:dec57677b53180ef5b89338cb1d43fc727299cbef781c95da87e0cf10092395d
  backend: 
    image: registry.redhat.io/3scale-amp2/backend-rhel8@sha256:8697cedba82c700efed14a3ec1fa2aa9e990da9fb75857278e3f036844c0f005
    redisImage: registry.redhat.io/rhscl/redis-5-rhel7@sha256:52ffb5bf944593c290c2de52db5117044e58633385dcbe70679ea69ff0c5ff01
  system: 
    image: registry.redhat.io/3scale-amp2/system-rhel7@sha256:e55e769a21030b3aa268a714138dd7fdb2ab348515c917f72362431bc46d2cf5
    redisImage: registry.redhat.io/rhscl/redis-5-rhel7@sha256:52ffb5bf944593c290c2de52db5117044e58633385dcbe70679ea69ff0c5ff01
    memcachedImage: registry.redhat.io/3scale-amp2/memcached-rhel7@sha256:08264cf3271b477562fa13b5e0190bf634c49d581e1cef59f5119c0bc88657f4
    database: 
      mysql:
        image: registry.redhat.io/rhel8/mysql-80@sha256:e2c4296aa3854c474a1cf1131f2f43cd19a1340bef510c180261a175bd58d58d
  zync: 
    image: registry.redhat.io/3scale-amp2/zync-rhel8@sha256:390cf1a4991bb5c62f18a0cf053d4e9a943d993c5f8ceddf1a1cf8d5bb34abc1
    postgreSQLImage: registry.redhat.io/rhscl/postgresql-10-rhel7@sha256:74a95fba3fb7edd8f6e439d5488bc954e6bae7b66ce82be3e33b3195ac42a58e

       

      2. Remove 3scale Operator 2.11 and install 3scale Operator 2.13 in the same namespace

      3. After the upgrade is complete (will upgrade according to the images, to version 2.12), edit APIManager YAML again and remove the image entries. This will make 3scale Operator to upgrade to the default images, upgrading to version 2.13.

      Show
      Option 1 1. Uninstall the operator ( { }DO NOT delete the APIManager CRD{ } ) 2. Follow the backup section chapter 9.4 of the backup & restore guide 3. Install a OCP 4.10 cluster, it's the latest supported minor for 3scale 2.11 per the supported configurations 4. Follow the restore section chapter 9.5 5. Upgrade 2.11 to 2.12 after taking a backup via the operator 6. Perform another backup now of 3scale 2.12 7. Upgrade 2.12 to 2.13 8. Take a backup of 2.13 . This uses the 2.12 documentation because the 2.13 documentation is missing this chapter. 9. Delete all 3scale resources & objects from the 3scale namespace on the 4.12 cluster 10. Restore 2.13 backup on their OCP 4.12 cluster Option 2 1. Patch the APIManager YAML with the following image references:   apiVersion: apps.3scale.net/v1alpha1 kind: APIManager metadata:   name: 3scale-apimanager   namespace: 3scale spec:    wildcardDomain: {{DOMAIN}}   resourceRequirementsEnabled: false   imageStreamTagImportInsecure: true   apicast:      productionSpec:        logLevel: debug     stagingSpec:        logLevel: debug     image: registry.redhat.io/3scale-amp2/apicast-gateway-rhel8@sha256:dec57677b53180ef5b89338cb1d43fc727299cbef781c95da87e0cf10092395d   backend:      image: registry.redhat.io/3scale-amp2/backend-rhel8@sha256:8697cedba82c700efed14a3ec1fa2aa9e990da9fb75857278e3f036844c0f005     redisImage: registry.redhat.io/rhscl/redis-5-rhel7@sha256:52ffb5bf944593c290c2de52db5117044e58633385dcbe70679ea69ff0c5ff01   system:      image: registry.redhat.io/3scale-amp2/system-rhel7@sha256:e55e769a21030b3aa268a714138dd7fdb2ab348515c917f72362431bc46d2cf5     redisImage: registry.redhat.io/rhscl/redis-5-rhel7@sha256:52ffb5bf944593c290c2de52db5117044e58633385dcbe70679ea69ff0c5ff01     memcachedImage: registry.redhat.io/3scale-amp2/memcached-rhel7@sha256:08264cf3271b477562fa13b5e0190bf634c49d581e1cef59f5119c0bc88657f4     database:        mysql:         image: registry.redhat.io/rhel8/mysql-80@sha256:e2c4296aa3854c474a1cf1131f2f43cd19a1340bef510c180261a175bd58d58d   zync:      image: registry.redhat.io/3scale-amp2/zync-rhel8@sha256:390cf1a4991bb5c62f18a0cf053d4e9a943d993c5f8ceddf1a1cf8d5bb34abc1     postgreSQLImage: registry.redhat.io/rhscl/postgresql-10-rhel7@sha256:74a95fba3fb7edd8f6e439d5488bc954e6bae7b66ce82be3e33b3195ac42a58e   2. Remove 3scale Operator 2.11 and install 3scale Operator 2.13 in the same namespace 3. After the upgrade is complete (will upgrade according to the images, to version 2.12), edit APIManager YAML again and remove the image entries. This will make 3scale Operator to upgrade to the default images, upgrading to version 2.13.

      Current Behaviour

      Because of this incompatibility only being resolved in 3scale 2.13 as documented in THREESCALE-8535 we have broken the upgrade path according to the OpenShift life cycle policy and it is not possible to upgrade OCP 4.10 to 4.12 without entering an unsupported configuration and also breaking the 3scale installation. Customers are finding themselves in a broken state when they arrive on OCP 4.12 when they try to upgrade 3scale.

      Expected behaviour

      The fix in THREESCALE-8535 should be available on 3scale 2.12, explicitly it should be possible to install 3scale 2.12 on OCP 4.12 and upgrade from 2.11 to 2.12.

      Note

      Neither of the 2 options available as workarounds are reasonable and involve a lot of work and are error prone not even considering the fact we have broken the OCP EUS policy. More and more customers are getting into this broken state as OCP 4.10 reaches EOL and they are upgrading directly to 4.12 to which there is no existing supported migration path for 3scale customers.

          1.
          		 Fix maxOpenshiftVersion in 3scale 2.11 Sub-task Closed Major Unassigned
          2.
          		 Fix maxOpenshiftVersion in 3scale 2.12 Sub-task Closed Major Unassigned

              Unassigned Unassigned
              rhn-support-keprice Kevin Price
              Yorgos Saslis Yorgos Saslis
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: