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
