Give warning when using unsupported devfile features

[AObuchow]

Description

Since there are devfile 2.2.x features that are not currently supported by DWO, we should warn the user when these features are being used in a devworkspace.

I imagine this would involve checking the workspace after it has been flattened and setting a warning to the workspace status.

Additional context

Related: #983

[AObuchow]

There are 3 potential approaches to presenting this warning to users that I've thought of so far: setting a warning in the workspace's status conditions, letting the webhook return an error when applying the devworkspace or letting the workspace give a warning when applying the devworkspace.

Workspace status warning

Pros:

• Allows users to still use devworkspaces with unsupported features (though it's possible the workspace won't work as expected)

Cons:

• Not very visible to users. AFAIK, the dashboard does not present workspace status warnings. Thus, the only way for a user to see the warning is by doing a kubectl get dw ... or a kubectl describe dw <workspace-name>. This could lead to a scenario where the user's workspace isn't working correctly, and they have todo a bit of debugging/research to figure out the issue.

Blocking workspaces that use unsupported features with webhooks

Pros:

• The dashboard is already able to present a UI error when the webhook returns an error
• It is impossible for the user to ignore the warning (since the workspace won't start), preventing potential cases where a user ignores the warning and reports issues with their workspace

Cons:

• There are unsupported features such as components.volume.size that won't necessarily break the workspace if they aren't supported by DWO. It could be frustrating to try using a devfile that uses these features (especially if the devfile comes from a repository that the user does not own), since the flow to get the workspace running would be:
  1. Try opening the workspace and receive the error
  2. Fork the repository
  3. Locally clone the repository
  4. Remove unsupported features from devfile
  5. Commit and push changes
  6. Try opening the workspace again, using the user's fork repository

Webhook warnings for unsupported features

Pros:

• Would allow users to still use devworkspace that have unsupported features (though the workspace may not behave correctly)

Cons:

• The dashboard does not support displaying webhook warnings yet. Currently, the only way to see the webhook warning would be to check DWO's logs, which a normal user may not have privilege to do. Checking the logs is also more difficult than doing a kubectl get dw ... or a kubectl describe dw <workspace-name>

In my opinion, blocking workspaces that use unsupported devfile features is the best approach that can be implemented today due to the fact that the warning/error would be visible in the dashboard.

If webhook warnings become supported by the dashboard, then this would be the best approach.

@amisevsk @ibuziuk @l0rd let me know if you have any thoughts on which approach should be taken.

[ibuziuk]

the two main UX points that we quickly discussed during standup today:

• as a user, I want to see the warning during workspace startup if my devfile contains properties that are unsupported by DWO
• as a user, I want to take a decision if I want to start a workspace anyway with unsupported devfile features or not

for the second point, I think we should have a similar UX that was implemented in eclipse-che/che#20738

However, instead of Continue with the default devfile we should have smth. like Continue Anyway

Based on that, it looks like the best option would be 1) Workspace status warning proposal, but this would require additional changes for showing the DW status message on UD level @l0rd @amisevsk wdyt?

[AObuchow]

I think the simplest approach to achieve the UX goals we discussed would be for DWO to use webhook admission warnings, since the dashboard wouldn't have to add support for checking DW status'. The response from the Kubernetes API request to create the devworkspace should include the warning, and when this is caught, the UI warning could be presented.

Currently, in my testing, the Dashboard simply ignores the webhook warning and proceeds with opening the workspace.

for the second point, I think we should have a similar UX that was implemented in eclipse/che#20738

However, instead of Continue with the default devfile we should have smth. like Continue Anyway

+1