It includes:
- reworking Workspace Activity API to store timestamps of each status changes;
- add REST API endpoint to get workspaces ids by status and threshold timestamp;
* Adding support for @Traced annotation to enable whole method tracing
* Trace the creation and removal of workspace
* Trace the start of async start of the workspace
Note that this does not actually trace the async operations but merely
the "kick off" of those. For tracing the async operations, we need to
introduce support for propagating the span ids over the thread boundaries
using opentracing-concurrent.
* Enable tracing across the thread boundaries by augmenting the
WorkspaceSharedPool threadpool with tracing support.
Note that this does not add any new traces, merely enables the async
tracing.
* Add support for adding tags to @Traced methods.
The interceptor also reports the actual invoked class and method
(cleansed of Guice subclass name garbage)
* Trace the startup of pods during workspace startup.
* Trace stop of a workspace
* Introduce utility methods for tracing parts of methods.
* Trace provisioning of k8s objects (in both Kubernetes and Openshift
infrastructures).
* Create a common set of tags and enable strongly typed tags
* Apply the standard tags instead of hardcoded strings.
* Adding @Beta annotations for the tracing-related classes.
This needs to stabilize first.
* Replacing the "Traces" machinery with just annotated package private methods.
This way the code is easier to ready while we also keep all the flexibility
needed for the tag definitions.
* Rename CheTags to more descriptive TracingTags.
* Evaluate the tag values lazily.
This will reduce the load when tracing is switched off.
* Simplify the machine startup tracing logic and distinguish between
true error and mere cancellation due to prior errors.
* Trivial - applying formatting.
* Use getContext().getEnvironment().getMachines().size() to get the precise
number of machines that will be starting up.
* Trivial - change the name of the machine creation tag
* Use a formatted message instead of string concat.
* Update to the latest parent so that che-core-commons-tracing is correctly
incorporated into the full build.
* Fix tracing of the asynchronous stop of a workspace.
* Don't fall over when tracing is not available.
Allows running Che 7 workspace without any user environment but with Che 7 tooling set.
Workspace without environment has an empty list of environments and null value in `defaultEnv` field.
Field `activeEnv` is supposed to be `null` too.
What is changed:
- Migration of DB
- make defaultEnv nullable
- remove env_name from runtimes primary key
- make env_name in runtimes nullable
- Make code respect the fact that there are workspaces with no env
- settings API that returns the list of supported environment types returns no-environment type that - indicates that infrastructure support workspace with no environment at all.
Signed-off-by: Oleksandr Garagatyi <ogaragat@redhat.com>
Currently in Che there are still a number of requirements in upstream that are not required by the OIDC specification, so that Che still cannot be used with a number of OIDC compliant providers.
For example, in order to have Che working with the [`node-oidc-provider`](https://github.com/panva/node-oidc-provider), the following changes were necessary:
- Remove the requirement to have the email as a claim in the JWT access
token: this is not required the specification and is not supported by a
number of OIDC providers. Normally, the Id token contains such claims.
So now if the email is not in the JWT token the first time the user connects to Che, ten the email is retrieved from the OIDC provider through its `user-profile` endpoint.
- Explicitely specify the the `openid email profile` scope when requesting the access token. Because OIDC providers, when answering to the `userInfo` endpoint, are expected to return claims that corresponds to the scopes of the access token. So if an access token has the `openid` scope only, the `userinfo` might return no claim at all (according to the specification).
Until now it was working since keycloak allows adding claims to the returned tokens anyway.
- Allow supporting fixed redirect Uris: most OIDC providers support having a list of redirect URIs to come back to after the authorization step. But these authorized Uris don't necessarily support wildcards or prefix. Che doesn't support this currently, and these changes introduce 2 fixed callback HTML pages that redirect to the Dashboard / IDE URL of the final page we want to come back to after authentication. This makes Che compatible with more OIDC providers
We introduced a new boolean property to enable / disable fixed redirect URLs:
`che.keycloak.use_fixed_redirect_urls`
whose default value is `false`
- The previous points required some light changes in the Keycloak Javascript adapter file, that we will submit as a PR to the Keycloak project. I, the meantime the `OIDCKeycloak.js` file is still used, but has been updated to be now based on the `keycloak.js` file of the last `4.5.0-final` Keycloak release. This will make this Keycloak PR easier to get accepted.
Please keep in mind that this version upgrade only impacts the alternate OIDC provider case: when using a real Keycloak server, Che *always uses the `keycloak.js` file provided by the Keycloak server*.
Signed-off-by: David Festal <dfestal@redhat.com>
Roman Iuvshyn