Debug Che binaries within che-server without mounting /repo

[garagatyi]

Sometimes I need to debug some version of Che or some branch but I don't have compiled sources of that state of Che. I would want to debug Che without compilation of sources. But now it is not implemented.

Che version: 5.0.0-Snapshot

• Problem started happening recently, didn't happen in an older version of Che: [No]
• Problem can be reliably reproduced, doesn't happen randomly: [Yes]

[TylerJewell]

The cli requires that you run it in dev mode and that an assembly would exist on your local repo.

What are the circumstances where this doesn't work?

[garagatyi]

I was in the middle of development of some feature and needed to make fast debugging session of master. I had to commit my changes, checkout to master, recompile master to debug. And then checkout my branch, recompile it to continue my work. With codenvy it is even worse because I have to do all of that for 2 repos.

[TylerJewell]

That workflow is the expected workflow. I am not sure I see what should be improved?

[garagatyi]

Improvement is ability to debug che server without usage of local binaries

[TylerJewell]

Where would the binaries come from? There is not an image that has them - so you have to build those binaries anyways.

[garagatyi]

We always have binaries in che-server image

[TylerJewell]

Your specific scenario would not work then. Because of you have to debug master then you always have to build binaries. The images that are on dockerhub are only tagged images or the nightly, neither of which is correlated to master.

So you just want a way to debug an existing image if that tagged version has the binaries you want in it.

[garagatyi]

yes, and nightly is what I need to debug from time to time. Another use-case is to debug some tag to confirm submitted bug.

[TylerJewell]

So the objective is to be able to run development_mode on an existing eclipse/che-server Docker image without using the module or assembly that is on disk. Intead, using the binaries that are already packaged within the particular eclipse/che-server image that is referenced during the bootstrap phase.

I see two ways that this could be implemented:
1: Require a special volume mount of /internal:/repo. Assuming that the user doesn't have this folder on disk, if this fixed-name folder is volume mounted into the CLI, we will then assume that development mode is on, and we will use the binaries internal, skipping the disk checks. Any time '/internal' is volume mounted, we use internal binaries. All other volume mounts would check for binaries on disk. There are multiple locations where we check for DEVELOPMENT_MODE and then use the appropriate files on disk - for the CLI, for the assembly binaries, and for the puppet modules. So if you use /internal we'd have to use the internal values for all of these.

2: Add a --debug flag to the start() command, which would be a signal to use the internal image instead.

I am not a fan to the --debug as the syntax will not be obvious to end users on when they should mount :/repo or not. So I would prefer that we find a way to do a special volume mount.

@riuvshin @vparfonov - would like your opinions on this.

[garagatyi]

What about syntax docker run -e DEVELOPMENT_MODE=on eclipse/che-cli ... ?

[l0rd]

+1 for @garagatyi proposal.

Otherwise -e CHE_DEBUG_SERVER=true is already there to handle this case but is currently ignored by the cli.

For the record che-launcher solves @garagatyi problem using 3 env variables. You can run:

docker run -t --rm -v /var/run/docker.sock:/var/run/docker.sock \
  -e CHE_DEBUG_SERVER="true" \
  -e CHE_DEBUG_SERVER_PORT="8000" \
  -e CHE_DEBUG_SERVER_SUSPEND="false" \
  eclipse/che-launcher:nightly start

I think the cli should support these 3 variables too.

[TylerJewell]

-1 on the use of variables. The design iof the new cli has purposefully removed use of all variables unless they are needed during the init phase of the system. This would introduce an inconsistency and not be obvious tonend users on the difference between variables and the volume mount.

[l0rd]

@TylerJewell ok. I wasn't aware of this limitation. That makes it difficult to find an elegant solution. An option to the start command seems the better one. I would not know how to implement to "special repository" solution.

[TylerJewell]

Variables are quite problematic. One of the goals of the new cli is to give the admin a single location on which to configure his installation - the .env file. So if you are thinking about static configuration of an already existing installation then this is where you go. Simple for admin and creates consistency. The only time we use variables is if the admin needs to define values during an init when a new env file is created. And there are only two of those values CHE_HOST and CHE_PORT.

Then for anything that references files or folders on the host, we use volume mounts to reference those objects and the presence or lack of presence to set behavior patterns for the cli.

The issue comes in with dev mode. We have already defined dev mode to be a true event if :/repo is volume mounted. So having it activated due to a variable in the env file or on the command line or as a parameter to start breaks this consistency.

[l0rd]

The issue comes in with dev mode. We have already defined dev mode to be a true event if :/repo is volume mounted. So having it activated due to a variable in the env file or on the command line or as a parameter to start breaks this consistency.

I think this is the problem. Mounting volume /repo should not enable debug mode. These are 2 different things and should be enabled/disabled separately.

[TylerJewell]

I understand the instinct to separate the concept of configuration apart from location. It is easy to argue that you could have a simple "ENABLE_DEBUG_MODE" in a che.env, and without any :/repo mounting, then it would use the internal binaries. But then this presumes that you have an existing installation, for example, and the presence of the che.env file. You could then argue that we allow for any che.env property to also be defined on the command line with -e CHE_VAR_NAME=* syntax, and then use that during any pre-boot sequence, and if there is a che.env file, then to use the loaded values instead of the values within the che.env file.

From a UX point of view, it's really nice that we can tell an admin that everything they need to configure Che is entirely in che.env or by setting a very small, select set of volume mounts. If a volume mount is going to be mandatory, then the presence of the mount should automatically set the associated variables, to the degree that they can be set.

This has - as a consequence - lead to a very small number of variables or options on the command line, which has had this odd consequence of fewer errors with admins new to the CLI.

So I am not saying which way is the right way to implement in the end, but I did want you guys to understand that there is a design philosophy that we have stumbled upon, and it's (so far in external tests) proving that people are able to approach Che more simply. So I think it's a good think that I am striving to maintain that philosophy as the CLI designer.

Having said that, what's the harm with just having this be -v /internal:/repo for the setting that indicates you want to use an internal binaries instead of the one on the host?

[l0rd]

@TylerJewell I'm ok with your design philosophy (avoiding variables). What I'm suggesting is to use --debug (or add a new command start-debug or just debug) AND to make it coherent for users, change the cli behaviour when /repo is volume mounted: tomcat debug mode should be enabled only if flag --debug is provided, regardless of whether /repo has been volume mounted or not.

Using -v /internal:/repo has some problems:

• If folder /internal does not exists Docker will create it. We should avoid creating empty folders on users filesystem root
• If a folder /internal already exists we should warn the user that this is just a reserved name and the folder won't be really mounted
• docker run -v /internal:/repo ... is not explicit about what is happening here whereas--debug is straightforward

[TylerJewell]

Ok. I understand the concept. Need some time to think about it.

[TylerJewell]

I have initiated a pull request for this. I consider it experimental right now - it needs lots of testing.