Support Template object in OpenShift recipe

[sleshchenko]

Description

Ideally, it would be nice to be able to create a workspace from origin user's application recipe.
Now we support only KubernetesList which is quite flexible BUT a usage of Template is a more common way to deploy user's application.
So, if a user uses Template for his application then he has to rewrite it in KubernetesList way to be able to run a workspace with it.

It would be nice to support Template as an object of OpenShift recipe.

Template may have required parameters which requires input from a user. For now, Che doesn't have a right place where the user would be able to init them. The proposal is to support Template in OpenShift recipe with one limitation: Template MUST NOT have any required parameters without default values. In this case, if the user has them in his application recipe - he needs to modify original content and add default values to parameters which is much easier to do than converting the whole Template to KubernetesList

[gazarenkov]

Definitely +1, thanks @sleshchenko

Talking about supporting existed configuration I would say it is more "must have" than "nice to" feature since it looks like Kubernetes List is quite a rare case of describing deployment in real life.

[sleshchenko]

The following issues are also about supporting real application description in Kubernetes/OpenShift format:

• Support Deployment object in Kubernetes/OpenShift recipe Support Deployment object in Kubernetes/OpenShift recipe #11505
• Support DeploymentConfig object in OpenShift recipe Add supporting of DeploymentConfig objects in OpenShift recipe #5967
• Support ConfigMap object in Kubernetes/OpenShift recipe Support ConfigMap object in Kubernetes/OpenShift recipe #11507
• Support Secret object in Kubernetes/OpenShift recipe Support Secret object in Kubernetes/OpenShift recipe #11508
• Support Route object in OpenShift recipe Support Route object in OpenShift recipe #11530

[gazarenkov]

@sleshchenko I would also say effective recipe (the one applied to Runtime) should contain all the objects from original configuration.
I.e. recipe processing may add/(may be some)modify BUT not remove anything even if it does not "understand" it.

[sleshchenko]

@gazarenkov

I.e. recipe processing may add/(may be some)modify BUT not remove anything even if it does not "understand" it.

Makes sense but I'm not sure that it is possible to create a resource trough K8s/OS Fabric8 client or Rest API resource if you don't understand it.
I've checked that OpenShift Web UI parses and creates objects one by one, like pods, then service, etc.
So, I think there is no way to create an object if client doesn't know what it is going to create, client should call the corresponding API Service.

[gazarenkov]

@sleshchenko
I see what you mean but in this case our implementation has to be aware of all the objects (including alpha and beta readiness).
I doubt primitive set of basic Kubernetes/OS object is enough for real app development.
So, I am afraid the choice is:

• support all of them, including upstream
• care about subset of them important for Che and let others just pass through

[l0rd]

Related to #11476

We can't support templates until we are able to split runtimes in separate pods.

[garagatyi]

I don't understand why separation of the runtime is a concern. I think that we can embed sidecars into the user's app.

[garagatyi]

But separating it would be definitely easier, so it might not make sense to just spend time on that at the moment

[l0rd]

Yes sorry you are right. We can support Templates. But we definitely can't support Controllers as DeploymentConfig, Job and StatefulSet that you usually find in a Template.

[gazarenkov]

From my side - convenient way of tools injecting is out of scope.
Simply adding/removing side-containers looks acceptable if I can use in my Workspace env exactly the same deployment (recipe) as supposed to be in staging/prod.
For the time it is not the case and IMO it is blocker for real life development.

As a side comment - yes, "side-pods" looks more attractive than "side-containers" but IMHO there are some (heavy) technology challenges like networking, volume_mounting etc which have to be addressed in general to be able to deploy on "any" infrastructure. Otherwise, documenting and supporting it will look like a nightmare.
In contrast to side-containers where all of this predictability provided by Kubernetes.

[garagatyi]

@amisevsk is there anything left for this issue or we can close it?

[amisevsk]

Can be closed as PR is merged.