search

eclipse-che / che

Kubernetes based Cloud Development Environments for Enterprise Teams
http://eclipse.org/che
Eclipse Public License 2.0
6.99k stars 1.19k forks source link

Multi-Users for Che #5362

Closed skabashnyuk closed 7 years ago

skabashnyuk commented 7 years ago

Adding authentification - is a very frequent request from Eclipse Che community. We think that Keycloak is a rich framework that can provide many interesting features http://www.keycloak.org/about.html

From a technical perspective, it would be a separate assembly inside of Che. We don't want to remove an ability for plugin developers to have an easy and simple assembly without authentification and any heavy components for easy testing of their work. We might reuse the same approach like we did with "single port" feature. When changing some specific parameter on configuration will change the number of containers that would be running. In this case, Keycloak will be running as a separate container.

TylerJewell commented 7 years ago

Based upon the discussion on the planning session today, I'd like to adjust the language slightly. You said that "From a technical perspective, it would be a separate assembly inside Che". While it could be a separate assembly that does pose certain challenges with documentation and our marketing distribution. So, I think we agreed that we'd evaluate / investigate both a configuration-based approach to activating this AND also a custom assembly. But for marketing purposes, to the degree that we can keep it in a single assembly, there are other types of advantages.

gazarenkov commented 7 years ago

@TylerJewell Well, what we discussed is that we should not avoid any possible manner.

To be more clear. We have several let's say "pluggable points" (maybe forgot something):

There are a lot of combinations of such and we suppose third parties to be able to contribute theirs components as well (good docs needed of course) so what from your marketing perspective mean to keep it in a single assembly using configuration-based approach? To me it sounds like your expectation is to change anything from listed with just changing some configuration parameters and rebooting (without reassembling). Is it something like you have in mind?

TylerJewell commented 7 years ago

Actually, the more I think about it, our concepts may be compatible. The concept of an "assembly" in the Che sense is different from the concept of an installation given the unique qualities of our installer.

So it may be possible for us to have 1..n custom assemblies pre-built and for us to have a single installer image that knows how to install different configurations of Che (using different assemblies).

Our installer for Che is a stateless Docker container that in turn installs a che.env file. That file is what I consider the "configuration" of the system. This file's contents are used by both the installer container AND the Che server container to configure itself.

Since we have the ability to have different puppet templates that define different composable infrastructures, we could allow for different properties in che.env to activate different Che assemblies. The default assembly would: a) all of our standard IDE plugins b) our Docker-based workspace runtime c) our postgres RDMS DAO provider running in a 2nd container d) our KeyCloak implementation with the server running in a third container e) single port activation with the traefik proxy running in a fourth container

If a user modifies the right properties in the che.env, or perhaps just runs the CLI in "dev mode" which is a feature that we have, those properties could disable the postgres RDBMS, uses no-auth for a single user, does not allow for single port with Traefik.

In these two scenarios, the CLI would need to be smart enough to use two different custom assemblies. Each custom assembly would have the elements in the server necessary to support the configuration provided.

So yes, we can have different custom assemblies, but still a single installer & che.env file that determines the layout and setup when the system starts. Roman would know how to apply this.

skabashnyuk commented 7 years ago

Today I've discussed folder structure what we are going to have with @gazarenkov @riuvshin And we have such proposal

V1

/assembly
  /sdk
     /assembly-main
     /assembly-*
  /small-group(onprem)
     /assembly-main
     /assembly-*    
/dockerfiles
  /sdk
     /action
     /base
     /cli
     /dev
     /init
     ..
     /test
  /small-group(onprem)
     /cli
     /init

Roman's variant

/assembly
  /sdk
     /assembly-main
     /assembly-*
  /small-group(onprem)
     /assembly-main
     /assembly-*    
/dockerfiles
  /sdk
     /action
     /base
     /cli
     /cli-small-group
     /dev
     /init-small-group
     ..
     /test

@TylerJewell wdyt?

benoitf commented 7 years ago

FYI, from an external user POV, the layout seems complicated to understand what is proposing what I think we could try names like "core", "basic", "full"

riuvshin commented 7 years ago

Well, I actually disagree with using "small_group" in any place... In my mind "small group" means something minimalistic and lightweight while in that case "small group" means that this is EXTENDED CHE with DB, and stuff.

I would like something sdk (very basic stuff single container) and CHE where CHE is fully powered CHE.

gazarenkov commented 7 years ago

I would not say "sdk" name is good one. In this case I would expect something dedicatedly useful for plugin/extensions developers, not sure it is the case though.

I would better propose the name as the offering - first for "individual", second for "small group" (yes, it is rather marketing oriented, but it is what it is :) )

benoitf commented 7 years ago

small group let me more thinking of small group of features --> smaller than the sdk which is the opposite

TylerJewell commented 7 years ago

