Allow configuring workspace start timeout via CheCluster spec

[amisevsk]

Is your enhancement related to a problem? Please describe

Since workspace start is managed by the DevWorkspace Operator, the timeout before a starting workspace is marked as failed is now configured through the DevWorkspace Operator Config (DWOC) CR, deprecating older Che properties.

For certain CheCluster fields (e.g. PVC configuration), the Che Operator manages these fields by creating a custom DWOC that is used for all workspaces. This should be extended to allow setting .config.workspace.progressTimeout in the DWOC based on a CheCluster field as well.

Describe the solution you'd like

Start timeout for DevWorkspaces can be configured through the CheCluster spec

Describe alternatives you've considered

It's currently possible to work around this by setting the field in the CheCluster-owned DWOC in the install namespace. As this field is not managed by Che, its value is not reverted by the Che Operator.

Release Notes Text

The timeout to consider workspaces startup as failed was hardcoded and could not be configured by administrators. With this new feature Che administrators can specify the workspaces startup timeout in the CheCluster custom resource.

[tolusha]

I think startTimeout field is not introduced in operator config yeat.

[amisevsk]

My bad -- the field in DWOC is progressTimeout (i.e. .config.workspace.progressTimeout) since it applies to both starting and failing workspaces. I've updated the description above to reflect this.

Probably makes sense to use startTimeout in the Che config either way -- WDYT?

[tolusha]

Probably makes sense to use startTimeout in the Che config either way -- WDYT?

Make sense for me as well.

[AObuchow]

For this feature, I'm not sure if I should make it so that the DWOC field workspace.progressTimeout is overridden even if the corresponding Che Cluster CR field is not set. The outcome of this would be that leaving the Che Cluster field blank would cause DWO to use the default progress timeout value of 5 minutes.

i.e. Che Cluster CR devEnvironments.startTimeout = "" (unset) -> sets .config.workspace.progressTimeout = "" -> default progress timeout value of 5m is used.

The only affected users from this would be those who are using the workaround @amisevsk gave:

It's currently possible to work around this by setting the field in the CheCluster-owned DWOC in the install namespace. As this field is not managed by Che, its value is not reverted by the Che Operator.

If these users had set a non-default progress timeout value, and then upgrade Che (once my patch is merged), the progress timeout value in the DWOC would be reset to 5 minutes, and they would have to modify the timeout field in the Che Cluster CR.

I don't think this is really a breaking change (since it only affects the workaround), but it may be worth considering.

CC: @ibuziuk