docs(proxmox-supported-substrate): add the proposal for a support tier and maintenance model by themoriarti · Pull Request #98 · cozystack/community

Marian Koreniuk (themoriarti) · 2026-10-14T12:01:42Z

Proposes the decision cozystack/cozystack#3481 asks for: whether Proxmox VE becomes a supported way to run Cozystack, and on what terms.

What it proposes:

Tier. Proxmox ships in v1.7 as Beta.
Owners and commitments. Two owners from different organisations; a first response to area/proxmox within two working days; at least ten hours a month each.
Runner. A CageForge-hosted runner for the existing e2e-proxmox.yaml lane, restricted to schedule and workflow_dispatch, with a fresh VM per run and a pool-scoped token.
Promotion. Supported once criteria that can be read off GitHub hold.
Demotion. It drops a tier without anyone's goodwill when the lane stays red or the owners go quiet.

It also takes a position on #86. #86 rejects the "backend field in one chart" that the substrate landed as. Rather than defending that field, the proposal commits to porting Proxmox onto #86's library and backend contract once #86 is accepted. It fills in the Proxmox column of #86's contract table, including the rows not covered today: tenant LoadBalancer Services, Proxied ingress, monitoring agents and the autoscaler Role.

Facts are pinned to cozystack main at e05c56524, v1.7.0-rc.1, and a live Proxmox VE 9.2.20 stand checked on 2026-10-14.

Before review

If this revises a merged design proposal: it adds a decision record under that proposal's decisions/ directory, or says below why none is needed.

Not applicable: this adds a new proposal and does not revise a merged one.

DCO

Commits are signed off (git commit --signoff).

…r and maintenance model cozystack/cozystack#3481 asks whether Proxmox VE becomes a supported way to run Cozystack, decided deliberately rather than accumulated by merging parts. The substrate is in v1.7 with no stated support level and with an E2E lane that has never run. The proposal ships it as Beta and names the owners, their response time and the runner behind the lane. It sets promotion criteria that can be read off GitHub, and demotion criteria that need no one's goodwill. It also commits the substrate to the backend model of community#86 instead of defending the backend field it landed as, and fills in its column of that proposal's contract table, gaps included. Assisted-by: LLM Signed-off-by: Marian Koreniuk <moriarti@cp.if.ua>

coderabbitai · 2026-10-14T12:01:54Z

Important

🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

Run configuration

Source mode: Auto
Repository: Unavailable
Branch: Unavailable
File: No configuration file from this repository applied
Commit: Unavailable
Layers: defaults
Review profile: CHILL
Plan: Advanced
Run ID: a2206d34-3829-467f-881f-228616b685b6

Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

Marian Koreniuk (themoriarti) · 2026-10-14T12:16:41Z

One follow-up to the "What has been verified" section, now that enough time has passed.

