Part 1 of the series on enabling the DevWorkspace Operator as workspace engine #4
Conversation
…ce engine Signed-off-by: Mario Loriedo <[email protected]>
_posts/2021-10-12-devfile-v2-and-the-devworkspace-operator-p1.md
Outdated
Show resolved
Hide resolved
_posts/2021-10-12-devfile-v2-and-the-devworkspace-operator-p1.md
Outdated
Show resolved
Hide resolved
_posts/2021-10-12-devfile-v2-and-the-devworkspace-operator-p1.md
Outdated
Show resolved
Hide resolved
_posts/2021-10-12-devfile-v2-and-the-devworkspace-operator-p1.md
Outdated
Show resolved
Hide resolved
_posts/2021-10-12-devfile-v2-and-the-devworkspace-operator-p1.md
Outdated
Show resolved
Hide resolved
_posts/2021-10-12-devfile-v2-and-the-devworkspace-operator-p1.md
Outdated
Show resolved
Hide resolved
_posts/2021-10-12-devfile-v2-and-the-devworkspace-operator-p1.md
Outdated
Show resolved
Hide resolved
_posts/2021-10-12-devfile-v2-and-the-devworkspace-operator-p1.md
Outdated
Show resolved
Hide resolved
_posts/2021-10-12-devfile-v2-and-the-devworkspace-operator-p1.md
Outdated
Show resolved
Hide resolved
Co-authored-by: Michal Vala <[email protected]>
Co-authored-by: Michal Vala <[email protected]>
Co-authored-by: Michal Vala <[email protected]>
Co-authored-by: Lukas Krejci <[email protected]>
Co-authored-by: Lukas Krejci <[email protected]>
Signed-off-by: Mario Loriedo <[email protected]>
_posts/2021-10-12-devfile-v2-and-the-devworkspace-operator-p1.md
Outdated
Show resolved
Hide resolved
_posts/2021-10-12-devfile-v2-and-the-devworkspace-operator-p1.md
Outdated
Show resolved
Hide resolved
| - It introduces the volume component type. | ||
| - Events and parent are two new components types. | ||
| - Besides Che it’s used by the OpenShift Developer Console, `odo` and the [Devfile Docker plugin](https://github.com/devfile/devfile-docker-plugin). | ||
|
|
There was a problem hiding this comment.
- it introduces Universal Developer Image
|
|
||
| ### A new way to specify the editor and its plugins | ||
| As mentioned above, version 2 of the Devfile, doesn’t include cheEditor and chePlugins component types anymore. | ||
|
|
There was a problem hiding this comment.
There was a problem hiding this comment.
Thanks, that's a good point. I have added the reference.
Co-authored-by: Florent BENOIT <[email protected]>
Co-authored-by: Florent BENOIT <[email protected]>
Signed-off-by: Mario Loriedo <[email protected]>
| metadata: | ||
| name: python-hello-world | ||
| attributes: | ||
| che-theia.eclipse.org/sidecar-policy: USE_DEV_CONTAINER |
There was a problem hiding this comment.
theia attributes should not be a part of devfile I believe.
Instead, it should be defined somewhere in .che/che-editor.yaml
and if this is a default policy, then better to omit it in any case
| mountSources: true | ||
| - name: venv | ||
| volume: | ||
| size: 1G |
There was a problem hiding this comment.
Just note that size does not any effect anything in devworkspace
| registryUrl: https://my-registry.com # optional | ||
| override: # optional | ||
| containers: | ||
| - name: theia-ide |
There was a problem hiding this comment.
Is it already published? Since AFAIK it's not implemented yet, so would be good to avoid confusion and ask users to try out something that is not going to work.
Update: Alright, that's already published https://che.eclipseprojects.io/2021/10/12/@mario.loriedo-devfile-v2-and-the-devworkspace-operator-p1.html
|
|
||
| With version [7.28 of Che](https://github.com/eclipse/che/releases/tag/7.28.0) we have introduced a new workspace engine, [the DevWorkspace Operator](https://github.com/devfile/devworkspace-operator), that supports v2 of the Devfile specification. Although the default engine is still the che-server we plan to replace it with the DevWorkspace in the next few months. | ||
|
|
||
| Switching to the DevWorkspace engine has some important consequences. Notably on the authentication subsystem that will be lighter and more flexible, on the workspaces network managed by a central gateway powered by [Traefik](https://github.com/traefik/traefik) and simpler configuration options for Che administrators. |
There was a problem hiding this comment.
lighter is more or less true for OpenShift, but I would say not for Kubernetes (at least for local).
It makes sense to note that on Kubernetes now we require OpenID provide(or OAuth, I'm not sure)
But yeah, that's not something we already support. And on kubernetes we still depends on Keycloak.
Update. Ah, that's delayed till next blogpost:
Keycloak is not required anymore and Che users have to be Kubernetes users
| Having the Devfile at the root of a repository makes it possible to use a simple factory link to the repository to start the workspace. For example [workspaces.openshift.com/#https://github.com/eclipse/che-docs](https://workspaces.openshift.com/#https://github.com/eclipse/che-docs) is a factory link: when a user click on it, a workspace defined by the Devfile in the repo [github.com/eclipse/che-docs](https://github.com/eclipse/che-docs) will be started on the public Che instance hosted by Red Hat at workspaces.openshift.com. | ||
|
|
||
| Recommending to colocate and evolve a v2 Devfile with the source code has two consequences: | ||
| - the `project` section of a Devfile can be omitted: it’s implicitly set to the git repo where the Devfile lives |
| - Che samples will include a Devfile at their root (those Devfiles used to be published in the Devfile registry) | ||
|
|
||
| ### Only one running workspace per user | ||
| A user cannot have more than one running workspace at a time. This limitation is related to the persistent volume strategy (“common”) that is used by Che. The same Volume is mounted by every workspace of the same user. This is implemented using Pods `volumeMounts.subPath` property and guarantees that the number of Volumes mounted by Che matches the number of users. |
There was a problem hiding this comment.
The same Volume is mounted by every workspace of the same user
Volume -> PersistentVolume not to initiate confusion with devfile volume
This is implemented using Pods
volumeMounts.subPathproperty and guarantees that the number of Volumes mounted by Che matches the number of users.
This mixes two stuff:
- volumeMounts.subPath: the way we isolate files of different workspace in one PV
- show a motivation why we stick to one PV per user.
Signed-off-by: Mario Loriedo [email protected]