v6 went GA on 2026-07-04 but v5 installs are pinned to the 5.1.x line
by the updater, so they have no in-app signal that v6 exists. Rework
the existing release announcement fabric (dismissible banner plus the
Updates settings card) from RC-testing copy to a factual notice: v6 is
a new major version, upgrading is a manual step, link to the upgrade
guide and changelog on main. New announcement id so users who
dismissed the RC banner see the GA notice once; dismissal still
persists per browser. Updater line-pinning is untouched.
Parse guest VM IDs from canonical resource segments and require per-disk suffix matches so alert migration cannot remap one guest's disk alert onto another guest. Refs #1511
Lint only the packages containing staged .go files (falling back to ./... when
none are staged) and cap golangci-lint concurrency/timeout via
GOLANGCI_LINT_CONCURRENCY and GOLANGCI_LINT_TIMEOUT to keep the hook from
exhausting resources on large trees.
Each release line is owned by its branch (release/5.1 cuts 5.1.x, pulse/v6-release
cuts v6). Replace the main-only branch check with a detached-HEAD guard and pass
--ref "${CURRENT_BRANCH}" to the create-release.yml dispatch so the workflow
runs against the releasing branch.
The pollPVEInstance error path returned without touching node state, so
a host that stopped answering kept showing its last online snapshot
forever (#1441, reported against v5 in #1135), and a host that was
already down when Pulse started never appeared on the dashboard at all
(#1433).
Route the poll error through the same grace policy as the existing
empty-node fallback: nodes seen within the grace window keep their
prior state with degraded connection health, then flip to offline with
cleared uptime and CPU once the window lapses. An instance with no node
state yet gets the synthesized offline entry from removeFailedPVENode
so it still shows on the dashboard.
Backport of the v6 fixes 02955619f and 8372a22c5.
The agent self-updater's HTTP client followed redirects with no
CheckRedirect policy. Go's net/http strips Authorization/Cookie on a
cross-host redirect but forwards custom headers such as X-API-Token, so a
cross-origin 30x from the operator-configured PulseURL (open redirect,
compromised/hijacked server, DNS/BGP hijack, or a malicious provisioning
URL) leaked the agent API token to the redirect target (CWE-200/CWE-522).
Backport of the v6 fix: refuse to follow any redirect rather than
re-sending the token. Covers both the getServerVersion version-check path
and the binary-download path, with regression tests asserting the redirect
target is never hit.
Reported by tonghuaroot.
Follow-up to the #1341 dual-source fix. In a Proxmox cluster the
Proxmox-API instance name (cluster/connection name) differs from the
host-agent's node hostname, so a pool's two source identities share no
prefix (e.g. `prodcluster-ceph-pool-X` vs `agent:pve5-ceph-pool-X`). The
per-pool override is saved under one identity. The previous fix only
toggled the `agent:` prefix, which bridges a single node but not a
cluster, so when the deduped winner was the API copy the row found no
override and showed the storage default. With the cluster's API Ceph
source intermittently dropping (the same clustered environment as #1319),
the winner oscillated and the threshold appeared to flap between the
custom value (50%) and the default (80%) on the polling cadence.
Carry every source instance for an FSID as `CephCluster.InstanceAliases`
(populated in DedupeCephClusters) and emit the pool ID under each as
`Storage.AliasIDs`. Override resolution (alert evaluation and the
thresholds UI) now tries the primary ID plus every alias, so a per-pool
override resolves regardless of which source currently wins. This mirrors
v6's source-independent override identity. Non-breaking: existing keys
resolve via aliases, no re-entry needed.
Follow-up to the #1341 dual-source fix. When the Proxmox API identity
wins the FSID dedup, proactively clear any usage alert still active under
this agent's own pool IDs so a pre-fix duplicate clears on the next agent
report rather than aging out over the ~24h stale-alert window. Agent-only
clusters (where the agent identity is the winner) are untouched.
Fixes#1341 (reopened)
When the same Ceph cluster is reported by both the Proxmox API poller
(instance "pve5") and a Pulse host-agent (instance "agent:pve5"), it
landed in state twice under two pool-ID namespaces
("pve5-ceph-pool-X" vs "agent:pve5-ceph-pool-X"). The frontend collapsed
them via an FSID dedup whose winner was chosen by a fluctuating
completeness score, but alert evaluation ran on the raw, un-deduped list
(and ce1607694 added a third check on the raw agent cluster). So:
- the threshold UI row identity flipped between the two pool IDs as the
dedup winner oscillated, making a saved per-pool override appear to
revert between the custom value and the storage default; and
- both pool IDs were alert-checked under independent lifecycles,
producing duplicate, flapping active alerts.
Make alert evaluation and the frontend consume the same deterministic
FSID-deduplicated Ceph view (DedupeCephClusters), preferring the
authoritative non-agent identity so a pool has exactly one ID. Route the
agent-report and mock alert paths through GetDedupedCephClusters, and
honor the legacy "agent:"-prefixed override key for the surviving pool so
existing thresholds keep firing without manual re-entry. Retires the
ce1607694 agent-only check path.
Centralize the QEMU guest-agent MemAvailable fallback on the 5.1 branch and record the direct guest-agent value in diagnostic snapshots.
Add regression coverage for the issue #1319 saturated Linux memory payload and Windows fsinfo volume payload.
Refs #1319
Fixes#1341
When a Pulse host-agent reports Ceph data, ApplyHostReport upserts the
cluster into state but only the Proxmox-API polling path ran
cephPoolAlertStorageTargets. Users with agent-reported Ceph (instance
prefix "agent:hostname") saved per-pool overrides under
agent-prefixed IDs that the alert manager never evaluated. The
threshold appeared to save (and showed Custom in the UI), but the
polling cycle was checking a different storage ID, so the alert
silently stayed dormant. Run CheckStorage for each pool right after
the agent upsert so the override key actually drives evaluation.
Refs #1341
UpdateAlertConfig used to log SaveAlertConfig failures and still tell
the client "saved successfully", leaving the in-memory state with the
new override but the on-disk file untouched. On the next config reload
or process restart, the override silently vanished and the user saw
their threshold "revert" with no surfaced error. Return HTTP 500 with
the persistence error so the frontend can show a real save-failed
toast instead of false confidence.
Refs #1341
buildAlertsDiagnostic previously emitted only boolean flags (legacy
thresholds, missing cooldown/grouping window). Override keys and their
trigger values were absent, so triaging a support case where the user
suspects an override mismatch required asking them to paste
data/alerts.json from inside their container. Add an Overrides slice
that names each persisted key with its thresholds and disabled flags.
Sanitize mode in the frontend redacts the keys to override-N while
keeping thresholds visible, so a public export still shows the alert
shape without leaking instance names that may be hostnames.
Refs #1341
The 5.1.32 fix in 6f3bea32f only tested the storage default path for
synthetic Ceph pool entries. Reporter on #1341 sets a 50% per-pool
override on a pool at ~61% usage and still doesn't get an alert; lock
the override path against future regressions so this remains a config
question rather than a code regression.
Ensure the dashboard guest table expands to 100% of the container width on large screens (especially under the Proxmox overview tab), while retaining the minimum width calculation to prevent horizontal collapses.
Fixes#1480
