Skip to content

Correct stale architecture docs in experimental/ssh/README.md - #6451

Open
anton-107 wants to merge 1 commit into
mainfrom
fix-ssh-readme-stale-architecture
Open

Correct stale architecture docs in experimental/ssh/README.md#6451
anton-107 wants to merge 1 commit into
mainfrom
fix-ssh-readme-stale-architecture

Conversation

@anton-107

Copy link
Copy Markdown
Contributor

Changes

Docs only, one file. Corrects experimental/ssh/README.md where it had drifted from the code:

  • Compute requirements. The list claimed terminal SSH works on standard access mode. It does not - ValidateClusterAccess requires Dedicated access mode with single_user_name set, and both entry points call it, so standard / dedicated-to-a-group / no-isolation clusters are rejected before any work happens. Also mentions serverless, which the list omitted entirely.
  • Both design diagrams. Key distribution (secret scope, not a pub-key in the notebook), workspace paths, the notebook's real name, the /logs endpoint, the ProxyCommand flags, and the websocket URL shape.
  • Removed a step that does not exist: the sequence diagram ended with DELETE metadata.json on teardown. The server just calls os.Exit(0) and leaves the file behind.
  • Added the reason that matters: metadata.json is published before the listener accepts and outlives the process, so neither its presence nor its contents prove a server is running. That is why the client always re-probes /metadata through the driver proxy.

The high-level diagram previously showed per-Spark-user SSH servers, an arrangement that only made sense while standard access mode was in scope.

Why

Someone reading this README to learn the feature would come away with the wrong mental model in three ways that matter: they would expect standard-mode clusters to work, look for metadata.json under ~/.ssh/, and assume a stale metadata file means no server is running.

Verified each claim against origin/main rather than trusting the prose: ValidateClusterAccess and setup.go, internal/workspace/workspace.go for paths, internal/server/server.go for endpoints and the exit path, internal/keys/ for key flow, and buildSSHArgs / ToProxyCommand for the spawned command.

Tests

No tests - docs-only, no behavior change. ./tools/validate_whitespace.py passes and go mod tidy leaves the modules untouched. No changelog fragment: experimental/ and doc-only both fall under the skip list in the pr-checklist skill.

I could not render the Mermaid locally (no npm registry access from this host), so I validated the diagrams structurally instead - subgraph/end balance, no undeclared node or participant references, every arrow carries a label - and confirmed the new text introduces no character that the previously-rendering diagrams did not already use. Worth eyeballing both diagrams in the GitHub preview before merging.

This PR was written by Claude Code.

The compute requirements claimed terminal SSH works on standard access mode.
It does not: ValidateClusterAccess requires Dedicated access mode with
single_user_name set, and both entry points call it (client.go on a direct
`connect --cluster`, setup.go on `ssh setup`), so a standard, dedicated-to-a-group,
or no-isolation cluster is rejected before any work happens.

The two design diagrams had drifted from the code as well:

- Keys travel through a per-session secret scope, not a pub-key baked into the
  bootstrap notebook. The notebook is `ssh-server-bootstrap`, not
  `start-server-with-pub-key.ipynb`.
- Workspace paths are /Workspace/Users/$me/.databricks/ssh-tunnel/$v/..., not
  ~/.ssh/$v/..., and metadata.json also carries cluster_id and usage_policy_id.
- The server serves /logs alongside /ssh and /metadata, publishes metadata
  before it starts accepting connections, and never deletes metadata.json - it
  just exits, which is why the client must re-probe /metadata through the driver
  proxy rather than trusting the file.
- The ProxyCommand takes --cluster/--metadata flags, and the websocket URL
  includes /o/$workspaceId and ?id=$connId.
- The high-level diagram showed per-Spark-user servers, an arrangement that only
  made sense while standard access mode was in scope.

Co-authored-by: Isaac <no-reply@databricks.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants