Debugging tools reference

Use these tables to compare SKAO debugging services, configured limits, and environment availability.

Capability matrix

Capability	Headlamp	Coder	BinderHub	JupyterHub
Kubernetes resource and event views	Yes	Via CLI	No	No
Live Pod logs	Yes	Via CLI	No	No
In-cluster DNS and network tests	No	Yes	From notebook server	From notebook server
Browser IDE or notebook	No	Yes	Yes	Yes
Repository-derived environment	No	No	Yes	No
Shareable environment URL	Resource URL	No	Yes	No
Persistent user storage	No	Home directory	Per server	Per server

Coder workspace

The SKAO Kubernetes workspace offers these connection options when enabled by the template:

• VS Code Desktop

• browser-based VS Code

• browser-based JupyterLab

• browser terminal

• SSH

The workspace image includes kubectl, helm, k9s, tango_admin, Jupyter tools, poetry, and pip. The home directory persists when the workspace stops and starts. Packages installed outside the home directory do not necessarily persist.

Workspace Kubernetes permissions focus on list and view operations. The API can deny mutation operations, including deleting Pods. The precise permission set comes from the workspace service account and can change independently of this page.

Manage a workspace from its settings page. You can start, stop, or restart the workspace; select the configured CPU and memory values; and define autostart and autostop schedules. Disk size is fixed after workspace creation. Close active IDE, terminal, and SSH connections when you finish because an active connection can prevent inactivity-based shutdown.

Request a different workspace image or compute option from the System Team support channel.

BinderHub and JupyterHub limits

The existing portal configuration records these limits:

Setting	Configured value
Named server name	Maximum 20 characters
Server count	Up to five named servers plus My Server
Inactivity timeout	Server stops after two hours without activity
Storage	2 GiB per server
Compute	1 CPU and 2 GB RAM per server
Storage lifecycle	Storage remains when a server stops and is deleted when the server is deleted

BinderHub accepts a repository URL and a Git reference. Its repo2docker builder recognises environment files in the repository root, binder/, or .binder/. Supported files include requirements.txt and environment.yml. Consult the repo2docker configuration reference for the full and current list.

Open JupyterHub directly when you do not need BinderHub to build a repository. JupyterHub lists your existing servers and lets you create a named server, start a stopped server, or stop and delete a server. Starting a stopped server returns you to the work you left in it.

Manage named servers from JupyterHub.

You can create a notebook in the server or upload one from your computer. Install dependencies manually on this route, because no image is built from repository configuration.

The STFC deployment exposes JupyterHub directly.

JupyterHub profiles

A profile overrides the default server configuration with different CPU, memory, storage, or software. Only a cluster administrator can deploy one, so the profiles available depend on the environment.

The selector appears when you add a server in an environment that has profiles configured.

Add a new server to reach the profile selector.

Select a profile, then start the server.

Note

The profiles shown above are illustrative. Request a profile for your team through the System Team Support Desk, stating the storage, CPU, memory, and software it needs.

Headlamp SKAO views

The SKAO Headlamp plugins add business-specific information to the standard Kubernetes interface. A deployment mounts them into Headlamp’s plugin directory, so the views below appear alongside the built-in resource pages.

Plugin	View
ska-prometheus	Built-in CPU, memory, network, and disk metrics for Pods and other resources, including a metrics panel on the Namespace page. Metrics are filtered by datacentre.
ska-owner-metadata	SKAO CI/CD metadata, with navigation to the pipeline and job that deployed the resource.
ska-organization	Tabs presenting namespace information per SKAO team, user, and project.
ska-helm-release	Installed Helm releases and their dependency versions in a namespace.
ska-tango	SKA Tango Operator custom resources, DeviceServer and DatabaseDS, with TANGO database information.
flux	FluxCD resource information. Marked beta.
ska-logo	Applies the SKAO logo to the interface.

Find the current plugin set and image tags on the releases page.

Service URLs

Services vary by environment. Production environments do not expose every debugging tool.

Important

Rows marked Local access have no public Headlamp URL. Reach those clusters through InfraHQ, as described in Access a cluster with InfraHQ. Arrange this access in advance — it is a prerequisite for debugging the ITF and Array Assembly environments at all.

CI/CD datacentres:

Datacentre	Headlamp	Coder	BinderHub
stfc-techops	Open	Open	Open
stfc-dp	Open	N/A	Open
aws-cicd	Open	N/A	Open

ITF and production datacentres:

Datacentre	Headlamp	Coder	BinderHub
mid-itf	Local access [1]	N/A	Open
low-itf	Local access [1]	N/A	Open
mid-aa	Local access [1]	N/A	N/A
low-aa	Local access [1]	N/A	N/A
aws-*	N/A	N/A	N/A

[1] (1,2,3,4)

Reach these clusters through InfraHQ and run Headlamp locally. See Run Headlamp locally.

Upstream documentation

• Coder user guides

• BinderHub architecture

• repo2docker configuration files

• Headlamp documentation