Check edge cases for automounted configmaps/secrets

[amisevsk]

What does this PR do?

Checks some edge cases in automounted secrets and volumes that can cause workspace startup to hang

1. Fail startup if the deployment we're creating is invalid
2. Check for collision in automounted volumes:
   • automounted volume collides with DevWorkspace volume on name
   • automounted volume collides with DevWorkspace volume on mountPath
   • automounted volumes collide on mountPath

Also prefixes automounted volumes with automount-[secret|configmap] to avoid collisions with each other and with DevWorkspace volumes (e.g. you can't automount a configmap named "project" currently).

Note: prefixing volume names as above can lead to issues, so it may be worth it to drop the last commit in this PR. If a secret/configmap's name is very long and the prefix pushes it over 63 chars, workspace start will fail.

What issues does this PR fix or reference?

Minor issue I happened to run into while checking #455 where my secrets shared a mountPath and no error was shown (except in logs)

Is it tested? How?

Here comes a long testing doc:

1. Store the DevWorkspace we'll use for testing in /tmp/

   cat > /tmp/test-dw.yaml <<EOF
   kind: DevWorkspace
   apiVersion: workspace.devfile.io/v1alpha2
   metadata:
     name: theia-next
   spec:
     started: true
     template:
       components:
         - name: test-container
           container:
             image: quay.io/libpod/busybox:latest
             volumeMounts:
               - name: testing-volume
                 path: /test-path
         - name: theia
           plugin:
             uri: https://che-plugin-registry-main.surge.sh/v3/plugins/eclipse/che-theia/next/devfile.yaml
         - name: testing-volume
           volume: {}
   EOF

2. Create secrets and configmaps for testing

   kubectl create secret generic test
   kubectl create configmap test
   kubectl patch secret test --type merge -p \
     '{
       "metadata": {
         "labels": {
           "controller.devfile.io/mount-to-devworkspace": "true"
         }
       }
     }'
   kubectl patch cm test --type merge -p \
     '{
       "metadata": {
         "labels": {
           "controller.devfile.io/mount-to-devworkspace": "true"
         }
       }
     }'

3. Case 1: automounted volumes collide on mountPath

   kubectl patch secret test --type merge -p \
     '{
       "metadata": {
         "annotations": {
           "controller.devfile.io/mount-path": "/collision"
         }
       }
     }'
   kubectl patch cm test --type merge -p \
     '{
       "metadata": {
         "annotations": {
           "controller.devfile.io/mount-path": "/collision"
         }
       }
     }'
   kubectl apply -f /tmp/test-dw.yaml
   kubectl get dw -w

   (should fail with meaningful error message)
4. Case 2: automounted volume and DevWorkspace volume collide on mountPath

   kubectl delete dw theia-next
   kubectl patch cm test --type merge -p \
     '{
       "metadata": {
         "annotations": {
           "controller.devfile.io/mount-path": "/test-path"
         }
       }
     }'
   kubectl apply -f /tmp/test-dw.yaml
   kubectl get dw -w

   (should fail with meaningful error message)

PR Checklist

• E2E tests pass (when PR is ready, comment /test v7-devworkspaces-operator-e2e, v7-devworkspace-happy-path to trigger)
  • v7-devworkspaces-operator-e2e: DevWorkspace e2e test
  • v7-devworkspace-happy-path: DevWorkspace e2e test

[sleshchenko]

I haven't tested but changes look meaningful.

Ideally, we should have unit tests for covered use-cases, but it's not mandatory.

[amisevsk]

Ideally, we should have unit tests for covered use-cases, but it's not mandatory.

I'll look into this -- I've generally been avoidant of adding tests for things that require the k8s API, so maybe it's time to dive into fakeClient :)

[JPinkney]

Changes make sense to me 👍

[sleshchenko]

/test v7-devworkspaces-operator-e2e, v7-devworkspace-happy-path

[amisevsk]

/test v7-devworkspace-happy-path

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: amisevsk, JPinkney, sleshchenko

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [JPinkney,amisevsk,sleshchenko]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

New changes are detected. LGTM label has been removed.

[amisevsk]

/test v7-devworkspaces-operator-e2e, v7-devworkspace-happy-path