Wokspaces are not loaded when che starts as a container

[Alexpud]

The problem is very similar to the one reported in #1410, i experienced the same problem today and was able to solve it.

But when i launched the che-server, the new way to launch che as a docker container, the same problem appeared. I tried to export the CHE_CONF_DIR=/home/user/che and it made no change. I can execute workspaces and all, but they are not shown in the dashboard. I have several workspaces folders in the container but no workspace is shown in the dashboard. Also, theres only preference.json inside the storage folder on CHE_HOME.

As a test, i tried to see if i was mounting directories the wrong way, i mounted the same directories on the codenvy/che images, and it worked. But on che-launcher didn't.Don't know if theres any relation.

So my questions is:
At the current stage of the che-laucher, is there a way for me to see the workspaces created?

Thank you.

[TylerJewell]

We have resolved all of the issues with #1410 - and we have tested this pretty vigorously. So perhaps is a way that you are setting up your host.

Can you tell us the OS, the OS version, the values of any CHE_ variables and then the exact syntax you used to start Che?

[Alexpud]

I use ubuntu 16.04 and 14 both x64, as to the CHE_variables i use:

OS:

Ubuntu

OS versions:

16.04 and 14, both x64.

Che environment variables:

CHE_CONF_FOLDER=/home/user/che/conf or i try to mount my own configuration file but to no effect; I set CHE_HOST_IP=${IP}, i set my host machine IP, the same one i use when i run che locally as a server.

Heres an image, i connected through bash to the che-server container.

[TylerJewell]

@Alexpud - can you also provide the syntax used to launch Che on the command line?

So, the syntax for starting / stopping che has changed with 4.6.2 in the Che Launcher. Notice that some of the variables are different between the Che launcher and the Che server. The Che launcher is an OS-agnostic way to simplify launching the Che Server, which is a container that runs as a daemon.

The environment variables for the launcher and the server are a bit different, and the launcher passes along a simpler set of variables onto the server, if appropriate.

New syntax:
https://eclipse-che.readme.io/docs/usage-docker

In particular:
CHE_CONF_FOLDER is for che.properties configuration.

However:
CHE_DATA_FOLDER is now for your workspaces and project storage.

So maybe this is the issue?

[Alexpud]

@TylerJewell
Now that you said, i realized i was using the environment variables wrong and corrected them, so i did not want to post the wrong command since i thought it wouldn't be helpful.

I ran the command bellow, it created the folder configuration and within it created the storage and workspace folders.

docker run --net=host -v /var/run/docker.sock:/var/run/docker.sock -e CHE_DATA_FOLDER=/home/boss/configuration -e HOST_IP=192.168.25.8 eclipse/che start

Then i created a workspace and a project, started and stopped it, after it i stopped the che-server container. I checked the storage folder, and it only contained the preferences.json and the folder of the workspace i created was empty.

[TylerJewell]

I think your -e CHE_HOST_IP=192.168.25.8 has the wrong variable in it. But that shouldn't be related to the workspaces not getting saved to the directory.

Humor me, please, and replace eclipse/che with codenvy/che-launcher:nightly. Also, pass in -e CHE_VERSION=nightly as well.

[Alexpud]

Ok i executed the following command:

docker run -v /var/run/docker.sock:/var/run/docker.sock -e CHE_DATA_FOLDER=/home/boss/datafolders -e CHE_VERSION=nightly codenvy/che-launcher:nightly start

And the problem persisted, storage folder created but only with preferences.json file inside it.

[TylerJewell]

Something is looking fishy - this was exhaustively tested. And we have #2123 - which is starting to look like a similar issue, but that is on Windows system.

[TylerJewell]

Humor me for one last try - I have a suspicion of what is happening. If you set CHE_DATA_FOLDER=/home/user/che, does this resolve the issue?

[Alexpud]

I executed several times the command
docker run -v /var/run/docker.sock:/var/run/docker.sock -e CHE_DATA_FOLDER=/home/user/che -e CHE_VERSION=nightly codenvy/che-launcher:nightly start

And it created 3 folders: lib, storage and workspaces. lib was filled automatically after the container creation with content similar to the lib folder on che binary; the storage and workspaces folders were empty.

After creating a workspace and executing it, the workspace folder contained the workspace and the projects files in it. But the storage folder contained only the preferences.json

[ghost]

@Alexpud can you please give it a try this way:

1. Start Che as you usually do
2. Create and run a workspace.
3. Stop a workspace4 at Workspace > Stop
4. Exec into a che-server container:

docker exec -ti che-server bash

1. When in a container, stop the server:

/home/user/che/bin/che.sh stop --skip:uid

The container will be stopped since this is the main process there.

1. Check /home/user/che/storage on your host machine - there should be a handful of jsons, including workspaces.json
2. Start Che as you did in Update DTD for GWT-module descriptors #1. You should see your workspace now.

Action items for us:

@TylerJewell we should think how to properly stop Che server when NOT using CLI but a pure docker syntax.

[Alexpud]

@eivantsov @TylerJewell It worked!

Thank you very for your time and patience.

[TylerJewell]

@eivantsov - surprised that this worked. If you look at the che-launcher stop method, it is doing exactly what you wrote. @Alexpud - could you share how you were stopping Che before you tried @eivantsov suggestion?

https://github.com/eclipse/che/blob/master/dockerfiles/che-launcher/launcher_cmds.sh#L64-L81

stop_che_server() {
  if ! che_container_is_running; then
    info "-------------------------------------------------------"
    info "ECLIPSE CHE: CONTAINER IS NOT RUNNING. NOTHING TO DO."
    info "-------------------------------------------------------"
  else
    info "ECLIPSE CHE: STOPPING SERVER..."
    docker exec ${CHE_SERVER_CONTAINER_NAME} /home/user/che/bin/che.sh -c -s:uid stop > /dev/null
    wait_until_container_is_stopped 60
    if che_container_is_running; then
      error_exit "ECLIPSE CHE: Timeout waiting Che container to stop."
    fi

    info "ECLIPSE CHE: REMOVING CONTAINER"
    docker rm ${CHE_SERVER_CONTAINER_NAME} > /dev/null
    info "ECLIPSE CHE: STOPPED"
  fi
}

[Alexpud]

@TylerJewell
I didn't know if it was the correct way, i asssumed since i was dealing with containers, the normal way to stop the container would be correct. I followed the documentation for usage as a docker server https://eclipse-che.readme.io/docs/usage-docker-server

docker stop che-server

Sorry, i didn't even imagine i needed to go inside the container to stop it, i knew i could, but i didn't think it would be necessary/work.

[TylerJewell]

That is the issue :) You should have done che stop or docker run -v /var/run/docker.sock:/var/run/docker.sock eclipse/che stop.

I was pulling my hair out - and terrified that we had a serious bug. I do not know how Eugene figured out that it was a stop issue without seeing you demo it live.

[Alexpud]

@TylerJewell - It was my fault for not doing executing the command you just posted.
But if i could make a suggestion: It would be great if the users were able to stop the che container with like you usually do with others containers. It seems less "weird" and more intuitive.

[TylerJewell]

I don't think that is a viable path. A single che instance can be managing dozens of other containers, for example - so start / stop has to be through our system.