Add supporting of DeploymentConfig objects in OpenShift recipe

[sleshchenko]

The current implementation doesn't support deployment config objects in OpenShift recipe. It was implemented in this way because of a problem of matching environment configuration to containers specified by the recipe.

It was decided to obligate OpenShift recipe objects with the following limits:

• pod name in a template of deployment config is mandatory;
• pod name must be unique whole pod objects and templates of pods in deployment configs objects.
  So it means that the following recipe is invalid:

---
kind: List
items:
-
    kind: Pod
    metadata:
        name: pod1
    spec:
        containers:
        -
            name: main
            ...
-
    kind: DeploymentConfig
        metadata:
            name: dc
        spec:
            template:
                metadata:
                    pod1
                spec:
                    containers:
                    -
                        name: main
                        ...

Add supporting of DeploymentConfig objects in OpenShift recipe.
Note that deployment config will generate names for pods, and it is needed to put something on labels or annotations to link Running pod and environment machine.

[garagatyi]

@sleshchenko just to be on the same page: OS also supports pure deployment objects

[amisevsk]

I've lost detailed notes about implementing workspaces as DeploymentConfigs instead of Deployments, but I did leave a comment with a few issues encountered here.

Using DCs instead of Deployments means using OpenShiftClient internally instead of KubernetesClient, which has caused us issues at various times in the past. It could also potentially result in a fair bit of code duplication, as Deployments support is part of the Kubernetes infra but DeploymentConfig support would necessarily be OpenShift infra only.

[garagatyi]

We might need to redesign some stuff to achieve this. But it is one of the original goals of Workspace.Next to support different formats in their original format without just pulling out some of the data and ignore everything else. This is really important for a real case scenarios where user don't adapt their application definition to be able to use it in Che.

[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.

[gorkem]

/remove-lifecycle stale

[gorkem]

We need to support both Deployment and DeploymentConfig. Obviously DeploymentConfig will be OpenShift only. Priority is to add Deployment first though.

[amisevsk]

For clarity, Deployment support is already present. Part of the issue is that devfiles moved away from specifying workspace configuration as k8s/OS yaml and instead implements a lot of parallel functionality in its own spec. At this point, I believe this issue would be

1. Add a OpenShift component type in parallel to Kubernetes
2. Add support for DeploymentConfigs in this component type.

As it stands, most of our devfiles use dockerimage components, and much of what you'd find in a kubernetes-type component is duplicated in the devfile spec itself.

[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.