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

[amisevsk]

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:

• java-maven rh-che #1347 Adding Che 7 java-maven upstream stack #1420 / Che 7 java-maven stack is not fully functional on che.openshift.io eclipse-che/che#13383
• java-gradle Che 7 java-gradle stack is not working on che.openshift.io eclipse-che/che#13384
• go
• python
• .NET
• Apache Camel
• PHP (not yet in upstream master)
• Node (not yet in upstream master)

Sub tasks:

• Most public images do not work as the base for Che 7 workspaces on OpenShift Most public images used in devfile registry do not work as the base for Che 7 workspaces on OpenShift eclipse-che/che#13454

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

• Need to make sure that all devfiles from registry work on che.prod-preview.openshift.io #1434

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]

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]

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]

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]

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]

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]

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]

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]

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

[l0rd]

@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]

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

[l0rd]

@ibuziuk ok for me

[amisevsk]

Closing in favor of #1434