Uploaded image for project: 'Red Hat OpenShift Dev Spaces (formerly CodeReady Workspaces) '
  1. Red Hat OpenShift Dev Spaces (formerly CodeReady Workspaces)
  2. CRW-10226

Dev Spaces operator triggering unnecessary devspaces Deployment rollouts

XMLWordPrintable

    • False
    • Hide

      None

      Show
      None
    • False
    • Workaround Exists
    • Hide

      Do not include more than one data.key in 

      spec:
  devEnvironments:
    trustedCerts:
      gitTrustedCertsConfigMapName: che-git-self-signed-cert

      Consolidate all CA certs into one file and create a ConfigMap with only one data.key.

      Show
      Do not include more than one data.key in  spec:   devEnvironments:     trustedCerts:       gitTrustedCertsConfigMapName: che-git-self-signed-cert Consolidate all CA certs into one file and create a ConfigMap with only one data.key.
    • Hide

      Follow https://eclipse.dev/che/docs/stable/administration-guide/deploying-che-with-support-for-git-repositories-with-self-signed-certificates/ but create a ConfigMap with more than one data.key. The more keys you add, the more often you will see bad behavior.

      Show
      Follow https://eclipse.dev/che/docs/stable/administration-guide/deploying-che-with-support-for-git-repositories-with-self-signed-certificates/ but create a ConfigMap with more than one data.key. The more keys you add, the more often you will see bad behavior.

      Description of problem:

      Dev Spaces operator misbehaves when the {{gitTrustedCertsConfigMapName }}points to a ConfigMap that has more than one data.keys.

      Prerequisites (if any, like setup, operators/versions): 

      {}Dev Spaces v3.26

      Steps to Reproduce:

      Follow https://eclipse.dev/che/docs/stable/administration-guide/deploying-che-with-support-for-git-repositories-with-self-signed-certificates/ but create a ConfigMap with more than one data.key. The more keys you add, the more often you will see bad behavior.

      Actual results:

      During its normal reconciliation process, v3.26 of the Dev Spaces operator evaluates the ConfigMap, returning a list of its data.keys in a random order. The operator interprets the different ordering of keys as a change to the ConfigMap that it has to process (this is a bug, there was no change).

      When the ConfigMap processing logic executes, it increments the CM_VERSION environment variable value for the devspaces Deployment, which causes a new ReplicaSet to be created and the devspaces Pod to be replaced.

      Expected results:

      The Dev Spaces operator properly evaluates the ConfigMap has "no change" and takes no action.

      Reproducibility (Always/Intermittent/Only Once):

      Always

      Acceptance criteria:

      Given a user may create gitTrustedCertsConfigMapName with more than one data.key if they have multiple CA bundles they need to include,

      When the operator logic is updated to return the list of data.keys in the same order each time, (sort?)

      Then the unnecessary devspaces Deployment rollouts will cease.

       

      Definition of Done:

      Build Details:

      Additional info (Such as Logs, Screenshots, etc):

       

       *

              abazko Anatolii Bazko
              rh-ee-ajaeger Aaron Jaeger
              Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: