Allow stable Session Naming for ephemeral sessions

[iyannsch]

Is your feature request related to a problem? Please describe.

Right now, the Session/Workspace name is set-able when creating non-ephemeral sessions.
The following code shows how to create a session with predictable name:

const launchRequest = {
            serviceUrl: config.serviceUrl,
            appId: config.appId,
            user: email!,
            appDefinition: appDefinition,
            workspaceName: 'we-can-set-every-value-here',

but this parameter is ignored for ephemeral sessions. The session's name would be we-can-set-every-value-here-session.

This allows to create two sessions with the same name, both resolving to the same workspace, and, thus, restarting and reconnecting the user to the workspace. This is good and actually very useful functionality.

Still, it seems like unintended functionality to allow such behavior on non-ephermal sessions but not on ephemeral ones. Maybe, this mechanisms allows to bring the system in a unpredicted state by choosing weird names?

Describe the solution you'd like

We want a controllable way to set the session name (regardless of persistency). The session names are currently calculated in regard to the user and the appDefinition, giving us no flexibility to add dynamic data fetched via the landing page to it (exerciseId).

In our use case it is required to (re)identify a running session and have the user connect to it. This could be solved with either setting the name ourselves or being able to predict the names in a stable and extensible way.

Describe alternatives you've considered

It would also be able to define some flags/options during session/workspace creation to later identify it with.

Cluster provider

No response

Additional information

No response

[lucas-koehler]

We discussed this with the team:

Frontend code using session objects should not depend on K8S resources being named as handed over in a REST call. The reason is that names must be processed by the backend to be valid Kubernetes object names.

We propose adding a label property to the Session object spec that may contain any text and can be used to identify a session again. In combination with solving #377 , a frontend implementation can then forward the user to the running session.

I think it still makes sense to keep the functionality of connecting to the same workspace again when its name is specified. Maybe the documentation should be improved to make clear the workspaceName is disregarded for ephemeral session launches.