Convert between 3rd party artifacts and workspace definiton

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.

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

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