feat: Mounting resources should not cause workspace restart

[tolusha]

What does this PR do?

This PR prevents automatic workspace restarts when mounting resources (ConfigMaps, Secrets, PVCs) by introducing a new controller.devfile.io/mount-on-start-only attribute.

What issues does this PR fix or reference?

eclipse-che/che#23553

Is it tested? How?

PR Checklist

• E2E tests pass (when PR is ready, comment /test v8-devworkspace-operator-e2e, v8-che-happy-path to trigger)
  • v8-devworkspace-operator-e2e: DevWorkspace e2e test
  • v8-che-happy-path: Happy path for verification integration with Che

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: tolusha
Once this PR has been reviewed and has the lgtm label, please assign dkwon17 for approval. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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

[tolusha]

The main problem here is that even if we mount the resources (marked with special attributes) only when the workspace starts—and not while it’s running—we still need to decide how to handle changes to those resources while the workspace is active.
The crucial question is how we can prevent the workspace from restarting when those resources are modified, since the source object differs from the one in the cluster.

[dkwon17]

I haven't tried, but is it possible to ignore configmaps/secrets that have the controller.devfile.io/mount-on-start-only attribute in automountWatcher to avoid reconciling running workspaces?

devworkspace-operator/controllers/workspace/devworkspace_controller.go

Line 727 in b61eaed

Watches(&corev1.Secret{}, handler.EnqueueRequestsFromMapFunc(r.runningWorkspacesHandler), automountWatcher).

[tolusha]

It slightly mitigates the problem, but it doesn’t address it completely.

For example:

1. The object with the controller.devfile.io/mount-on-start-only attribute was changed, and we ignored it.
2. When a DWOC object changes, it triggers a reconcile. Then we need to build the spec object and compare it with the one in the cluster. Since the objects differ, this causes the workspace to restart.

https://github.com/devfile/devworkspace-operator/blob/main/controllers/workspace/devworkspace_controller.go#L719-L742

[tolusha]

There is a solution that I don’t really like, but it could work.
We would need to make copies of the objects marked with the controller.devfile.io/mount-on-start-only attribute that are mounted to the DW.
This way, we would be able to construct a spec object that matches the one in the cluster.