Ambiguity over exec & apply commands for preStart & postStop

There is a semantic difference between exec and apply commands and when one should use them. For example,

exec commands are commands that are required to be executed only when a container is up and running.
apply commands are commands that are typically applied for example during preStart and postStop events, when a pod is not present.

However, having personally worked on Odo's preStart feature, this is not the case. Odo currently utilizes only exec and composite commands in its product. This is the case for preStart as well, where a preStart event is an exec command. The container component's command & args(image's command & args if the devfile container command & args are absent) are overridden by the exec command's commandLine & workingDir.

This is different to what the authors of the spec initially intended. The apply command's container component image command & args are to be used as preStart or postStop commands.

Having mentioned that, there is a use-case where we can utilize an exec command for preStart/postStop when the dedicatedPod in the container component is set to true. This use case can be useful and valid when a separate pod is required to that of the main pod. The dedicated pod can utilize the pvc volumes defined to execute its preStart & postStop actions whose data could be accessed by the main pod via the pvc volumes.

Agree with the proposed behaviour and need to update the schema description to describe this behaviour. Add a restriction to not allow using dedicatedPod with preStart/postStop.

@l0rd

@l0rd @davidfestal Can a composite command have apply commands as sub-commands? If yes, can the composite command be used as a preStart/postStop event.. Though the parallel property would not work in case of preStart as initContainers are executed sequentially always.

We probably should try to avoid making the logic too "smart". If our rule is to only allow apply command to be specified as the preStart/postStop command (not exec), then a composite command can only be used only if all of the containing commands are apply commands. If the composite command happens to contains a mix of exec and apply, then that command cannot be used as preStart/postStop command and it should fail in our validation.

@elsony

agree with @elsony

This is getting way too complicated.
In the current description for preStart we are saying that on Kubernetes preStart is implemented as initContainer. But apply command can reference for example kubernetes component.

schemaVersion: 2.0.0
metadata:
  name: fail
  version: 1.0.0
components:
  - name: tools
    container:
      image: quay.io/eclipse/che-java11-maven:nightly
  - name: asdf
    kubernetes:
      inlined: >
        apiVersion: batch/v1
        kind: Job
        metadata:
          name: hello
        spec:
          template:
            spec:
              containers:
              - name: hello
                image: busybox
                command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
              restartPolicy: OnFailure
  - name: m2
    volume: {}
commands:
  - id: asdf
    apply:
      component: asdf

events:
  preStart:
    - asdf

Now, this doesn't make sense at all.
We need to create additional restrictions on what component types can be used with apply in preStart. Only container component should probably be allowed.

@l0rd

Apply of a container component at preStart is translated into a Kubernetes initContainer inside the main POD.

But I never understood this rule applied to other types of components.
In case of a kubernetes components, I assume that the apply on preStart would simply create the corresponding Kubernetes objects before the main POD is started.

@l0rd Am I remembering well here ?

In case of a kubernetes components, I assume that the apply on preStart would simply create the corresponding Kubernetes objects before the main POD is started.

This could make sense. But we need to be carefull. Because this behavior is a lot different from using InitContainer.
InitContainer guarantees that the command will exit successfully and the Pod/Workspace won't start before it exits. With apply on kubernetes component we can't guarnetted neither of that. This means that the behavior of preStart can be slightly different based on the command types used

Not saying that this is a big problem, we just need to me make sure that users understand this. It needs to be clearly documented.

@davidfestal

@davidfestal @kadel This is a bit off topic with the current issue but since we're talking about kubernetes/openshift components, how are kubernetes/openshift components generally expected to be executed? Are they supposed to be tied to an apply/exec command? devfile v1 Che guide gives an example of a kubernetes type component being executed with an exec command - https://www.eclipse.org/che/docs/che-7/end-user-guide/importing-kubernetes-applications-into-a-workspace/. If you look at our devfile v2 command desc for exec and apply, it says exec is executed in an existing component container and apply is applying a given component definition, typically bound to a workspace event

Coming back to this issue, do we want apply command to be associated with a non-container component for preStart/postStop? Maybe that restriction is specifically for odo i.e., apply events are associated with a container component.

This issue is stale because it has been open for 90 days with no activity. Remove stale label or comment or this will be closed in 60 days.

Navigation Menu

Repository navigation

Ambiguity over exec & apply commands for preStart & postStop #204

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Ambiguity over exec & apply commands for preStart & postStop #204

Description

Activity

elsony commented on Nov 3, 2020

maysunfaisal commented on Nov 4, 2020

elsony commented on Nov 5, 2020

l0rd commented on Nov 6, 2020

kadel commented on Feb 3, 2021

davidfestal commented on Feb 3, 2021

kadel commented on Feb 3, 2021

maysunfaisal commented on Feb 3, 2021

github-actions commented on Jul 10, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions