Publish port in Docker machines only in case there is a server
in the workspace config that represents the port.
Refactor OpenShift infrastructure code.
Refactor Docker infrastructure code.
Add constant of memory attribute and reuse it everywhere it is
hardcoded.
Add constant for installer environment attribute and reuse it
everywhere it is hardcoded.
Add machine memory attribute validation to workspace validation.
Move provisioning of servers, environment variables from
infrastructure implementations to runtime SPI abstract level.
Signed-off-by: Oleksandr Garagatyi <ogaragat@redhat.com>
* Ping the wsagent URL (possibly external), not the *internal URL*.
* Use `getProperties().getInternalUrl()` when `getUrl()` returns `null`
* Add a new provider for an optional routing suffix for workspaces to be
used in the external URLs of created workspace agents in the
use-cases where a custom server evaluation strategy is used (Openshift,
Traeffik, etc ...).
* Add 2 new macros for the custom server evaluation template which are:
- `user`: the current environment context user if any,
- `workspacesRoutingSuffix`: the suffix returned by the available
`WorspacesRoutingSuffixProvider` if any.
Both values can null, in which case they are not added to the ST
variables, so that it is possible to test on their existence in the
template. For example:
```
<if(workspacesRoutingSuffix)><user>-che.<workspacesRoutingSuffix><else><externalAddress><endif>
```
* Add a new provider to get workspace-related Openshift configuration containing:
- the `io.fabric8.kubernetes.client.Config` object to connect the right
Openshift cluster / namespace in which workspaces will be created
- The name of the namespace in which workspaces are cteated
- A boolean that tell if the workspaces will be created in a different
cluster as the che-server.
These data returned by the subclasses of the new provider can of course
depend on the current user (and this will be the case for multi-tenancy)
* Also support the `application/vnd.api+json` content type in responses
* Now use the new providers to connect to the right clutser / namespace
* Allow the Docker connector to return the API endpoint...
The base `DockerConnector` class returns `null` as the endpoint, thus
keeping the previous behavior.
However the `OpenshiftConnector` implementation now returns the API
endpoint without the need for any environment variable:
Indeed in the case of Openshift, the API endpoint is either based on:
- the internal fully-qualified name of the `che-host` service if
workspaces are to be hosted on the same Openshift cluster,
- the external URL of the `che` route if workspaces may be hosted on a
distinct Openshift cluster.
* If related properties or env variables are void, use the connector to retrieve
the API endpoint.
* Required changes for multi-tenancy in deployment script
* Allow overriding the agent log directories in a clean way so that we don't need
to replace the `XXXWsMasterModule` class only
to override the `run_command` binding.
* Move some local-docker-related configuration into a separate `dynamodule`.
This avoid the need to override the `WsMasterModule` class and comment
these bindings in derived assemblies that use a distinct implementation
or don't need Traeffik (such as for Openshift deployments).
* Return `OpenShiftException` when workspaces namespace cannot be reached
* Add multi-tenancy options to the deploy script
* Add the `CHE_EPHEMERAL` and `CHE_USE_ACME_CERTIFICATE` options
* Fix the name of the used docker image for multi-tenant
Signed-off-by: David Festal <dfestal@redhat.com>
* CHE-6702 Add env variables to machine config
* CHE-6702 Add setting of env variables into OpenShift machines
* CHE-6702 Add setting of env variables into Docker machines
* CHE-6702 Make env field known for stack validator
Some changes are required like
- anyString() --> nullable(String.class) for many tests as in fact we provide null values
- add class for VerificationMode as there are more than one method now (can't use lambdas)
- remove cast on ArgumentMatcher (now we can use lambdas as there is generics)
- remove unecessary stubbing (mockito is now reporting un-needed stubs)
Change-Id: I69c7ccc86bc85a4401d5e33671229ae0ce560dbb
Signed-off-by: Florent BENOIT <fbenoit@redhat.com>
Multi-user Eclipse Che (#6441)
#### How to run it.
```docker run -it -e CHE_MULTIUSER=true -e CHE_HOST=<your ip> -e CHE_KEYCLOAK_AUTH-SERVER-URL=http://<your ip>:5050/auth -v /var/run/docker.sock:/var/run/docker.sock -v ~/.che-multiuser:/data eclipse/che:nightly start --skip:pull --skip:nightly```
#### How to manage it
- Keycloak configured with two realms. ```Master``` and ```che```. Also we have one user admin/admin in both realm. Admin user in master realm is - super admin.
- Eclipse Che configured for che realm
- We enabled user registration in ```Che``` realm
#### Known limitation
- swagger would not work. We need to upgrade a version. to support openid authentification https://github.com/eclipse/che/issues/6015
- It's working on local docker. We are going to provide scalable version based on OpenShift on next versions.
- Invitation of non-existent users to Eclipse Che organization https://github.com/eclipse/che/issues/6335
#### How to run it when it is in a branch
To run an multiuser Che version, the following steps are required after building the branch:
- Rebuild init, cli and che images (in the given sequence). To do that, proceed to folder _dockerfiles/<image_name>_ and run _build.sh_
- Run Che in a usual way using cli, with additional parameters: `-e CHE_MULTIUSER=true` and `--skip:pull --skip:nightly`
Full command example:
`docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock -v /home/user/.che:/data -e CHE_MULTIUSER=true eclipse/che-cli:nightly start --skip:pull --skip:nightly`
- MacOS users may need to edit _che.env_ file in the data folder, changing `CHE_HOST` and `CHE_KEYCLOAK_AUTH__SERVER__URL` values to their specific IP.
When start is succeeded, the following docker containers should be created:
- che, exposing 8080 port;
- che_keycloak, exposing 5050 port;
- che_postgres, exposing 5432 port;
note: some dependencies have been updated (avoid eclipselink dependencies as it contains some API of javax.persistence package)
then, when tests are running, Java runtime complains about siganture mismatch between eclipse-link jar and javax-persistence.jar (same package but with two origins)
By using org.eclipse.persistence.core and org.eclipse.persistence.jpa the dependencies are more explicit and we select only required dependencies.
Change-Id: I4752a79e1badb2bf36594a3f7c1928569200d2a5
Signed-off-by: Florent BENOIT <fbenoit@redhat.com>
Oleksandr Garagatyi