kubernetes-latest flaked because the worker-readiness wait was split into 8m-to-join + 3m-to-become-Ready. Under sandbox load a slow KubeVirt VM boot consumes most of the join budget, then the tenant cluster's cilium CNI needs several more minutes to make the freshly-joined nodes Ready, overflowing the fixed 3m Ready window even though the CNI converges fine (its HelmRelease reached True shortly after). Replace with one 12m deadline polling for >=2 Ready nodes, robust to wherever the time goes. Same single-deadline shape as the LINSTOR post-install fix (#2928).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Reconfiguring the Etcd CR triggers a HelmRelease upgrade that renders the EtcdBackupSchedule; hr/etcd and etcdcluster can report ready on the prior revision before the new resource materializes, so the immediate get raced to NotFound. Poll for it (timeout 120s), mirroring the CronJob wait already used later in the same test.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Auto mode evicts running etcd members to apply VPA recommendations, churning the StatefulSet (disruptive to quorum and a Cilium IP-reuse-leak trigger under load). Initial sizes at pod creation without evicting; the existing 250m/256Mi minAllowed floor covers the no-runtime-resize tradeoff. Same eviction-churn class as the monitoring VPA fix.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
In Auto mode the VPA Updater evicts running pods to apply new recommendations. During install that eviction churn recreates VictoriaMetrics pods faster than Cilium releases their endpoint IPs, tripping the cluster-pool IPAM "IP already in use" (putEndpointIdInvalid) leak that wedges a pod and stalls the install. Initial sets requests at pod creation without ever evicting, removing the trigger (the cilium-leak healer remains as defense for non-VPA churn paths).
Also raise vmstorage/vmselect minAllowed floors to 200m/512Mi: under Initial a pod is sized once at creation and never re-sized at runtime, so the floor is the safety net against the heavy query/storage tiers being left under-provisioned.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Claude Code does not natively support AGENTS.md; add the thin CLAUDE.md
shim so all Claude Code sessions pick up the same guidance as other tools.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
## What this PR does
Clears the OpenSSF Scorecard **Vulnerabilities** check (was **0/10**).
Scorecard queries OSV against the dependency graph, so reproducing it
with `osv-scanner` over both `go.mod` files surfaced **12 advisories**:
| Advisory | Package | Fixed in |
|---|---|---|
| GO-2026-4918, 4971, 4977, 4980, 4982, 4986 | stdlib (Go toolchain) |
1.26.3 |
| GO-2026-5037, 5038, 5039 | stdlib (Go toolchain) | 1.26.4 |
| GO-2026-4918, GO-2026-5026 | `golang.org/x/net` | 0.55.0 |
**10 of 12 are stdlib advisories** against the Go toolchain pinned at
`1.26.2` — so the dominant fix is raising the Go directive, not churning
dependencies.
### Changes
- **Go directive `1.26.2 → 1.26.4`** in the root module and the
`api/apps/v1alpha1` submodule (closes all 10 stdlib advisories; 1.26.4
is required for GO-2026-5037/5038/5039).
- **`golang.org/x/net 0.52.0 → 0.55.0`** (closes GO-2026-4918,
GO-2026-5026). `go mod tidy` carried the matching minor bumps to
`x/crypto`, `x/sys`, `x/term`, `x/text`, `x/tools` via MVS.
All version changes were made with `go mod edit` / `go get` / `go mod
tidy` — the generated `go.mod` was not hand-edited.
### Verification
- `osv-scanner` after the bump: **Total 0 packages affected by 0 known
vulnerabilities.**
- `go build ./...` passes on both modules (toolchain auto-upgraded to
go1.26.4).
- `make generate` produces **no drift** — `codegen-drift` CI stays
green.
> **Maintenance note:** the Renovate config (separate PR) deliberately
does **not** auto-bump the Go toolchain directive, so future stdlib
advisories (1.26.5+) will need a manual bump like this one. If you'd
prefer Renovate to keep the Go *patch* version current automatically,
that rule can be enabled — flagged for a decision.
### Release note
```release-note
fix(deps): bump Go to 1.26.4 and golang.org/x/net to v0.55.0, closing 12 known OSV advisories (10 stdlib, 2 in x/net)
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated the Go toolchain to the latest 1.26.x release for improved
build reliability and runtime compatibility.
* Bumped several indirect Go module dependencies (networking, crypto,
system, terminal, text, and tooling libraries) to newer stable versions
to enhance stability and security.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Promote the universal project guidance that previously lived only in a
local CLAUDE.md into the committed agent docs, so every contributor and
every tool (Codex/Cursor/etc., not just Claude) gets it from a fresh
clone.
overview.md gains Build and Development Commands (root + per-package
make targets, build env vars), Values schema generation, a Testing
section, and Domain references. contributing.md gains a "Verify Before
Considering Done" matrix and Review Expectations. Dedup: overview's Git
Commits block now points to contributing.md instead of restating it.
Assisted-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Capture the e2e stabilization conventions established over the last few
months as a routed agent doc: no retries on deterministic CI steps,
event-driven backstops over fixed sleeps, no EXIT/RETURN traps,
fail-fast HelmRelease-readiness gating, the status.history remediation
guard, first-class failure diagnostics, and a reviewer checklist. Also
documents Test-Impact Analysis (TIA) and its real scope — it trims only
the per-app loop, runs after install, and most PRs escalate to the full
suite. Wire it into AGENTS.md so every agent reads it before e2e/CI work.
Assisted-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
## What this PR does
Adds `spec.timeout: 10m` to the `kubevirt-csi-node` HelmRelease template
in `packages/apps/kubernetes/templates/helmreleases/csi.yaml`, aligning
it with every other tenant addon HR in the same directory (cilium,
coredns, ingress-nginx, etc. — all set `timeout: 10m`). `csi.yaml` was
the only one missing it; commit 9f9d8f85 ("Align timeouts for
HelmReleases") missed this template.
## Symptom
E2E NFS test times out waiting for `nfs-test-pod` to reach `Succeeded`.
Cozyreport events show the tenant `csi` HR running an Install →
Uninstall → Install remediation cycle. With
`install.remediation.retries: -1` and the default 5m Helm timeout,
kstatus marks the `kubevirt-csi-node` DaemonSet `InProgress` past 5m on
a slow tenant control-plane bringup (Kamaji APIs flapping, VM image
pulls), helm-controller times out, the remediation uninstalls the
DaemonSet, then reinstalls. Any volume mount in flight at that moment is
wedged.
## Origin
Single commit lifted unchanged from #2619.
### Release note
```release-note
NONE
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated the Container Storage Interface (CSI) Helm release settings to
include a `spec.timeout` of **10 minutes** when the etcd namespace value
is set (keeping the existing `spec.interval` at **5 minutes**).
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Summary
- Drop the `rm -f` line in
`packages/system/prometheus-operator-crds/Makefile` so the full upstream
CRD bundle (10 CRDs) ships instead of the 4-CRD subset.
- Pin `helm pull --version 25.0.0` to keep the operator CRD version at
`v0.87.0` (operator version bump is intentionally out of scope here).
- Re-run `make update` to repopulate `charts/crds/templates/` with the 6
previously-stripped CRDs: `Alertmanager`, `AlertmanagerConfig`,
`Prometheus`, `PrometheusAgent`, `ScrapeConfig`, `ThanosRuler`. The 4
already-vendored CRDs are byte-identical (version pin holds).
## Why
The bundle was originally trimmed to the 4 service-discovery CRDs that
VictoriaMetrics operator needs (`ServiceMonitor`, `PodMonitor`,
`PrometheusRule`, `Probe`). That was correct when the chart was vendored
inside `system/victoria-metrics-operator` (`ba5c785cc`, Dec 2023), but
the prune was carried over verbatim when the chart was extracted to its
own package, and again when the CRD release was propagated into tenant
Kubernetes clusters (`1e2b66131`, Dec 2025).
In tenant clusters the partial set blocks third-party apps that ship
their own `prometheus-operator` (e.g. `kube-prometheus-stack`): they
cannot deploy `Prometheus`/`Alertmanager` instances because the
platform-managed CRD set is incomplete, and `--server-side
--force-conflicts` workarounds get reverted by Flux as it re-reconciles
the narrower release manifest.
With the full bundle shipping, tenant apps can set `crds.enabled: false`
on their `kube-prometheus-stack` release and consume the platform CRDs
directly — the standard pattern for platform-level CRDs shared between
multiple stacks.
## Test plan
- [x] `helm template ./charts/prometheus-operator-crds` renders 10
`CustomResourceDefinition` resources, all in `monitoring.coreos.com` API
group.
- [x] `helm template packages/apps/kubernetes -f
tests/values/common.yaml` renders cleanly (75 kinds).
- [x] `helm unittest packages/apps/kubernetes` — 6 suites, 123 tests,
all pass.
- [x] No in-repo consumer hardcodes the 4-CRD list (verified by grep).
- [ ] Smoke-test on a tenant cluster: confirm `kube-prometheus-stack`
with `crds.enabled: false` installs cleanly and the operator can manage
`Prometheus`/`Alertmanager` instances against the platform CRDs.
## Out of scope
- Bumping the operator CRD version past `v0.87.0` — separate concern.
- Switching from `HelmRelease` to a Flux `Kustomization` for CRD
application — bigger refactor; current Helm ownership is fine now that
the bundle is complete and downstream apps can opt out of installing
CRDs.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Pinned the prometheus-operator-crds Helm chart pull to version
`25.0.0` for consistent regeneration.
* Streamlined the update workflow by removing the existing generated
charts directory before pulling the chart, improving build cleanliness.
* Removed the extra post-pull cleanup step that previously deleted
selected generated CRD templates.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Add `rm -rf charts/prometheus-operator-crds` before `helm pull` in the
update target so stale files from previous chart versions don't linger
across updates. This matches the convention used by cilium,
external-secrets-operator, external-dns, and cert-manager Makefiles.
Address review feedback from gemini-code-assist on
packages/system/prometheus-operator-crds/Makefile:9.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
The chart previously stripped the bundle to 4 CRDs (ServiceMonitor,
PodMonitor, PrometheusRule, Probe) — the set VictoriaMetrics operator
needs for service discovery. This was correct when the chart was
vendored inside system/victoria-metrics-operator (commit ba5c785cc,
2023), but the prune was carried over when the chart was extracted
to its own package, and again when the CRDs were propagated into
tenant Kubernetes clusters (commit 1e2b66131, 2025).
In tenant clusters the partial set blocks third-party apps that ship
their own prometheus-operator (e.g. kube-prometheus-stack) — the
missing CRDs (Prometheus, Alertmanager, AlertmanagerConfig,
PrometheusAgent, ScrapeConfig, ThanosRuler) prevent the operator from
deploying its instances against the platform-managed CRD set.
Drop the rm -f line in the Makefile so the full upstream bundle ships,
and pin --version 25.0.0 to keep the operator CRD version at v0.87.0
(operator version bump is a separate concern, out of scope here).
Tenant apps can now set crds.enabled: false on their kube-prometheus-
stack release and consume the platform CRDs directly.
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Aligns kubevirt-csi-node HR with every other tenant addon HR in
packages/apps/kubernetes/templates/helmreleases/ (cilium, coredns,
ingress-nginx, etc.) — all set timeout: 10m, csi.yaml was the only
exception. 9f9d8f85 ("Allign timeouts for HelmReleases") missed it.
Symptom: e2e NFS test (hack/e2e-apps/run-kubernetes.sh) times out
waiting for nfs-test-pod to reach Succeeded. Cozyreport events show
the tenant csi HR running Install -> Uninstall -> Install remediation
cycles. With install.remediation.retries: -1 and the default 5m Helm
timeout, kstatus marks the kubevirt-csi-node DaemonSet 'InProgress'
past 5m on a slow tenant control-plane bringup (Kamaji APIs flapping,
VM image pulls), helm-controller times out, the remediation uninstalls
the DaemonSet, then reinstalls. Any volume mount in flight at that
moment is wedged.
Observed on PR #2619 CI run 26142986969: csi HR remediation at
~07:07 happened ~10 min into the nfs-test-pod wait, killing the
mount and timing out the pod-Succeeded condition.
10m matches the surrounding HRs and gives the DaemonSet headroom
without changing remediation semantics on truly-broken installs.
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
(cherry picked from commit 866588ff61)
## What this PR does
`cozystack-api` published the free-form `.spec` of aggregated
`apps.cozystack.io` resources (Tenant, Application, …) as the boolean
`additionalProperties: true`. The Kubernetes ValidatingAdmissionPolicy
**status type-checker** run by `kube-controller-manager`
nil-dereferences when it recurses into that node
(`k8s.io/apiserver/pkg/cel/openapi.isExtension`). As soon as a VAP
matches one of these resources — `cozystack-tenant-host-policy` matches
`tenants` — KCM `CrashLoopBackOff`s on every control-plane node, stalls
reconciliation, and times out the install (`kubectl wait hr --all` never
completes). With the 3× install retry removed, a single occurrence fails
E2E outright.
This emits `x-kubernetes-preserve-unknown-fields: true` instead, in
`pkg/cmd/server/openapi.go::patchSpec` (both the schemaless and
custom-schema branches, covering the OpenAPI v2 and v3 post-processors).
It is semantically equivalent — "arbitrary fields allowed" — and the
type-checker handles it safely. All managed-app custom schemas already
use the safe **object-form** `additionalProperties`, so `patchSpec` was
the only source of the boolean form.
### Regression test
`TestPatchedSpecDoesNotPanicVAPTypeChecker` reproduces the exact crash
through `k8s.io/apiserver/pkg/cel/openapi.SchemaDeclType` — the entry
point KCM's `validatingadmissionpolicystatus` controller uses. It
**panics on the pre-fix code and passes after the fix**. Companion
structural tests assert the published spec carries
`x-kubernetes-preserve-unknown-fields: true` and never the boolean
`additionalProperties: true`, and that genuine object-form maps are left
untouched.
Verified against the pristine vendored `k8s.io/apiserver@v0.34.1` (the
version cozystack-api builds against), which reproduces the panic, and
previously confirmed end-to-end on `kindest/node:v1.33.1`.
### Upstream
The underlying nil-dereference is a Kubernetes KCM bug — the VAP status
type-checker should treat `additionalProperties: true` as dynamic rather
than panic. A separate upstream report is being prepared; cozystack
fixes the symptom immediately with the schema change above.
Fixes#2863
### Release note
```release-note
fix(api): publish the free-form resource `.spec` as `x-kubernetes-preserve-unknown-fields` instead of `additionalProperties: true`, fixing a cluster-wide `kube-controller-manager` CrashLoopBackOff (nil-pointer panic in the ValidatingAdmissionPolicy status type-checker) that stalled installs.
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Ensured published OpenAPI schemas no longer contain boolean-form
additionalProperties anywhere; top-level and nested schemas now use
preserve-unknown-fields for free-form specs, preventing
validation/runtime issues.
* **Tests**
* Added regression tests that feed varied untrusted schemas and verify
boolean additionalProperties are removed and published schemas remain
valid for tooling.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What this PR does
The SeaweedFS 4.31 chart bump (#2834) broke E2E for **every** PR on
`main`: in `tenant-root` the `seaweedfs-system` release never becomes
ready, so `install-cozystack` times out waiting on its HelmRelease. Two
regressions came in with the new chart; both reproduce with a plain
`helm template` of `packages/system/seaweedfs` (no cluster needed) and
are fixed here as vendored patches re-applied by `make update`, with
helm-unittest coverage.
**1. S3 served plaintext while everything expected HTTPS.** Until chart
4.05 the `-cert.file`/`-key.file` args were rendered whenever
`enableSecurity` was set, so `weed s3` served TLS on the main port
(8333). Chart 4.31 nested those args inside `{{- if .Values.s3.httpsPort
}}`, and we ship `httpsPort: 0` — so no TLS args rendered, s3 spoke
HTTP, and the HTTPS readiness/liveness probes (plus the ingress
`backend-protocol: HTTPS` and the COSI sidecar's `https://` endpoint)
all failed with `server gave HTTP response to HTTPS client`.
`patches/s3-tls-main-port.patch` moves the cert/key args back out of the
`httpsPort` gate, restoring TLS-on-main-port; `-port.https` is still
only added when `httpsPort` is set.
**2. COSI provisioner ServiceAccount name mismatch.**
`cosi-service-account.yaml` and the `ClusterRoleBinding` name the SA
`<global.seaweedfs.serviceAccountName>-objectstorage-provisioner`, but
the Deployment referenced `componentName`
(`<release>-objectstorage-provisioner`). Whenever `serviceAccountName`
!= release name — our case, `tenant-root-seaweedfs` vs
`seaweedfs-system` — the Deployment could not create pods
(`serviceaccount "seaweedfs-system-objectstorage-provisioner" not
found`). `patches/cosi-provisioner-sa-name.patch` aligns the Deployment
with the SA and the binding. (Upstream installs only avoid this because
their release name and serviceAccountName usually coincide.)
This is `main`-only: the 4.31 chart landed only on `main`, every release
branch is still on 4.05, so no `backport` is needed.
### Release note
```release-note
fix(seaweedfs): restore S3 TLS on the main port and fix the COSI provisioner ServiceAccount name after the 4.31 chart bump, so tenant SeaweedFS becomes ready again
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Fixed S3 TLS certificate arguments to render correctly when HTTPS port
is disabled.
* Updated COSI provisioner to use configurable service account naming.
* **Tests**
* Added regression tests for S3 TLS configuration and COSI service
account handling.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What this PR does
The e2e cluster bootstrap (`hack/e2e-prepare-cluster.bats`) let
`talosctl gen config`
pick its bundled default Kubernetes version — **v1.33.1** for Talos
v1.13.0.
v1.33.1 predates the fix for the kube-controller-manager
`ValidatingAdmissionPolicy`
status type-checker nil-pointer panic on `additionalProperties: true`
schemas
([kubernetes/kubernetes#135155](https://github.com/kubernetes/kubernetes/pull/135155),
backported to `release-1.33` in
[#136958](https://github.com/kubernetes/kubernetes/pull/136958), first
released in
**v1.33.10**). Because `cozystack-api` publishes `additionalProperties:
true` on the
aggregated Tenant schema, KCM crash-loops cluster-wide during install on
the old
default and fails E2E (#2863).
This pins the e2e **management** cluster to **v1.33.12** (latest 1.33
patch), which
contains the fix. It complements — and is independent of — the
schema-side fix in
#2867; either alone avoids the panic.
Refs: #2863
### Release note
```release-note
NONE
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated end-to-end test cluster configuration to explicitly pin the
Kubernetes version for more consistent test execution.
* Added explanatory comments clarifying the version choice and kept
existing secret/configuration wiring intact.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
The 4.31 chart bump (#2834) broke E2E for every PR: tenant-root
seaweedfs-system never becomes ready.
1. S3 served plaintext. Until 4.05 the -cert.file/-key.file args were
rendered whenever enableSecurity was set, so weed s3 served TLS on the
main port (8333); 4.31 nested them under 'if s3.httpsPort' and we ship
httpsPort=0, so s3 spoke HTTP while the HTTPS probes, the ingress
backend-protocol and the COSI sidecar endpoint all expected HTTPS
('server gave HTTP response to HTTPS client'). Restore the 4.05
behaviour via patch.
2. COSI provisioner ServiceAccount mismatch. cosi-service-account.yaml
and the ClusterRoleBinding name the SA
<serviceAccountName>-objectstorage-provisioner, but the Deployment
referenced componentName (<release>-objectstorage-provisioner). When
serviceAccountName != release name (tenant-root-seaweedfs vs
seaweedfs-system) the Deployment could not create pods
('serviceaccount not found'). Align the Deployment with the SA + binding.
Both fixes are vendored as patches re-applied by 'make update', and
covered by helm-unittest.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Andrei Kvapil <andrei.kvapil@aenix.io>
Address review feedback from gemini-code-assist on pkg/cmd/server/openapi.go:
markOpenObject and sanitizeForV2 initialized s.Extensions with the generic
map[string]any{}; use the named spec.Extensions{} type instead, matching the
kube-openapi types and the generated definitions in zz_generated.openapi.go.
No behavioral change — spec.Extensions is defined as map[string]interface{}.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Address review feedback from lexfrei and coderabbitai on
pkg/cmd/server/openapi_test.go:
TestPatchSpecSanitizesUserSuppliedBooleanAdditionalProperties only exercised the
top-level, properties, items, and allOf positions, leaving the one remaining
type-checker-reachable sanitizer branch untested: a boolean additionalProperties
nested inside an object-form additionalProperties. Deleting that recursion line
kept the whole suite green while the input panicked SchemaDeclType again (#2863).
Add the nested-under-additionalproperties case (the reachable blocker, verified
red->green by mutation) plus anyOf/oneOf/not cases (defense-in-depth: those
branches are recursed by the sanitizer but never traversed by SchemaDeclType, so
the hasBooleanAdditionalProperties assertion guards them). Rewrite the test
docstring to distinguish the type-checker-reachable cases from the
defense-in-depth ones, replacing the inaccurate "each case panics SchemaDeclType"
note.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Replacing the whole resources block dropped cloned values the override
did not name (e.g. the inherited cpu limit when only a memory limit is
configured), contradicting the documented inherit-when-empty semantics.
Also document the intentional provisioner-vs-placement sizing
asymmetry.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Andrei Kvapil <andrei.kvapil@aenix.io>
ComputePlacement ignores pins to non-existent shards, but rebalance
treated any pinned tenant as sticky, so an invalid pin blocked expected
moves. Honor only pins placement itself honors.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Andrei Kvapil <andrei.kvapil@aenix.io>
A failed patch no longer refreshes the rebalance cooldown or inflates
the moves counter, so retries are not delayed and not double-counted.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Andrei Kvapil <andrei.kvapil@aenix.io>
head -n 1 closing the pipe early under pipefail aborts the migration
once the HelmRelease name list outgrows the pipe buffer; count with
wc -l instead.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Andrei Kvapil <andrei.kvapil@aenix.io>
The README advertised cozy_flux_shard_* metrics while the endpoint was
disabled as shipped: serve them plain-HTTP on :8080 with scrape
annotations so the autosizing recommendation is actually observable.
Run the operator non-root with a read-only rootfs, dropped capabilities
and modest resources, quote the inject-ca-from annotation for YAML
tooling, and document the fresh-install bootstrap chain.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Andrei Kvapil <andrei.kvapil@aenix.io>
The Update handler rebuilds the HelmRelease from the Application, which
re-stamped sharding.fluxcd.io/key with the ApplicationDefinition default
and bounced the HelmRelease off its operator-assigned shard on every
update. Carry the live label over from the current HelmRelease instead.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Andrei Kvapil <andrei.kvapil@aenix.io>
The submodule still pulled golang.org/x/net v0.53.0, affected by GO-2026-5026
(failure to reject ASCII-only Punycode-encoded labels in golang.org/x/net/idna,
which the submodule imports). The root module was already on v0.55.0; align the
submodule so the advisory is closed across both go.mod files.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Clears the OpenSSF Scorecard Vulnerabilities check (was 0/10). An
osv-scanner pass over both go.mod files reported 12 advisories:
- 10 stdlib advisories against the Go toolchain pinned at 1.26.2
(GO-2026-4918/4971/4977/4980/4982/4986 fixed in 1.26.3;
GO-2026-5037/5038/5039 fixed in 1.26.4) — closed by raising the go
directive to 1.26.4 in both the root module and api/apps/v1alpha1.
- golang.org/x/net 0.52.0 (GO-2026-4918, GO-2026-5026) — bumped to
v0.55.0; go mod tidy carried the matching x/crypto, x/sys, x/term,
x/text and x/tools minor bumps via MVS.
After the bump osv-scanner reports 0 advisories. Both modules build,
and 'make generate' produces no drift (codegen-drift stays green).
Versions were changed with 'go mod edit'/'go get'/'go mod tidy', not by
hand-editing the generated go.mod.
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Assisted-By: Claude <noreply@anthropic.com>
The e2e cluster bootstrap let `talosctl gen config` pick its bundled
default Kubernetes version (v1.33.1 for Talos v1.13.0). That version
predates the fix for the kube-controller-manager ValidatingAdmissionPolicy
status type-checker nil-pointer panic on `additionalProperties: true`
schemas (kubernetes/kubernetes#135155, backported to release-1.33 in
#136958, first released in v1.33.10). cozystack-api's aggregated Tenant
schema publishes `additionalProperties: true`, so on the older default
KCM crash-loops cluster-wide during install and fails E2E.
Pin the e2e management cluster to v1.33.12 (latest 1.33 patch) so it runs
a Kubernetes that contains the fix. This complements the schema-side fix
in #2867 and is independent of it.
Refs: #2863
Assisted-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Addresses review feedback on #2863. The previous fix only converted the open
spec wrapper cozystack-api injects, so a user-supplied ApplicationDefinition
openAPISchema carrying a boolean additionalProperties — declared explicitly at
the top level, or nested under properties/items/allOf/anyOf/oneOf — was
republished verbatim and re-triggered the kube-controller-manager VAP
type-checker crash. openAPISchema is untrusted input (external-apps and
operator-authored definitions flow through unvalidated), so close the whole
class rather than only the schemas cozystack ships.
Recursively rewrite every boolean-form additionalProperties (nil inner schema):
additionalProperties:true becomes x-kubernetes-preserve-unknown-fields:true,
additionalProperties:false is dropped. Both JSON forms carry a nil inner schema
and crash the type-checker identically; object-form maps are recursed into and
left intact. Also publish the schemaless spec from a fresh schema so no
inherited $ref or properties leak into the open object.
Regression tests cover top-level true/false and nested (properties, items,
allOf) boolean forms, asserting the published schema carries no boolean
additionalProperties node and does not panic SchemaDeclType.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
## What this PR does
Re-vendors the SeaweedFS Helm chart from 4.05 (chart 4.0.405) to 4.31
(chart 4.31.0) via `make update`, and adapts the package layer to the
breaking changes that accumulated across the gap.
What lands with the bump: the PostgreSQL filer store (the backend used
here) moves to pgx v5 with PgBouncer support and an `ON CONFLICT` upsert
default; HTTPS certificates hot-reload without a pod restart on
cert-manager rotation; more S3 and volume Prometheus metrics are
exported, and the S3 Service now exposes a metrics port by default.
Package-layer adaptations:
- **Dropped `s3-traffic-distribution.patch`.** Native
`s3.trafficDistribution` support landed upstream in chart 4.12. The
native field is gated to Kubernetes >= 1.31 and auto-converts
`PreferClose` to `PreferSameZone` on >= 1.35, which the hardcoded patch
did not do. The patch is replaced with `s3.trafficDistribution:
PreferClose` in the package values, plus helm-unittest coverage pinning
all three version cases.
- **Migrated `global.*` to `global.seaweedfs.*`.** Chart 4.18 namespaced
the app-specific globals to avoid polluting the shared global namespace
when the chart is used as a subchart. The package values move
`enableSecurity`, `serviceAccountName`, `extraEnvironmentVars` and
`monitoring` to the new path instead of relying on the chart's
backward-compat shim.
Verified with `helm template` and `helm unittest`: the cluster env vars
reach the pods, the gRPC mTLS `security.toml` renders intact (including
the new admin/worker sections from the 4.24/4.26 security tightening),
and both retained patches still apply.
### Screenshots
N/A — no UI changes.
### Release note
```release-note
chore(seaweedfs): bump SeaweedFS to 4.31
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* OpenShift support and dedicated values for secure deployments
* S3 Iceberg gateway with optional ingress and service settings
* Volume UI ingress support and RocksDB variant guidance
* Grafana: new “Upload Errors” panel
* **Bug Fixes**
* Improved S3 traffic distribution handling across Kubernetes versions
* **Documentation**
* Expanded README: DB init, admin secret options, worker job types,
OpenShift notes
* **Chores**
* Helm chart bumped to 4.31.0; values restructured for SeaweedFS and
COSI bucket class simplified
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
cozystack-api published the free-form ".spec" of aggregated apps.cozystack.io
resources (Tenant, Application, ...) as the boolean `additionalProperties: true`.
The Kubernetes ValidatingAdmissionPolicy status type-checker run by
kube-controller-manager nil-dereferences when it recurses into that node, so as
soon as a VAP matches one of these resources (cozystack-tenant-host-policy on
tenants) KCM CrashLoopBackOffs cluster-wide and stalls reconciliation, failing
cold installs once the 3x install retry was removed.
Emit `x-kubernetes-preserve-unknown-fields: true` instead. It is semantically
equivalent ("arbitrary fields allowed") and the type-checker handles it safely.
All app custom schemas already use the safe object-form additionalProperties,
so patchSpec was the only source of the boolean form.
Adds a regression test that reproduces the exact crash through
k8s.io/apiserver/pkg/cel/openapi.SchemaDeclType (the entry point KCM uses): it
panics on the pre-fix code and passes after the fix.
Fixes#2863
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
The Watch goroutine never closed the events channel it owns, and
ProxyWatcher.Stop does not close the channel it proxies. When the
backing watcher ended, consumers ranging over ResultChan blocked until
their own timeout instead of seeing end-of-stream. Closing the channel
on goroutine exit matches the watch.Interface contract and the pattern
already used by the tenantmodule and application registries.
Goroutine-termination tests now assert the result channel closes.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Four goroutine-termination tests duplicated the same IsStopped polling
loop; waitForFakeWatcherStop keeps the deadline logic in one place.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Manual runtime.NewScheme setups in the List/Get error-path tests silently
discarded AddToScheme errors; the shared helper fails the test instead.
Renamed from newWatchTestScheme since it now serves both test files.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Upstream treats a missing parent VM as detach success, so when the VMI
outlives its VM during node reprovisioning the hot-plug pod keeps the
infra device exclusively attached to the source host and subsequent
attaches fail. Re-check VMI volume status after upstream unpublish and
detach from the VMI directly. Backport of kubevirt/csi-driver#184.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Andrei Kvapil <andrei.kvapil@aenix.io>
