REST API to create workspaces from a devfile

[benoitf]

Description

Currently there is a way to create a workspace from a devfile
https://github.com/eclipse/che/blob/master/wsmaster/che-core-api-devfile/src/main/java/org/eclipse/che/api/devfile/server/DevfileService.java#L98-L116

We can post a devfile content.

I would like to be able to create workspaces from content like this one: https://github.com/redhat-developer/devfile/blob/master/Devfile.yaml

Let say I'm a client like the dashboard where I could create content of such devfile, then this devfile is referencing other files by doing something like: local: petclinic.yaml

How could I submit such files through REST API ?

would it be something like MULTIPART_FORM_DATA / https://github.com/codenvy-legacy/che-core/blob/3.x/platform-api/che-core-api-factory/src/main/java/org/eclipse/che/api/factory/FactoryService.java#L166

or to submit content with a all-in-one format

---BEGIN DEVFILE---
content
---END DEVFILE---
---BEGIN petclinic.yaml---
content
---END petclinic.yaml---

something else ?

somehow related to #11549

[l0rd]

I know that we don't want to expose that to users but maybe supporting (server side) embedding the specification (petclinic.yaml) in the devfile would make easier for clients to call the API.

tool:
  kind: kubernetes
  spec:
      ...

[garagatyi]

@benoitf @l0rd what about using block inlining:

parent:
  child: |
    I can put anything here
    and it would be inlined
    but I still can still preserve
    structure so it looks good.
    Just remember to keep all the lines intended.

I used field content instead of field local for additional file.
Example of such a devfile:

---
specVersion: 0.0.1
name: petclinic-dev-environment
tools:
  - name: mysql
    type: kubernetes
    content: |
      kind: List
      items:
       -
        apiVersion: v1
        kind: Pod
        metadata:
         name: ws
        spec:
         containers:
          -
           image: 'eclipse/che-dev:nightly'
           name: dev
           resources:
            limits:
             memory: 512Mi
    selector:
      app.kubernetes.io/name: mysql
      app.kubernetes.io/component: database
      app.kubernetes.io/part-of: petclinic

Here is a demo of this feature implemented in devfile: https://youtu.be/gBIRNmQZNpY

[benoitf]

I think it's nice but I also think that ppl may want to use their existing k8s/minishift files. (so not trying to use inline content)

[garagatyi]

@benoitf building multi-part data or embedding content of files in a single text entry would also require files manipulation, so clients could replace local: <file name here> with

content: | 
<file content here>

Do you think that we also need to support multi-part in addition to a suggested approach?
If so, do you think that we don't need this inlined content approach (not sure whether it is convenient to do multi-part data on the browser client-side)?

[benoitf]

@garagatyi ok so this format is kind of client/server protocol. If the client is inlining files with that approach I think it's cool as well. But the server won't "un-inline" that content to separate files on server side. So we'll never be able so sync back these dev-files stored in a workspace to a devfile that a user could put into his repository later.

I referenced "multipart" just because server could be able to reconstruct the files in the same way they're locally.

Maybe it could be a good step1 as for now the workspace is never keeping devfile content for now and we could revisit later.

[benoitf]

@garagatyi adding to my previous comment.
if we could have

contentReference: 'local:foo.yml'
content: | 
<file content here>

maybe we could reconstruct on server side the same layout

[l0rd]

+1 as a first iteration with @benoitf contentReference addendum

[benoitf]

@garagatyi also names could be better than what I proposed :-)

could be as well

local: petclinic.yaml
localContent:  | 
<file content here>

or anything

[garagatyi]

@benoitf do you mean that we should preserve field local to show that it is a local file and also add field localContent with the content of the file. And on the server side we remove content from the devfile and put it into a representation of a local file?

[benoitf]

@garagatyi perfectly correct. But if you've other ideas/names that's fine

[garagatyi]

This would be reflected in the JSON Schema of devfile.
Let's consult with authors of the JSON Schema @l0rd @mshaposhnik @sleshchenko @skabashnyuk
WDYT guys about the changes suggested by Florent? If you are OK with them I'll work on it

[sleshchenko]

I'm OK with

local: petclinic.yaml
localContent:  | 
<file content here>

[l0rd]

I am ok as well

[skabashnyuk]

ok for me.