Uploaded image for project: 'Managed Service - API'
  1. Managed Service - API
  2. MGDAPI-4022

Addon secret missing alert and error

XMLWordPrintable

    • Icon: Task Task
    • Resolution: Done
    • Icon: Major Major
    • 1.24.0
    • None
    • None
    • MGDAPI - Sprint 25, MGDAPI - Sprint 26, MGDAPI - Sprint 27

      WHAT
      For grand fathering reason the operator was designed to work with out the addon secret. In this case it would fall back on to envs to get the value for the quota. With the adding of the custom smtp work there has being a dependence placed on the addon secret. The secret is expected to be on cluster. If the value for the smtp work is missing that is ok.

      We should be checking and error during the bootstrap stage if the secret is not present. It has being confirmed that all production clusters have the secret present. Different functions using the secret should handle the secret missing values needed for that feature.

      Error on this secret missing is important. For example take a customer that is using the 50m quota. If the secret gets removed some how the operator would not error and downgrade the user to the 20m quota. This downgraded will not be seen in ocm.

      HOW
      Check the code base for any function, places that used the addon secret and ensure they handle the errors on a missing secret correctly.
      Update the delayedInstall SOP to check for this missing secret.
      Engage with SRE if they would prefer a separate alert for this. Also clarify with SRE if cluster admins can actually delete a secret under the rhoam-operator namespace, see perms here

      TESTS

      • unit tests around any functions that gets updated due to this work
      • destructive e2e test is create which removes the secret and checks for the status block in the rhoam CR to state what the problem is.

      DONE

      • The operator has a full dependence on the addon secret.
      • Test are created to not allow this dependence to be removed

              aucunnin@redhat.com Austin Cunningham
              jfitzpat_rhmi Jim Fitzpatrick (Inactive)
              Maksym Vavilov Maksym Vavilov (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: