Out of main pod containers

[l0rd]

In current devfile spec there it is not possible to specify if a container will be run as part of the main dev environment pod[1] or if it should run in its own separated pod. In the v2.0.0 spec we would like to add a new field (dedicatedPod ) that can be applied to container components.

components:
  - container:
        image: maven
        dedicatedPod: true          # <-- Optional. Default value is false

[1] In Che the main pod is the pod where the editor and its plugins run.

[benoitf]

hi, in the comment there is a typo on "runIsnOwnPod" (is/in)

alternatives could it be like dedicatedPod: true or separatePod: true

[l0rd]

@benoitf thanks. Changed to dedicatedPod: true.

[metlos]

I think we should be careful with the endpoint definitions (#33).

If the default endpoint exposure is none (which is fine for single-pod workspaces), the following would IMHO be slightly hard to decipher to the user:

components:
  - container:
        image: postgresql
        dedicatedPod: true
        endpoints:
        - name: dbPort
          targetPort: 5432

This definition would make the endpoint unreachable from the rest of the workspace (default exposure is none).

[kadel]

```yaml
  - kubernetes:
       reference: https://.../mongo.yaml
       dedicatedPod: true

⚠️ If a Kubernetes component specifies a resource of type Pod or Deployment and dedicatedPod is set to false the containers definition will be extracted and included in the development environment Pod.

I'm afraid that using dedicatedPod: true as default for the Kubernetes component might be a little bit confusing. In most of the cases, the reason why I would use the Kubernetes component in Devfile is to create additional more complex resources (like Secretes, CustomResources, StatefulSets, or even Deployments with customized parameters like RollingStrategy etc..). For a lot of resources extracting ContainerSpec and combining it with the environment Pod won't even make sense.
Would it maybe make sense to invert the default in Kubernetes component to be dedicatedPod: false, otherwise 99% of Devfiles will to specify dedicatedPod: false

[l0rd]

@kadel I am ok with your proposal. @davidfestal @elsony what do you think about that?

[davidfestal]

I'm wondering whether the semantic of the dedicatedPod field would really be the same for container and kubernetes components. And obviously the expected default value for each one would not be the same as well:

• For container components we're trying to express that we want to force a container to run outside the workspace POD (default is inside)
• For kubernetes components we'd like to express that we want the containers involved in the kubernetes POD-like structures to be injected into the workspace POD (default is to create the kubernetes objects without any change).

So I'd rather start with the dedicatedPod field only for container components, and provide a distinct option the kubernetes component, possibly in a distinct issue.

[elsony]

+1 for the default value of dedicatedPod to be false. That's the mode that I foresee the majority of the containers are.
One thing that I'd like to confirm is the lifecycle of the pod if dedicatedPod is set to true. I assume that pod will still gets cleaned up properly when the removing the workspace.

[l0rd]

Edited the description, discussed and agreed.