Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Che 7 Stacks #12620

Closed
31 of 77 tasks
l0rd opened this issue Feb 6, 2019 · 14 comments
Closed
31 of 77 tasks

New Che 7 Stacks #12620

l0rd opened this issue Feb 6, 2019 · 14 comments
Labels
kind/task Internal things, technical debt, and to-do tasks to be performed. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.

Comments

@l0rd
Copy link
Contributor

l0rd commented Feb 6, 2019

Description

For Che 7 we want to release some new stacks that use the new ws.next based model and theia as editor.

Stacks guidelines

  • User runtime components:
    • Use official images: instead of building and maintaining our own java, python, go etc...docker images we should rather leverage the official upstream ones (usually on the DockerHub). That has 2 advantages (1. we do not need to maintain them 2. we make sure that Che workspaces work with images built by the community and not only with images from che-dockerfiles) and one drawback (there may be some caveates like permissions and tools that we need to deal with).
    • Override entrypoint: usually the official images have a terminating entrypoint. To avoid that the container exits right away we have to override it:
      "containerCommand": "['sleep']",
      "containerArgs": "['infinity']"
    • Specify images versions and ideally we should use image SHA1 hash
  • Memory settings. Workspaces are composed by an editor (usually Theia), one or more language servers and other plugins and a user runtime. We should provide enough memory for all of these components but we should avoid to require more than 4GB (3GB is current che.openshift.io limit):
    • Theia: 512MB should be enough ("sidecar.org.eclipse.che.editor.theia.memory_limit": "512Mi")
    • Language servers and other plugins: it depends on the particular plugin but every plugin should be tested to find the lower limit in the particular stack with the samples we provide. Once we have found the right value the memory limit should be set as a workspace configuration attribute: "sidecar.org.eclipse.che.vscode-redhat.java.memory_limit": "1024Mi"
    • User runtimes: same as language servers and other plugins but the memory should be set as a container attribute: "memoryLimitBytes": "512000000".
  • Use Theia version next
  • No default commands: it doesn't make sense to add default commands at the stack level. Commands should be defined at sample level.
  • No servers: a Theia plugin is able to automatically figure out what ports need to be exposed, hence there is no need to spcify servers and preview urls anymore
  • Tips to fix issues on OpenShift
    • Set HOME=/home/user: arbitrary users don't have a home folder defined in /etc/passwd hence we should define one and the convention is to set it to /home/user
    • Use volumes to bypass folders permissions: arbitrary users have restrictive access to some folders in runtime container. If the processes running in the container (e.g. mvn) need to access the folder a trick is to mount the folder as a volume:
    "volumes": {
      "m2": {
        "path": "/home/user/.m2"
    }}
    • define PS1: to have a nicer terminal we can configure PS1 environment variable
  • Samples
    • Macro do not work on Theia (${current.project.path}): use environment variables instead and use the sample folder. For example: cd ${PROJECTS_PATH}/java-web-simple.
    • As for the user runtime components we should prefer samples that we do not need to maintain (i.e. vertx samples)

Current issues

Stacks list

Java

NodeJS

Python

.NET Core

Go

PHP

Che Development

Other misc

@slemeur slemeur mentioned this issue Feb 6, 2019
69 tasks
@l0rd
Copy link
Contributor Author

l0rd commented Feb 6, 2019

cc @slemeur

@ghost ghost added the kind/task Internal things, technical debt, and to-do tasks to be performed. label Feb 25, 2019
@l0rd l0rd self-assigned this Mar 5, 2019
@l0rd l0rd mentioned this issue Mar 19, 2019
@slemeur
Copy link
Contributor

slemeur commented Mar 20, 2019

Updated with a more complete list to be targeted for GA

@slemeur slemeur changed the title New Che 7 Beta Stacks New Che 7 Stacks Mar 20, 2019
@l0rd l0rd removed their assignment Mar 20, 2019
This was referenced Mar 20, 2019
This was referenced Apr 5, 2019
@tsmaeder
Copy link
Contributor

tsmaeder commented Apr 9, 2019

@l0rd @slemeur no PHP stacks?

@tsmaeder
Copy link
Contributor

tsmaeder commented Apr 9, 2019

@l0rd how can we have a camel stack if we don't have a camel plugin yet?

@tsmaeder tsmaeder mentioned this issue Apr 9, 2019
@tsmaeder
Copy link
Contributor

tsmaeder commented Apr 9, 2019

About quarkus: if we are talking about building native programs, the target would be any image that has the necessary libraries. In the end, there is no "server" to be installed.

@tsmaeder
Copy link
Contributor

tsmaeder commented Apr 9, 2019

Che server dev stack needs Golang, no?

@l0rd
Copy link
Contributor Author

l0rd commented Apr 9, 2019

@l0rd how can we have a camel stack if we don't have a camel plugin yet?

A copy/paste issue. Fixed now. Thanks

About quarkus: if we are talking about building native programs, the target would be any image that has the necessary libraries. In the end, there is no "server" to be installed.

Agree. I was thinking about an image where the quickstart sample was pre-built so that the developer can get started quickly.

Che server dev stack needs Golang, no?

I don't think so. I think Golang was only used for the exec agent but in Che 7 that's a separate plugin.

@slemeur
Copy link
Contributor

slemeur commented Apr 9, 2019

@l0rd + @tsmaeder : Added PHP.

@nickboldt
Copy link
Contributor

So will we SUPPORT all these stacks, or will only a subset of these be Red Hat GA-level supported? Right now for CRW 1.x / Che 6 we only support Node8 and Java8, with the rest being community-supported. I've opened https://issues.jboss.org/browse/CRW-225 to track the downstream specs.

@nickboldt
Copy link
Contributor

Che server dev stack needs Golang, no?

I don't think so. I think Golang was only used for the exec agent but in Che 7 that's a separate plugin."

Not sure if it's relevant but the Che 6 operator (and the CRW 1.x operator) both rely on golang too:

https://github.com/eclipse/che-operator/blob/master/Dockerfile#L13

@l0rd
Copy link
Contributor Author

l0rd commented Apr 17, 2019

@nickboldt good point. I have added a Che operator stack, it should not be part of the che-server stack though.

@tsmaeder
Copy link
Contributor

@l0rd @slemeur golang chag example is broken, see #13176. Ok to strike that one?

@l0rd
Copy link
Contributor Author

l0rd commented Apr 26, 2019

@tsmaeder +1

@che-bot
Copy link
Contributor

che-bot commented Dec 30, 2019

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 che-bot closed this as completed Jan 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/task Internal things, technical debt, and to-do tasks to be performed. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.
Projects
None yet
Development

No branches or pull requests

5 participants