The three worker pools on the stand were moved on 2026-10-14 to a template built by hack/proxmox-talos-template.sh (cozystack#4742) from the chart's own Talos values. Until then their workers came from a host-node image. Its zfs extension waits for /dev/zfs, which a VM never has, so Talos rebooted every worker when its boot timeout ran out, roughly every 71 minutes. On the production tenant that showed as 74 restarts of every pod in three and a half days.

On the new template every new node has kept its boot ID past that point, at 103, 75 and 72 minutes, with no pod restarts.

myasnikovdaniil · 2026-10-23T14:06:51Z

Hi! We removed Status and Date from proposal headers in #111. Could you remove these fields when you next update your proposal? Decision records keep their metadata.

Sorry for the extra work, I wanted to mention this now so it doesn't come up late in review.

…l> (#5000) ## What this PR does The Proxmox suite (`hack/e2e-chainsaw/kubernetes-proxmox/`) has now run for the first time on a real self-hosted stand: a dedicated Cozystack v1.7.0-rc.1 management cluster on Proxmox VE, with the runner CageForge offered to host in cozystack/community#98. The suite failed before it reached the hypervisor, because the fixture and the chart disagree on what a node pool may be called. `kubernetes-nodes` names its release `kubernetes-nodes-<CR name>` and, since fd14126, refuses to render one that does not start with `kubernetes-nodes-<spec.cluster>-` (`packages/apps/kubernetes-nodes/templates/_helpers.tpl`). The fixture, added later in 7500a9f, names its `KubernetesNodes` `md0`. On the stand that gave: ``` Helm install failed for release tenant-e2eproxmox/kubernetes-nodes-md0 ...: kubernetes-nodes: release name "kubernetes-nodes-md0" must start with "kubernetes-nodes-k8s-e2e-" — name the KubernetesNodes CR <cluster>-<pool> (cluster="k8s-e2e") ``` No `Machine` was ever created. The `tenant-and-cluster` step passed its `ProxmoxCluster` assert in 20 seconds and then waited out the 20-minute `Machine` assert. - The fixture names the pool `k8s-e2e-md0`. Nothing else in the suite, `run-proxmox.sh` or the workflow refers to the pool by name. - `hack/proxmox-e2e-fixture_test.bats` gets a case that reads `metadata.name` and `spec.cluster` of the fixture's `KubernetesNodes` and fails unless the name is `<cluster>-<pool>`. It is POSIX sh like the rest of the file, so `hack/cozytest.sh` can still run it. ### Testing - `bats hack/proxmox-e2e-fixture_test.bats` (bats 1.14.0, the CI commit): 7/7. The new case was checked to fail against the old fixture: `FAIL: KubernetesNodes md0 must be named k8s-e2e-<pool>`. - `hack/check-commit-trailers.sh upstream/main..HEAD`: OK. - Lane, before the fix (fork `main` @ aed7fa8): https://github.com/themoriarti/cozystack/actions/runs/39402535098. Red on the `Machine` assert, as above; the teardown removed the tenant and left no VM on the hypervisor. - Lane, with this commit: https://github.com/themoriarti/cozystack/actions/runs/39442983145. The pool release `kubernetes-nodes-k8s-e2e-md0` installs, the `Machine` is created, capmox clones the worker from the template and boots it, and the worker joins the tenant and goes `Ready` (Talos v1.13.6). The run is still red, one step later and for a known reason: the tenant's CCM crash-loops on `pccm:v0.15.0` with `panic: version string "0.15.0" doesn't match expected regular expression: "^v(\d+\.\d+\.\d+)"`, so the node keeps `node.cloudprovider.kubernetes.io/uninitialized` and no providerID, and the `Machine` assert reports `Provisioned`, expected `Running`. That is #4917. The teardown removed the tenant, the worker VM and its cloud-init ISO. Two earlier runs on the same commit, 39406900563 and 39409765857, stopped at stand configuration rather than at this repository: capmox's token could not see an ISO storage, and the stand's `publishing.host` did not resolve from the fixture's public resolvers. Both are fixed on the stand. They are listed below because the lane does not say a stand needs them. ### Found on the way, not changed here - **What a stand must provide**, beyond the `PROXMOX_*` variables: - an `iso`-content storage on which capmox's token holds `Datastore.AllocateTemplate` (to upload the cloud-init ISO) and `Datastore.Allocate` (to delete it with the VM). go-proxmox uploads to the first `iso` storage the token can see; without delete rights the `Machine` never finishes deleting. - a `publishing.host` whose `<cluster>.<tenant>.<host>` resolves through the fixture's own resolvers (`8.8.8.8`, `1.1.1.1`) to a root ingress with SSL passthrough: on the Proxmox substrate that name is the tenant's `controlPlaneEndpoint`. - **`COZY_PVE_ADDRESSES/GATEWAY/PREFIX/BRIDGE/POOL`** are not passed by the workflow. Unset, they default to `vmbr50` and `10.0.0.180-185`. This stand sets them in the runner's environment. - **The fixture's `templateTags`** (`capmox-template, cozystack, talos, talos-v1.13.6`) are not the set that `hack/proxmox-talos-template.sh` writes (`cozystack, schematic-…, talos, talos-v…`). capmox matches tags as a set, so a template built by the script is not selected. This stand tags its template to match the fixture. - **Teardown reports success once the CRs are deleted.** It does not wait for the VMs to be gone; on this stand a worker VM outlived its `Machine` for hours while capmox retried a forbidden delete. The CCM fix itself is #4917. Once a release carries it, this lane should get past the `Machine` assert. The lane stays manual. It has no `push` or `pull_request` trigger, and its nightly schedule is a no-op unless `PROXMOX_NIGHTLY` is set, which it is not on this stand. The runner is registered to a fork whose only collaborator is its owner. Running it from cozystack/cozystack needs a runner group restricted to this workflow and a protected environment, which is a follow-up for community#98, not this PR. ### Screenshots Not a UI change. ### Downstream repositories - [x] No downstream repository is affected by this change The diff touches one fixture under `hack/e2e-chainsaw/` and one bats file. It moves or renames nothing under `hack/`, changes no make target and no node prerequisite. ### Release note ```release-note NONE ```  ## Summary by CodeRabbit - **Bug Fixes** - Updated the Kubernetes node pool fixture to use the required cluster-prefixed naming convention, improving compatibility with Kubernetes node validation. - **Tests** - Added validation to confirm that Kubernetes node fixtures include the required cluster reference and use the expected cluster-based name format.

The proposal conventions no longer keep these fields; status and dates come from the introducing PR's history. Assisted-by: LLM Signed-off-by: Marian Koreniuk <moriarti@cp.if.ua>

Marian Koreniuk (themoriarti) · 2026-10-29T13:00:59Z

myasnikovdaniil thanks for the heads-up. Status and Date are gone from the header (65eb6a7); nothing else changed.

Marian Koreniuk (themoriarti) mentioned this pull request Oct 14, 2026

Proxmox as a supported platform: where the work stands and what a decision needs cozystack/cozystack#3481

Open

Marian Koreniuk (themoriarti) mentioned this pull request Oct 26, 2026

docs(design-proposals): add Proxmox LXC containers for tenants #117

Open

docs(proxmox-supported-substrate): drop Status and Date from the header

65eb6a7

The proposal conventions no longer keep these fields; status and dates come from the introducing PR's history. Assisted-by: LLM Signed-off-by: Marian Koreniuk <moriarti@cp.if.ua>

Navigation Menu

Repository navigation

docs(proxmox-supported-substrate): add the proposal for a support tier and maintenance model - #98

docs(proxmox-supported-substrate): add the proposal for a support tier and maintenance model#98
Marian Koreniuk (themoriarti) wants to merge 2 commits into
cozystack:mainfrom
themoriarti:docs/proxmox-supported-substrate

Marian Koreniuk (themoriarti) commented Oct 14, 2026

Uh oh!

coderabbitai Bot commented Oct 14, 2026 •

edited

Loading

Uh oh!

Marian Koreniuk (themoriarti) commented Oct 14, 2026

Uh oh!

myasnikovdaniil commented Oct 23, 2026

Uh oh!

Marian Koreniuk (themoriarti) commented Oct 29, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

Marian Koreniuk (themoriarti) commented Oct 14, 2026

Before review

DCO

Uh oh!

coderabbitai Bot commented Oct 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Marian Koreniuk (themoriarti) commented Oct 14, 2026

Uh oh!

myasnikovdaniil commented Oct 23, 2026

Uh oh!

Marian Koreniuk (themoriarti) commented Oct 29, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

coderabbitai Bot commented Oct 14, 2026 •

edited

Loading