I have two things to introduce:

  1. I would rather see "individual" and "workgroup". It helps to avoid terms like "simple", "full", "basic" because these are not descriptive for an end user. It could mean many things to different people on what is included in each of those definitions. Another option could be "singleuser" and "multiuser". Because really all of the customizations we are doing are because of that simple switch.

  2. On the structure proposed by @skabashnyuk - I think it's going in the right direction, but I suspect that the CLI folder should not be part of each custom assembly. I think the CLI becomes smarter and lives as a peer of the multiple assemblies. We would have che.env properties that if turned on / off, automatically activates the other assembly. We could, for example, use the name of the Docker image in the /init package as a way to determine which assembly gets launched.

benoitf commented 7 years ago

@tyler is that "enterprise" name would match as well ?

TylerJewell commented 7 years ago

I thought about the use of the term "enterprise", and I chose to avoid that as I felt that it attached a number of concepts related to support, infrastructure, and configuration that we may or may not support with this particular packaging. Or, we may only want to support them if you have Che on OpenShift, which is quite different from Che on Docker. So I think the term is a bit ambiguous as it could mean different things to different people.

benoitf commented 7 years ago

Ok

gazarenkov commented 7 years ago

"individual" and "workgroup" - good for me

gazarenkov commented 7 years ago

See no problem having CLI as a part of each assembly, why not if it is required?

TylerJewell commented 7 years ago

We could have a structured tiering:

  1. A top-level CLI that has master che.env. Configuration values in this file may launch different assemblies based upon how admin configures it.
  2. Each assembly also has a CLI that is special purpose, just for running that local assembly and nothing else.

But I think #2 is an anti-pattern to how we intended the CLI to operate.

gazarenkov commented 7 years ago

I do not understand what does "A top-level CLI that has master che.env. Configuration values in this file may launch different assemblies based upon how admin configures it" mean. It sounds like there are several assemblies packed together to let have one CLI to choose which one to run?

I would imagine assembly without mandatory CLI at all, but if assembly requires CLI why not to include it?

TylerJewell commented 7 years ago

I think the confusion you are running into can be solved by learning a small amount on how the CLI runs.

The CLI is a stateless, temporary container that imports a configuration from a set of files in an installation directory. It then uses that configuration to define a set of puppet manifests that are executed to generate a "configuration instance" that can run Che itself. Different properties in che.env can generate different types of "configuration instances".

The configuration instances include docker compose and other scripts necessary to start and stop Che. Since we can generate different configuration instances, those instances can generate different kinds of compose scripts that reference different Docker images.

So, we can look at the admin point of view of which properties we want on / off, and then based upon those properties we can generate compose scripts that choose to launch the single container version (with one assembly in it) or the a multi-container version with postgres, keycloak, and other software in different images / assemblies.

gazarenkov commented 7 years ago

OK, indeed, I misunderstand where /cli folder is placed so what inside of it. Then I let you decide.

The only thing - I'd like to rename "assembly" on something more specific like "docker-assembly"

TylerJewell commented 7 years ago

It might help to define "assembly" a little bit. Is an assembly just the custom tomcat packaging that runs ws-master? Or, do we want to define an assembly to be the custom WAR, tomcat, and Docker image that packages it all together for execution?

riuvshin commented 7 years ago

@TylerJewell just to make it clear for me which way to go on CLI and 2 assemblies. We have following options: CLI

1 separate CLI for multiuser che / separate che-server image

2 single CLI with ability to switch CHE assemblies (that will add some difficulties for simple single user che all images for che multi server will be pulled and maybe some other side effects)

che-server: 1 use single che-server image for both tomcat assmeblies 2 use different images for che-server (che-server and che-server-multiuser)

I personally think more about CLI 1) because it much more flexible and it will be easy if we will need add something more it will be easier to extend and with single CLI it could be nightmare of workarounds to make it work same way for both completely different products. And to me it is much easier to understand what you are actually using because you use different images for different products. As for che-server I prefer 2 because it will be better for users who need only single user CHE they will just choose right image. Btw we also can use separate tag for multiuser like: che-server:latest and che-server:multiuser-lates

skabashnyuk commented 7 years ago

2.2 - I thought we go in this way.

riuvshin commented 7 years ago

@skabashnyuk sorry I messed it up, now edited. THere is to topic single / different CLI image and single / different che-server image

TylerJewell commented 7 years ago

Hi @riuvshin - I think what we said was 2.2:

  1. Single CLI with ability to switch che assemblies based upon values in che.env.
  2. Use different docker images for che-server and che-server-multiuser

On the comment for how to tag images, is that a best practice? I thought that labels should only apply to version labels? So how would you have handle version 6.1 of the multi-user image?

riuvshin commented 7 years ago

@TylerJewell got it.

about tags it was just a thoughts, we will go with different images.

l0rd commented 7 years ago

@skabashnyuk I've added the following item to the epic:

- [ ] Fix bug that currently slow down IDE in OSIO https://github.com/redhat-developer/rh-che/issues/300
skabashnyuk commented 7 years ago

@l0rd can you explain how they are related?

l0rd commented 7 years ago

@skabashnyuk that's a problem that we have noticed when keycloak authentication is enabled in rh-che. Since we don't want to continue fixing keycloak related issues on rh-che repository I've linked the issue here. Fixing it as part of this epic seemed the right thing to do.