Allow admins to change workspaces inactivity and run timeout

[l0rd]

Is your enhancement related to a problem? Please describe

Before switching to the DevWorkspace engine, it was possible to specify workspaces timeout through Che server properties CHE_LIMITS_WORKSPACE_IDLE_TIMEOUT and CHE_LIMITS_WORKSPACE_RUN_TIMEOUT.

Currently Che-Theia based workspaces are idled after 15 minutes of inactivity. This is specified in the editor definition and it's not configurable by the user or by an admin (if not by patching the editor definition in the plugin registry or by publishing and using an alternative editor definition).

Note that VS Code and JetBrains IDE based workspaces are never idled and that we want to use a universal idling mechanism (there is a separate issue for that).

Describe the solution you'd like

CheCluster CRD should have:

• devEnvironments.secondsOfInactivityBeforeIdling
• devEnvironments.secondsOfRunBeforeIdling

That should be propagated as environment variables to the workspace containers:

• SECONDS_OF_DW_INACTIVITY_BEFORE_IDLING
• SECONDS_OF_DW_RUN_BEFORE_IDLING

Machine exec should parse those variables, if they exist, when setting the timeout.

Machine exec should support SECONDS_OF_DW_RUN_BEFORE_IDLING

Theia definition should not specify the --idle-timeout parameter for machine exec.

The defaults should be 30 minutes for secondsOfInactivityBeforeIdling and SECONDS_OF_DW_INACTIVITY_BEFORE_IDLING and -1 for secondsOfRunBeforeIdling and SECONDS_OF_DW_RUN_BEFORE_IDLING

Additional context

#21322

Release notes text

Administrators can specify the timeout for inactivity and running workspaces with the CheCluster spec.devEnvironmentfieldssecondsOfInactivityBeforeIdlingandsecondsOfRunBeforeIdling` respectively. The default values are 30 minutes and -1 (no timeout) respectively.

[pdfruth]

I ran across this enhancement request while searching for any known method of customizing the workspace idle timeout.
It is super annoying to have to restart a workspace after only 15 minutes of idle.

I have searched, and found another suggested workaround here.
But, that workaround does not seem to work in my environment (Red Hat OpenShift Dev Spaces Operator V3.0 on Red Hat OpenShift Container Platform V4.10.18)

Questions:

• Is there any news on when this enhancement will be implemented?
• Is there any workaround to customize or disable the idle timeout in the meantime?

[amisevsk]

I'm not clear on why it's done in this way. The DevWorkspace Operator provides the environment variable DEVWORKSPACE_IDLE_TIMEOUT to DevWorkspaces as a suggested idle timeout (which can be configured from the DevWorkspace configuration CR). If the e.g. machine-exec command was

          command:
            - /go/bin/che-machine-exec
            - '--url'
            - '127.0.0.1:3333'
            - '--idle-timeout'
            - '$DEVWORKSPACE_IDLE_TIMEOUT'

then the workspace would automatically take into account the configured value in DWO.

[l0rd]

Note that here we are talking about Theia, the default editor included in Che workspaces. If instead we specify to use VS Code, IntelliJ or PyCharm instead of Theia, those won't be idled at all (and this can be problematic too). So, @pdfruth, if you prefer no-idling you can refer to this blog post draft to use a different editor.

[pdfruth]

@l0rd
I don't think you've linked to a blog post draft. The link leads to a Git issue comment.
Can you link to the blog post draft, please?

[l0rd]

@pdfruth sorry, I have updated the comment above with the right link.

[pdfruth]

@l0rd Thank you for the updated link to the blog post draft.
I have attempted to follow the instructions by adding .che folder containing a che-editor.yaml file to an existing Git repo.
However, upon creating a new Openshift Dev Spaces workspace, I still see the Theia editor (as seen in this screen-shot)
The Git repo containing my simple Python app is here.
Can you see what I might have done wrong?

[l0rd]

@pdfruth: you need a devfile c.f. https://github.com/pdfruth/voting-app-py-ds/pull/1, thanks for spotting that, I will update the document to mention that.

@olexii4 I have reproduced that upstream too: .che/che-editor.yaml is ignored if there is no devfile.

[pdfruth]

Thank You @l0rd. I can confirm that the addition of a devfile has enabled the che-code editor to load. And there is no idle timeout!!

[pdfruth]

Hi @l0rd
As you mentioned earlier;

... if you prefer no-idling you can refer to this blog post draft to use a different editor.

I have been able to get the che-code editor working in conjunction with the Red Hat OpenShift Dev Spaces V3.0 operator on an OCP cluster on x86 architecture.
I would like to do the same on an OCP cluster on the s390x architecture. But I do not see container images at https://quay.io/repository/che-incubator/che-code?tab=tags.
Questions:

• Is there a place to find che-code images for s390x architecture?
• The blog article indicates the intent to make the VSCode editor = default, with 3Q22 timing. Is the intent to make it default on all supported architectures where the Red Hat OpenShift Dev Spaces operator is supported today? And is 3Q22 still valid?
• If there is not s390x images available today, is there instructions somewhere for building from source?

[l0rd]

@pdfruth @azatsarynnyy I don't think we have any s390 build yet and I am not sure if we have a plan to build it for 3Q22 (cc @azatsarynnyy @RomanNikitenko @nickboldt). To build it yourself you can have a look at the PR check GitHub action.

[l0rd]

I have updated the description with CheCluster devEnvironments section instead of workspaces and I have added a note about the default values for the CheCluster fields and the env variables.

[RomanNikitenko]

@pdfruth

If there is not s390x images available today, is there instructions somewhere for building from source?

I think for s390x platform you should add the corresponding target, please see here, building images - here

Using those changes I had a successful build for ppc64 platform, but I didn't test it for s390x platform...

[l0rd]

@dkwon17 can we close this issue (asking to figure out if we can include it in 7.51 release notes).

[dkwon17]

@l0rd , yes this can be closed and included in the 7.51 release notes

[nickboldt]

@pdfruth @azatsarynnyy I don't think we have any s390 build yet and I am not sure if we have a plan to build it for 3Q22 (cc @azatsarynnyy @RomanNikitenko @nickboldt). To build it yourself you can have a look at the PR check GitHub action.

For S390x support, or to contrubute to the effort, see https://issues.redhat.com/browse/CRW-3171

[RomanNikitenko]

Tested on s390x platform - yes - there are some problems on yarn install step:

@pdfruth
FYI
These changes should fix the problem