Skip to content
This repository has been archived by the owner on Mar 17, 2021. It is now read-only.

Use upstream che 7 stacks as-is in rhche without any customizations #1347

Closed
10 tasks
amisevsk opened this issue Apr 4, 2019 · 12 comments
Closed
10 tasks

Use upstream che 7 stacks as-is in rhche without any customizations #1347

amisevsk opened this issue Apr 4, 2019 · 12 comments

Comments

@amisevsk
Copy link
Collaborator

amisevsk commented Apr 4, 2019

Description:
PR eclipse-che/che#12898 fixes various issues with stacks in upstream Che. We should port those changes over to the fabric8 stacks.

List of che 7 stacks that should be available on che.openshift.io for GA:

Sub tasks:

also, we need to test all devfiles that would be available in the devfile registry:

Stack images Acceptance Criteria

These are the things that we should verify to validate a particular stack

  • workspace containers can be started
  • terminal shell for the runtime container(s) is bash (git PS1 is nice to have)
  • HOME is set
  • No "User has no name" problem
  • devfile commands can be executed successfully

Stack Language Servers Acceptance Criteria

  • code completion works successfully
  • code navigation works successfully
  • debugging works successfully
@ibuziuk
Copy link
Member

ibuziuk commented Apr 5, 2019

also since che 6 gradle factory is pretty unusable atm it is a very good time to replace it with che 7 equivalent - #1344

@amisevsk
Copy link
Collaborator Author

Before proceeding much farther in this issue, we should clarify what the purpose and goal of redhat-devleoper/che-dockerfiles is going forward.

We're currently using the upstream che-dev image for che7 workspaces, which has none of the modifications we do downstream (and is based off Debian IIRC). Additionally, che-dev is quite general-purpose; it has maven, java, node, tomcat, etc. installed by default, and we might want to move away from that.

I've got some semi-working che7 maven and gradle stacks, but there seem to be some UID issues (user in dev machine is different from /home/user, and importing user's bash profile causes a few issues). Personally I think we should consider keeping che-dockerfiles around as a repo for at least base images for running on our clusters, but am open to suggestions.

@l0rd @ibuziuk WDYT?

My current WIP is here

@l0rd
Copy link
Contributor

l0rd commented Apr 16, 2019

What I would really like is that we just take existing images and reuse them as they are. It doesn't matter if it's for che.openshift.io, upstream or codeready worksapces: in all 3 platforms we want users to be able to run their stack without any modification and rebuild of the images.

Now the challenge on OpenShift is that by default the containers are started as arbitrary users. In particular:

  1. the arbitrary user may not have the privileges to read/write some folders
  2. in /etc/passwd there is no entry for that arbitrary user

I think that problem 1. is mitigated by some OpenShift-ready images (e.g. the centos ones) but I haven't found any image that does the envsubst trick. As a consequence some applications will have issues. One example is mvn that won't know where to create the .m2 folder and creates a ? folder in the current working directory. That only solution I have found currently is to use mvn -Duser.home=${HOME}. Gradle works fine if we set the right env variable (GRADLE_USER_HOME="/home/user/.gradle").

That said I have tested a Che 7 Java-maven stack replacing the recipe image with fabric8/s2i-java:latest-java11 and it worked fine.

@ibuziuk
Copy link
Member

ibuziuk commented Apr 16, 2019

What I would really like is that we just take existing images and reuse them as they are. It doesn't matter if it's for che.openshift.io, upstream or codeready worksapces: in all 3 platforms we want users to be able to run their stack without any modification and rebuild of the images.

👍

Now the challenge on OpenShift is that by default the containers are started as arbitrary users

@l0rd currently should we use s2i based images for che 7 for now on che.openshift.io to avoid these issues or somehow try to contribute required fixes to the images used in upstream recipes?

@l0rd
Copy link
Contributor

l0rd commented Apr 16, 2019

I think going with s2i images would be the right choice. And I would like to stress again that this is not a che.openshift.io specific issue. Che users and crw customers running on OpenShift will face this issue.

@amisevsk
Copy link
Collaborator Author

Ok, I'll look into it more, thanks @l0rd and @ibuziuk.

It looks like the current che-dev image is working becuase of its entrypoint

@ibuziuk
Copy link
Member

ibuziuk commented Apr 25, 2019

Need to test upstream stacks as-is on che.openshift.io and do not override anything on rh-che: e.g centos/python-36-centos7:1 from https://github.com/sclorg

  • same images should work on both k8s / openshift

if image works we add new stack in rh-che, if it is not we open issue upstream

@ibuziuk ibuziuk modified the milestones: Sprint #165 (Che OSIO), Sprint #166 (Che OSIO) May 2, 2019
@ibuziuk ibuziuk changed the title Port upstream stacks changes to rhche Use upstream che 7 stacks as-is in rhche without any customizations May 2, 2019
@ibuziuk
Copy link
Member

ibuziuk commented May 13, 2019

Not sure if we need a new issue for that but, theia:next is currently the default editor in the upstream - on rh-che all che 7 stacks should also use theia:next by default (currently on che.openshift.io 1.0.0is still used) eclipse-che/che#13235

PR sent - #1414

ibuziuk added a commit to ibuziuk/rh-che that referenced this issue May 21, 2019
Signed-off-by: Ilya Buziuk <ibuziuk@redhat.com>
@ibuziuk ibuziuk modified the milestones: Sprint #166 (Che OSIO), Sprint #167 (Che OSIO) May 22, 2019
ibuziuk added a commit that referenced this issue May 22, 2019
Signed-off-by: Ilya Buziuk <ibuziuk@redhat.com>
@l0rd
Copy link
Contributor

l0rd commented Jun 26, 2019

@amisevsk I have added a list of acceptance criteria to the issue description (cc @slemeur). I may miss something so please update. I have splitted acceptance criteria in 2 because I believe that those could become 2 independent automated tests suites to use as PR checks on che-plugin-registry and (language servers / debug adapters repos?)

@ibuziuk
Copy link
Member

ibuziuk commented Jul 3, 2019

@l0rd are you ok to close this issue in favor of #1434 and move the acceptance criteria there?

@l0rd
Copy link
Contributor

l0rd commented Jul 3, 2019

@ibuziuk ok for me

@amisevsk
Copy link
Collaborator Author

Closing in favor of #1434

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants