Convert between 3rd party artifacts and workspace definiton

[gorkem]

It is very often that developers start their development with an external code generation tool that does not generate a Che workspace definition, or have an existing application that they want to continue to develop with Che. Currently Che does not provide a way to import and existing application or infrastructure definition and convert it to a workspace. Similarly when a workspace is created via Che's own UI there are no tools provided for exporting a 3rd party definition that can be used to deploy the developed application.

Convert to workspace

This feauture should analyze the 3rd party artifact and convert it to a che workspace definition with the goal of enabling further development. System can determine during the analysis that it requires further information to create the workspace definition. Depending on the interface used the additional information can be provided by the developer, because some interfaces (3I&F) like factories will not be able to provide interaction, feature should be able to provide some defaults.

Workspace engine should try to determine the minimum required tooling for the converted workspace and provision them into the definition.

Some of the conventions, standards that exists and being developed for applications definitions

• Selector arguments see label and annotation proposal

Supported 3rd party tools/artifacts

• kubernetes/openshift object models (yaml/json)
• Helm charts

Export workspace

Che should have an option to export a workspace definition to a 3rd party format. This export can include only the information that is relevant to runtime and omit the development time information.

Supported 3rd party tools/artifacts

• kubernetes/openshift object models (yaml/json)

Question: Should we try to implement a label/annotation standard for kubernetes that can capture the tooling information on workspace and be a replacement for workspace definition.

Defining collaborators (aka multi-container workspaces)

Application should be able to define its collaborators on a workspace from an infrastructure. For instance, this should allow a 10 microservice application’s only 2 microservice to be modified as part of the workspace while the rest are used either as new deployments that are part of the workspace or in place as defined on the kubernetes deployment.

Standard Services

It should be possible to create a workspace by referring to one or more standard services provided by service brokers. For instance a developer should be able to use the CLI friendly name of a service provided by a service broker. See the Service object on the Open Service Broker API in particular the name field and also the tags field can be used to find out more about the service.

Q: What to do on infrastructures that does not have a service catalog? One option is to implement a Che's selection of stacks as a catalog.
Q: Can we depend on the instance created by broker service on Che? Do we need to create the instance of the service Che way.? How can we reach to the info for the service if we need to.

Depending on the referenced services workspace engine may need to determine a minimal set of tools to provision along the service to enable development.

[skabashnyuk]

@gorkem is this UI (dashboard) mostly issue? Or this requires some server-side logic from your point of view?

[gorkem]

@skabashnyuk It is not strictly dashboard. We need a backend that can understand kubernetes.yml (or any other supported configuration) and transform that into a workspace. Similarly, it should be capable of exporting a workspace to a kubernetes configuration. Dashboard is definitely a client for this backend but we also need this to be a backend that could accommodate different clients for instance a CLI or a service like OSIO.

In this task I mention a UI for selection of parts to a workspace. However one can imagine the selection to be just annotation/tags on the configuration file, where an application generator like helm charts could just create those annotations that would allow us to create workspaces.

[skabashnyuk]

I thought the way to import/export recipe is pretty straightforward
you need to put your recipe in the content field of workspace config.
This is an example for docker compose.

          "recipe": {
            "content": "services:\n db:\n  image: centos/mysql-57-centos7\n  environment:\n   MYSQL_ROOT_PASSWORD: password\n   MYSQL_DATABASE: petclinic\n   MYSQL_USER: petclinic\n   MYSQL_PASSWORD: password\n  mem_limit: 1073741824\n dev-machine:\n  image: eclipse/centos_jdk8\n  mem_limit: 2147483648\n  depends_on:\n    - db",
            "contentType": "application/x-yaml",
            "type": "compose"
          }

I assume for kubernetes.yml it would be looking the same at that time when we implement
kubernetes support.

[benoitf]

maybe this backend should also handle the addition of all tooling used to bootstrap the provided infrastructure (like adding sidecars for IDE, LSP, etc) on top the provided file.

in short : for example, turning a user openshift yaml into a workspace with all tooling added.

[skabashnyuk]

maybe this backend should also handle the addition of all tooling used to bootstrap the provided >infrastructure (like adding sidecars for IDE, LSP, etc) on top the provided file.

@benoitf Do you have concrete algorithm how to do that just looking on kubernetes.yml?

[garagatyi]

I think what @benoitf says can be achieved by declaring an infrastructure agnostic entities that match to user's environment if needed. Such as installer button. We can somehow use sidecar or agent entity to declare that there should be something that provides some functionality but the definition of the environment can be infrastructure-specific and should be applied in Che internals.
@benoitf Am I right?
If so, this doesn't solve suggested by @gorkem workflow of alternating environment parts for the development flow I suppose.

[gorkem]

The recipe field on the workspace configuration is not enough because.

1. It is humanly not possible to edit in place, it is a document embedded into another one. Nobody wants to edit "\n" characters
2. What is included on the recipe is a subset of the actual runtime environment that is on the workspace for instance information such as routes are not available on recipe.

We want to make it super easy for anyone wishing to use Che for developing their existing application defined on a cloud way. That means today we need to accommodate, things like a kubernetes yaml config, Helm or such application definition formats. We had a pretty good chance of defining our own configuration based on workspace configuration of Che perhaps 6-9 months ago if we could have made it more generic and provided tooling. I feel that train has left the station now.

Of course the other direction where an application starts its life on Che as a workspace and ends up being deployed to cloud should also be possible. Che should be able to export a deployable kubernetes config for instance.

Of course, kubernetes yaml does not have enough information to create a workspace from. So we need either something like dashboard or a CLI to help specify additional questions. Also I think we can use things like metadata constructs. (Think annotations on a kubernetes yaml) to specify missing pieces for a workspace.

[garagatyi]

It is humanly not possible to edit in place, it is a document embedded into another one. Nobody wants to edit "\n" characters

In my opinion, it is just a matter of not appropriate IU/UX. I'm sure we can provide good UI where it is not needed.

What is included on the recipe is a subset of the actual runtime environment that is on the workspace for instance information such as routes are not available on recipe.

If you mean that routes that are added by Che (for servers exposure) then yes - they are not available. But this looks expected I think since it is part of the framework that doesn't force a user to understand all the underlying complexity of the system.

[gorkem]

I have almost rewritten this one, hopefully it is more clear now.

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

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