Post start commands should be run detached

[l0rd]

Is your enhancement related to a problem? Please describe

Workspaces Pod is stuck in PodInitializing status until postStart command doesn't complete.

This can be tested with the devfile in this repository where the postStart command is tail -f /dev/null and the workspaces never starts:

schemaVersion: 2.2.0
(...)
commands:
(...)
  - id: neverendingcommand
    exec:
      label: "8. Tail /dev/null"
      component: tools
      commandLine: |
        tail -f /dev/null
      group:
        kind: build
events:
  postStart:
    - neverendingcommand

Describe the solution you'd like

A postStart event should never block the workspace startup. The command should run detached. One way to do that would be to prefix the command with nohup and suffix it with &:

A command in a devfile or devworkspace should then be transformed into a container lifecycle postStart like the following one:

      lifecycle:
        postStart:
          exec:
            command:
              - 'nohup'
              - 'tail'
              - '-f'
              - '/dev/null'
              - '&'

[amisevsk]

DWO PR https://github.com/devfile/devworkspace-operator/pull/1081 updates how postStart events are handled. However, it does not run all commands detached, as there is more risk of breaking commands if they are run in this way. Detaching all commands would mean that the container could be started before required commands complete.

[l0rd]

Detaching all commands would mean that the container could be started before required commands complete.

@amisevsk what scenario do you have in mind? Because the scenario I have in mind is when post start is used to run mvn package (or any command to build / test / run the application) and the IDE startup should not be blocked by that. But I am afraid I am missing some important scenario where it makes sense for the container to be started after.

[amisevsk]

I don't have a specific example in mind -- my main concerns are

• This makes detatch behavior mandatory, whereas now it's possible to choose (we can always nohup mvn package & instead of just mvn package). This is a break from how poststart works in kube-land
• It makes the rewriting/combining that DWO has to do more complicated and error prone -- we already have to combine a series of arbitrary commands, and doing more to manipulate them raises the chances something goes wrong

We can continue to look into it, but I feel like the risks potentially outweigh the gains.

[l0rd]

Ok let's put that on hold for now and wait to see if there is any user/customer complain.

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[amisevsk]

/remove-lifecycle stale