8000 feat(scaling): Proxmox VE provider by adeelahmad · Pull Request #579 · adeelahmad/lense · GitHub
[go: up one dir, main page]
Skip to content

feat(scaling): Proxmox VE provider - #579

Merged
adeelahmad merged 3 commits into
mainfrom
claude/project-thread-azm2mb
Oct 18, 2026
Merged

feat(scaling): Proxmox VE provider#579
adeelahmad merged 3 commits into
mainfrom
claude/project-thread-azm2mb

Conversation

@adeelahmad
@adeelahmad adeelahmad commented Oct 18, 2026
Copy link
Copy Markdown
Owner

Description

Before: auto scaling could launch units on this machine, DigitalOcean and Hetzner Cloud, but not on a Proxmox server you own.

After: an admin can add a Proxmox VE provider (the API address, the node, and an API token). Each unit is a linked or full clone of a VM template, tagged for Lens and started. Once the clone's QEMU guest agent answers, Lens runs the first-boot script in it, which joins the mesh and starts lens worker, and tags the clone lens-booted. Letting a unit go stops the clone and deletes it with its disks. These units cost nothing unless the admin gives the provider a price. Like the other machines elsewhere, launching waits for the mesh's install line.

How: domain/scaling_proxmox.py calls the Proxmox API with httpx and an API token. Launching takes the next VM id and starts the clone. A background thread then waits for the clone task, tags and starts the clone, waits for the guest agent and runs the script. The script never touches the server's storage, and it stays only in Lens's memory until it runs. A boot that fails shows on the unit, and the scaler deletes a clone that never joins. For a private CA there are verify_tls and ca_cert.

Motivation and Context

Adeel asked for auto scaling worker nodes on "Remote Proxmox", among others. This is the third piece, after #556 (core) and #573 (DigitalOcean and Hetzner). SSH hosts and the model hosts come next.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change; ! in the title)

Checklist:

  • The title is a Conventional Commit.
  • My code follows the code style of this project (make hooks checks it on commit).
  • I added or updated tests.
  • My change requires documentation updates, and I have updated docs/ accordingly.
  • Users need more than the title to understand it, so I wrote it under ## Unreleased in CHANGELOG.md. (n/a: the title and docs/scaling.md say it)

Done questions (AGENTS.md)

  • Goal: one more asked-for node provider. It launches once the mesh's install line lands, and SSH and the model hosts follow.
  • Agents: the same REST, MCP and assistant scaling tools take proxmox providers.
  • Zero setup: nothing to install (httpx).
  • Fewest clicks: certificate checking and linked clones are on by default. The admin gives an address, a node, the token and a template id.
  • Configurable: every setting has a default where one makes sense and lives on the provider. The Settings forms come in a later PR.
  • Light: off by default, with no new dependency.
  • Private and secure: the token secret is sealed and TLS is verified by default. The first-boot script goes through the guest agent and is never written to the server. Threat model: P-SCALING's voided-by names the admin-given address, verify_tls off and the agent hand-off.
  • Cost: unpriced unless the admin sets a price.
  • User decides: approvals are unchanged, and existing defaults are unchanged.
  • Upgrades: there is no change to stored data.
  • Honest: docs and README call it in progress, since launching waits for the mesh's install line.
  • Tests and docs: 3 backend tests against a mock Proxmox API. docs/scaling.md, the README, requirements and the threat model are updated. OpenAPI is unchanged.
  • Open: no new dependency.
  • Reported in the project thread. Refine later (LXC containers) is in docs/scaling.md.
  • Reuse: httpx, the driver interface, and scaling_drivers.user_data.

Local CI (ci/local-ci.sh) passed every job on this change (33e983a, before the cherry-pick onto main): both backend jobs, Next.js, pre-commit, the title check and the upgrade check.

Generated by Claude Code

claude added 3 commits October 18, 2026 07:51
@claude
feat(scaling): Proxmox VE provider
a5a30b8 
Units are linked (or full) clones of a VM template, tagged for Lens and
started; once the guest agent answers, the first-boot script runs in the
clone through it, so nothing lands on the server's storage. Letting a
unit go stops the clone and deletes it with its disks.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ALjNbLobvPe7VwvDL8j7V3
@claude
docs(readme): list answering questions about Lens as built, now that …
08e9d4a 
…v0.15.0 released it

The requirements check fails every pull request once a release's
changelog names an In progress item.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ALjNbLobvPe7VwvDL8j7V3
@claude
Merge remote-tracking branch 'origin/main' into claude/project-thread…
25fdae7 
…-azm2mb

# Conflicts:
#	README.md
@adeelahmad
adeelahmad merged commit 310a2a5 into main Oct 18, 2026
12 checks passed
@adeelahmad
adeelahmad deleted the claude/project-thread-azm2mb branch October 18, 2026 09:40
@adeelahmad adeelahmad mentioned this pull request Oct 18, 2026
Merged
21 of 23 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@adeelahmad @claude
0