About Sessions
This page includes information about running, sharing, and deleting sessions.
Running an App/Workflow Session
Any app or workflow can generate a session as long as its YAML file contains a sessions definition. Below is an example of a YAML file with a sessions definition, with a session named desktop:
sessions:
desktop:
You can check for sessions in the app or workflow's Build tab. For more information, please see Building Sessions.
Start your workflow or app. A notification will appear, either with the message Executing workflow [name] or App [name] launched. You'll also be redirected to the Sessions page.
Once the session has been created, the page will display the session, status, local port, and remote port.
When your navigation bar is expanded, your number of running sessions will appear next to Sessions.
Click the session name to see view the exposed application.
Running a Manual Session
You can create a session manually, which does not require a running app or workflow. Creating a manual session is useful if you're running an application that exposes a port. For example, you can run a Jupyter Notebook server on a port on your cluster's controller node, then expose access to that server by creating a manual session pointing to the port.
Alternatively, you can create a session using a link. This method is used for workflows that run externally from a workflow. You could use the external link to create a session and share that session with other users in your organization.
To create a session manually, navigate to Sessions. Click Add Sessions.
On the next page, select Tunnel or Link.
Link sessions only require a Name and a URL. After setting these parameters, you can click Add Session.
Tunnel sessions require a Name, Remote Port, and Target Type.
After selecting a Target Type, you must select a running resource to launch the session.
- Compute clusters only require one field, Target, which refers to the running cluster.
- Kubernetes clusters require Kubernetes Cluster (the running cluster), the Resource Type (pods, deployments, or services), and a Resource Name.
Advanced Options
All parameters in this section are optional.
The Workspace Port refers to the port in your workspace that the session will be forwarded to. You can leave this field blank or enter 0 to choose a random port.
The Slug will be appended to the URL when accessing the session. This parameter is useful for apps whose basePath is not /.
The Remote Host is the hostname of the app's running location. This parameter is set to localhost by default.
Application Uses HTTPS? determines whether the session will use HTTPS to access the app running on the forwarded port. Please note that you should only select use HTTPS if the application you are running is using HTTPS. This does not affect encryption between your browser and ACTIVATE.
Use Custom Domain determines whether the session's URL will use a custom domain to access the app running on the forwarded port. If you're using the SaaS version of our platform, the URL will take the form of *.activate.pw where * is the session domain. For standalone deployments of ACTIVATE, the URL will vary.
After configuring these settings, click Add Session.
You will be redirected to the Sessions page as the session starts. When the session's status displays running, click its name to access the session.
Sharing a Session
On the Sessions page, click the share icon.
On the next page, select the group(s) you want to share the session with. You'll see the message Permission updated successfully.
Only share a session with groups you trust. Sharing is the same as allowing users in the group to run the app as you.
Deleting a Session
On the Sessions page, click the delete icon.
A dialog box will appear with the message Are you sure you want to delete this session?
Click Delete.
A notification will appear with the message Session deleted.
Please note that deleting a session does not cancel the app or workflow that created the session. You must cancel the workflow or app separately.