Uploaded image for project: 'OpenShift GitOps'
  1. OpenShift GitOps
  2. GITOPS-2372

Refine upgrade-operator script

    XMLWordPrintable

Details

    • Epic
    • Resolution: Won't Do
    • Undefined
    • None
    • None
    • Testing
    • Refine upgrade-operator
    • False
    • None
    • False
    • To Do
    • 0
    • 0% 0%

    Description

      After the `docker login` removal in the commit 3327bc most of those scripts are error-prone since they only work when the local has an active session with the quay.io registry. In some other cases, the installation of the operator fails due to missing credentials in the secret pull-secret to access and pull the IIB bundle image.

      To see an example of how the flow works in the current scripts:

      1. They export the current pull-secret config from the OCP cluster to a file named "authfile":

      oc get secrets pull-secret -n openshift-config -o template='{{index .data ".dockerconfigjson"}}' | base64 -d > authfile
      

      2. Then, back up the docker config and use "authfile" as it:

      mv ~/.docker/config.json ~/.docker/config_tmp.json
      mv ./authfile ~/.docker/config.json
      

      3. At this point, they log in with a shared account to append the login information to the JSON file (link here):

      docker login (...)
      

      4. Move back the docker config files:

      mv ~/.docker/config.json ./authfile
      mv ~/.docker/config_tmp.json ~/.docker/config.json
      

      5. Now the "authfile", with all the OCP pull-secrets information along with the pull-secret for our personal Quay registry (where the IIB image was pushed), is used to update the proper secret in the cluster:

      oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=authfile
      

      They are some drawbacks in using this strategy to share the IIB bundle with the cluster:

      1. We are mirroring the same image several times to individual accounts, and that leaves in the hands of each team member the management of credentials and permissions, apart from the over usage of the platform.
      2. Using a Quay shared account like devtools allows us to segment the solution into two pieces: The one which pushes the IIB images to the registry, and the other that configures the OCP cluster secret to access those images.
      3. Moreover, the use of that shared account would simplify the maintenance and cleanup tasks, as well as permit the centralization of those tasks.

      We may enhance the gitops-components-automated-testing scripts to find a better solution for retrieving and pushing the IIB images

      Acceptance Criteria:

      1. To remove and clean up all unnecessary code inside the gcat scripts.
      2. Store all IIB in a centralize Quay registry.
      3. Find a way to handle the credentials for Brew Registry instead of prompting for the password (docker login) in every execution.

      Attachments

        Activity

          People

            bluengop@redhat.com Borja Luengo (Inactive)
            bluengop@redhat.com Borja Luengo (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: