Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [che-dev] 1 CLI or 2 CLI?
+1 for one CLI that can start both single and multi user che servers. 

Does offline mode makes sense for multi-user server? I don't think so. We may avoid pre-fetching docker images needed for multi-user che server.

To answer Marian I don't think we should discard the idea of extending current Che CLI (that runs in a docker container) to deploy and run Che on k8s or openshift. The benefit is that the only requirement to run Che, besides minishift or minikube, is just docker. We don't want to ask users to install and update a platform specific Che CLI binary. We want a user to be able to start Che via `docker run eclipse/che` independently of the container platform he is running on.  


On Thu, Jun 22, 2017 at 4:00 PM, Tyler Jewell <tjewell@xxxxxxxxxx> wrote:
Marian:

The CLI modifications we are discussing here would be for the Docker-based installation and startup of Che.

The process for deploying Che into k8s or openshift has not been spec'd out yet.

Tyler


Tyler Jewell // Dev Products // 978-884-5355

On Thu, Jun 22, 2017 at 3:01 AM, Marian Labuda <mlabuda@xxxxxxxxxx> wrote:
Hi,

just a thought. When I heard rumors about CLI for Che for deploying to OpenShift, I was kinda feeling strange to have CLI as a docker image to deploy to OpenShift container platform. Haven't you give a thought to have a CLI per platform per architecture? Something similar to OpenShift CLI. It is a oc binary for a specific arch and platform, it has just a few MB and it is really fun to work with it - I am using it much more frequently thanr Web UI or desktop tools. You would not have to throw away all work which has been done, you could just encapsulate existing CLI calls to a new CLI client....


Regards

Marian Labuda
Red Hat Che QE

On Wed, Jun 21, 2017 at 10:14 PM, Tyler Jewell <tjewell@xxxxxxxxxx> wrote:
So, a launcher-launcher-cli pattern?  Let's go inception on the CLI.

You are correct in that it would require some re-think on aspects of the CLI. There are certain elements that are identical no matter which assembly-CLI that you would use:
1. The installation folder, project files, and workspace storage
2. The che.env configuration file
3. Some of the pre-flight checks such as disk read / write, network tests, firewall tests
4. Certain utility image pulls, such as eclipse/che-ip

And then other elements would be specific to an assembly-CLI:
1. The registry of images used to run / stop / monitor che
2. The images that are downloaded as part of any offline mode
3. The upgrade validity (today we just check version compatibility, but we'd also need to check assembly compatibility)

Another variation that could be considered is a command-line flag. In this scenario we only have a single che.env file. The user could pass `--assembly:singleuser' or `--assembly:workgroup`, and then we do a hard install / config for the architecture required given the flag specified.  In this situation, there is a single CLI, but if a user configures something in che.env that is for multi-user configuration while passing `--assembly:singleuser`, then that property would be ignored as a no-op.



Tyler Jewell // Dev Products // 978-884-5355

On Wed, Jun 21, 2017 at 12:46 PM, Oleksandr Garagatyi <ogaragat@xxxxxxxxxx> wrote:
What about a variant with 1 CLI that can download assembly-dependant CLI when the user made his choice of assembly.
1. We won't need 2 public CLIs.
2. Public CLI can download any other private CLI conf (or private CLI itself) to start an assembly, so it is scalable. 
3. No overhead of other images, WARs, etc.

But it would make current CLI a bit more complex.

On Wed, Jun 21, 2017 at 10:23 PM, Tyler Jewell <tjewell@xxxxxxxxxx> wrote:
Eclipse Che Community:

We have a decision to make that will have long lasting impact on how people install, configure and run Eclipse Che. 

I'd like people's public comments and opinions. We will use this perspective in the drafting of the specification for installations.

As part of the Red Hat acquisition of Codenvy, Red Hat is open sourcing certain Codenvy subsystems related to security, authentication, and persistence that will move into Eclipse Che.

This increases the complexity of Eclipse Che.

We will address this complexity by having the Che repository support multiple assemblies. Essentially, we can compile Che with different combinations of plugins and extensions to create a tailor-made server and agent binary based upon the configuration selected.

At a minimum, we envision two initial assemblies provided as "official" product installations:
1. A single server, providing no security, easy to install as a Docker image anywhere
2. A multi-user server, with authentication, potentially requiring a proxy, master server, and db.

We will use our stateless CLI to generate different docker-compose.yml scripts to launch Che depending upon the configuration chosen by the admin when they install the product.

Here is the choice.

We have two ways to enable this:
1. We can create a single Docker image that has both assemblies packaged as different WAR files. Depending upon how the end user configures properties in che.env, the docker-compose script will be able to start Che's container with the right WAR deployed to Tomcat.  The benefit of this approach is that we have a single CLI with single syntax. However, the standard Che Docker image will be 150 MB larger as we will bundle two WARs together. This approach will not be scalable long term if we want to have many different assemblies for how to run Che master on Tomcat.  Also, and potentially very costly, the nature of the CLI requires that we itemize all of the Docker images that will be used by the CLI for installation. With a single CLI, it will include all of hte images for proxy, database which would be automatically pulled by the CLI, even if the end user was just desiring the simple installation that does not require those components.

2. We can create two separate CLIs, each one representing a type of installation. Each CLI will have a different Docker image name, so the end user would have to know in advance which architecture they wish to install. This would guarantee that the downloads from image pulls are minimal. However, we would have to adapt our documentation to account for the concept of many different installers, and potentially we would want to add checks within the CLI to prevent people from using the wrong CLI on an installation (ie, if you are trying to upgrade Che using the simple architecture CLI on an install that was done with a different CLI).

Opinions welcome.

I had dreamed of a world where we could use a single CLI to do a basic install. And with that installation there would be a single che.env file that was the single location for doing any kind of configuration, whether you wanted to configure a system without authentication or one with.  The CLI could then start Che and the associated containers based upon that configuration.  However, since we support offline installation and pre-fetch of Docker images, these basic functions make it challenging to create an all-in-one packaging that is still performant.

Tyler Jewell // Dev Products // 978-884-5355

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev




--

Alexander Garagatyi

Red Hat 





_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev


Back to the top