mirror of
https://github.com/cozystack/cozystack.git
synced 2026-11-09 22:13:18 +09:00
v1.6.5
5400
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 myasnikovdaniil
|
908b107ab4 |
chore(release): promote v1.6.5-rc.3 -> v1.6.5 (#4937)
Promotes `v1.6.5-rc.3` to stable `v1.6.5` without rebuilding containers. Their digests remain bit-for-bit what passed rc e2e; the tag-rewritten packages tree is re-serialized as a temporary OCI candidate and pinned here by digest. On merge, pull-requests-release.yaml verifies that candidate against this tree before creating the write-once `v1.6.5` tag, retagging the candidate and container digests to `v1.6.5` (+`:latest` when this is the newest stable), publishing the stable cozy-installer chart, and publishing the release. Do NOT squash-merge (decision B): the stable tag must attach to a real merge commit. ✅ RC full e2e was verified for `v1.6.5-rc.3` before promotion. ℹ️ E2E already ran against the immutable rc, so this promote PR does not run E2E by default. A maintainer may add the `full-e2e` label to run the full suite again. ✅ Includes `docs/changelogs/v1.6.5.md`, which finalize uses verbatim as the published release body. ✅ Website docs PR opened/refreshed on `cozystack/website` (branch `update-docs-v1.6.5`), generated from the `release-1.6.5` staging branch. **Do NOT merge that PR until `v1.6.5` is published** — merging it early flips the site's latest-version pointer to an unpublished version and 404s its docs/API links (see the PR body).api/apps/v1alpha1/v1.6.5 v1.6.5 |
||
|
cozystack-ci[bot]
|
7dfc094583 |
docs: add changelog for v1.6.5
Signed-off-by: cozystack-ci[bot] <274107086+cozystack-ci[bot]@users.noreply.github.com> |
||
|
cozystack-ci[bot]
|
c294e5fd64 |
Pin promoted packages artifact for v1.6.5
Signed-off-by: cozystack-ci[bot] <274107086+cozystack-ci[bot]@users.noreply.github.com> |
||
|
cozystack-ci[bot]
|
0824833c4b |
Prepare release v1.6.5 (promoted from v1.6.5-rc.3)
Signed-off-by: cozystack-ci[bot] <274107086+cozystack-ci[bot]@users.noreply.github.com> |
||
|
cozystack-ci[bot]
|
8ea06cdab5 |
Prepare release v1.6.5-rc.3
Signed-off-by: cozystack-ci[bot] <274107086+cozystack-ci[bot]@users.noreply.github.com> |
||
|
myasnikovdaniil
|
5a7531a339 |
[Backport release-1.6] fix(tcp-balancer): rename backends and pin HAProxy so the chart starts on 3.3+ (#4516)
## What this PR does Backports #4366 to release-1.6. All three original commits applied without conflicts and retain their cherry-pick references. HAProxy is pinned to 3.4.4 and backend names no longer collide with frontend names. An empty whitelist leaves Kubernetes and Talos frontends unfiltered. Enabling whitelistHTTP without a whitelist fails rendering. Validation passed with 9 Helm tests, five rendered configurations checked by HAProxy 3.4.4, and package generation without changes. The old chart reproduces the name collision. Removing only the HTTP reject rule makes the regression test fail. ### Downstream repositories - [x] No downstream repository is affected by this change - [ ] [cozystack/website](https://github.com/cozystack/website) - follow-up: - [ ] [cozystack/terraform-provider-cozystack](https://github.com/cozystack/terraform-provider-cozystack) - follow-up: - [ ] [cozystack/ansible-cozystack](https://github.com/cozystack/ansible-cozystack) - follow-up: - [ ] [cozystack/ccp](https://github.com/cozystack/ccp) - follow-up: - [ ] [cozystack/talm](https://github.com/cozystack/talm) - follow-up: - [ ] [cozystack/cozyhr](https://github.com/cozystack/cozyhr) - follow-up: - [ ] [cozystack/cozy-proxy](https://github.com/cozystack/cozy-proxy) - follow-up: - [ ] [cozystack/cozystack-telemetry-server](https://github.com/cozystack/cozystack-telemetry-server) - follow-up: - [ ] [cozystack/external-apps-example](https://github.com/cozystack/external-apps-example) - follow-up: - [ ] [cozystack/examples](https://github.com/cozystack/examples) - follow-up: - [ ] [cozystack/community](https://github.com/cozystack/community) - follow-up: ### Release note ```release-note fix(tcp-balancer): backport HAProxy 3.4.4, distinct backend names and whitelist validation to 1.6. ```v1.6.5-rc.3 |
||
|
myasnikovdaniil
|
2b90e8cf45 |
[Backport release-1.6] fix(kubernetes): break bootstrap-token Job out of Helm hook to unblock fresh installs (#4541)
<!-- Thank you for making a contribution! Here are some tips for you: - Use Conventional Commits for the PR title: `type(scope): description` - Types: feat, fix, docs, style, refactor, perf, test, build, ci, chore - Scopes are not an exhaustive list — pick the most specific scope for the change and extend the list when a genuinely new area appears. Examples: - System components: dashboard, platform, operator, cilium, kube-ovn, linstor, fluxcd, cluster-api - Managed apps: postgres, mariadb, redis, kafka, clickhouse, virtual-machine, kubernetes - Development and maintenance: api, hack, tests, ci, docs, maintenance - Breaking changes: append `!` after type/scope (`feat(api)!: ...`) or add a `BREAKING CHANGE:` footer - If it's a work in progress, consider creating this PR as a draft. - Don't hesistate to ask for opinion and review in the community chats, even if it's still a draft. - Add the label `backport` if it's a bugfix that needs to be backported to a previous version. --> ## What this PR does Backports #3887 to `release-1.6`. The fix reached `main` only: `v1.6.3` and `v1.6.4` both still ship the bootstrap-token Job as a `post-install,post-upgrade` Helm hook, and `git tag --contains` on the merge commit returns `v1.7.0-alpha.1` and nothing from the 1.6 line. Tracked as #4539. #3875 describes the deadlock this removes: the chart upgrade waits for `MachineDeployment` and the child HelmReleases, workers cannot register without the `bootstrap-token-<id>` Secret in the guest cluster, and the hook that creates that Secret only runs once the wait has already succeeded. The wait cannot succeed without nodes, so the upgrade times out and Flux retries the same cycle indefinitely. It is deterministic rather than flaky, and it takes out every tenant Kubernetes cluster on the platform at once. What makes the backport worth filing separately: anyone hitting this on 1.6.3 finds #3875 closed in the tracker, upgrades to 1.6.4 expecting the fix, and lands in exactly the same state. Observed on a production cluster before the manual workaround: machines stuck in `Provisioned` with no `NODENAME`, VMIs `Running` with IPs assigned, guest clusters reporting `No resources found` for nodes, and no bootstrap-token Secret anywhere in the guest `kube-system`. Creating the Secret by hand brought nodes up within 90 seconds on each affected tenant. `git cherry-pick --mainline 1` of the merge commit applied cleanly with no conflicts, and nothing was changed on top: the diff here is identical to what merged on `main`. Validation, `helm unittest` in `packages/apps/kubernetes` including `tests/talos_templates_test.yaml` which this change extends: ``` Charts: 1 passed, 1 total Test Suites: 19 passed, 19 total Tests: 189 passed, 189 total ``` ### Screenshots Not applicable, no UI changes. ### Downstream repositories <!-- Cozystack is upstream for repositories that are NOT kept in sync with it automatically, and nothing in CI compares the two sides, so a change here can break them silently. Which change forces what, and which file to touch, is the trigger map in docs/agents/contributing.md under "Downstream Repositories". Walk it before you tick anything. IF YOU ARE AN AI AGENT OR AN LLM, THIS IS PART OF THE TASK, NOT A FORM TO FILL IN: 1. Walk the trigger map against the actual diff of this PR, file by file. Do not decide from the PR title or from your memory of what you changed. 2. For every repository you tick, open the follow-up PR there and link it on the same line. A ticked box with no link claims work that does not exist, which is worse than an empty box. Search that repository for an open PR or issue covering it first, and link that instead of filing a duplicate. 3. When the follow-up is out of scope, or needs a decision that is not yours to make, open an issue in that repository instead, link that, and say so in the PR body. Do not push a speculative PR into another repository just to fill a line here. 4. Do not tick "No downstream repository is affected" to make the checklist go away. If you are unsure, leave every box empty and say so in the PR body, so a human decides. --> - [x] No downstream repository is affected by this change - [ ] [cozystack/website](https://github.com/cozystack/website) - follow-up: - [ ] [cozystack/terraform-provider-cozystack](https://github.com/cozystack/terraform-provider-cozystack) - follow-up: - [ ] [cozystack/ansible-cozystack](https://github.com/cozystack/ansible-cozystack) - follow-up: - [ ] [cozystack/ccp](https://github.com/cozystack/ccp) - follow-up: - [ ] [cozystack/talm](https://github.com/cozystack/talm) - follow-up: - [ ] [cozystack/cozyhr](https://github.com/cozystack/cozyhr) - follow-up: - [ ] [cozystack/cozy-proxy](https://github.com/cozystack/cozy-proxy) - follow-up: - [ ] [cozystack/cozystack-telemetry-server](https://github.com/cozystack/cozystack-telemetry-server) - follow-up: - [ ] [cozystack/external-apps-example](https://github.com/cozystack/external-apps-example) - follow-up: - [ ] [cozystack/examples](https://github.com/cozystack/examples) - follow-up: ### Release note <!-- Write a release note: - Explain what has changed internally and for users. - Start with the same `type(scope):` prefix as in the PR title - Follow the guidelines at https://github.com/kubernetes/community/blob/master/contributors/guide/release-notes.md. --> ```release-note fix(kubernetes): create the tenant bootstrap-token Secret outside the Helm hook, so Talos workers can register during a chart upgrade instead of deadlocking against the wait that needs them ``` |
||
|
myasnikovdaniil
|
234dfdaaae |
[Backport release-1.6] fix(api): keep a suspended HelmRelease suspended across an app update (#4928)
## What this PR does Backport of #4411 to `release-1.6`. `REST.Update` rebuilds the HelmRelease from the Application and writes it back whole, and Application has no suspension, so every edit through the API resumes a release that an operator or a controller suspended. The CNPG restore driver depends on it: it suspends the target release, patches the Postgres app through this API, purges the Cluster and resumes only after the purge, so the next render lands `bootstrap.recovery` on an empty namespace. When the patch resumes the release, helm-controller upgrades right away, the Cluster gets rendered while the purge still runs, the driver deletes it, and nothing renders it again because the values don't change anymore. RestoreJob stays `Running` until its deadline. Why it is needed on this line now. The race was hidden by timing: Update dropped `finalizers.fluxcd.io`, helm-controller spent its first pass putting it back and requeued, and that delay usually let the purge finish first. #4683 and #4919 keep the finalizer across the write, so the delay is gone. After they landed, `postgres-2-backup-roundtrip` failed on v1.6.5-rc.1 (https://github.com/cozystack/cozystack/actions/runs/38583543706) and in two earlier PR runs, each time stuck at `TargetPurged: Cluster ... deleted; awaiting chart-rendered re-bootstrap`. In the snapshot of the rc run the HelmRelease of the restore target upgraded to v2 at 16:16:13Z, the Cluster was deleted at 16:16:22Z, and no Cluster of the target exists afterwards. The cherry-pick conflicted only in comments of `REST.Update`, where this branch already has the metadata carry-over. The two `Spec.Suspend` assignments merged unchanged and the comments read as they do on main. ### Validation - `go build ./...` is clean, `go vet ./pkg/registry/...` is clean, `go test ./pkg/registry/... ./internal/backupcontroller/...` passes. - Removing either `Spec.Suspend` assignment turns its test red: `TestUpdate_PreservesSuspend` for the first write, `TestUpdate_RefreshesSuspendOnConflictRetry` for the conflict retry. - Not run here: the restore round trip on a live cluster, the E2E of this PR covers it. ### Downstream repositories It changes how the aggregated API writes the HelmRelease back, no downstream repository restates that. - [x] No downstream repository is affected by this change - [ ] [cozystack/website](https://github.com/cozystack/website) - follow-up: - [ ] [cozystack/terraform-provider-cozystack](https://github.com/cozystack/terraform-provider-cozystack) - follow-up: - [ ] [cozystack/ansible-cozystack](https://github.com/cozystack/ansible-cozystack) - follow-up: - [ ] [cozystack/ccp](https://github.com/cozystack/ccp) - follow-up: - [ ] [cozystack/talm](https://github.com/cozystack/talm) - follow-up: - [ ] [cozystack/cozyhr](https://github.com/cozystack/cozyhr) - follow-up: - [ ] [cozystack/cozy-proxy](https://github.com/cozystack/cozy-proxy) - follow-up: - [ ] [cozystack/cozystack-telemetry-server](https://github.com/cozystack/cozystack-telemetry-server) - follow-up: - [ ] [cozystack/external-apps-example](https://github.com/cozystack/external-apps-example) - follow-up: - [ ] [cozystack/examples](https://github.com/cozystack/examples) - follow-up: ### Release note ```release-note fix(api): app edit through cozystack API no longer resumes a suspended HelmRelease, so postgres restore waits for its purge before the cluster is rendered again. ```v1.6.5-rc.2 |
||
|
Myasnikov Daniil
|
b5525f5b94 |
fix(api): keep a suspended HelmRelease suspended across an app update
Update rebuilds the HelmRelease from the Application and writes it back
whole, and the Application carries no suspension, so every edit made
through the API resumed a release that an operator or a controller had
suspended.
The CNPG restore driver depends on that suspension. It suspends the
target release, patches the Postgres app through this API, purges the
Cluster, and resumes only once the purge is done, so the chart's next
render lands bootstrap.recovery on an empty namespace. Resumed by the
patch instead, helm-controller upgrades straight away: the chart can
render the recovery Cluster while the purge is still running, the
driver then deletes it as the Cluster being replaced, and nothing
renders it again because the values have not changed since. The
RestoreJob sits in Running until its deadline.
On main this has been masked by timing rather than prevented. The same
write also dropped the Flux finalizer, so helm-controller's first pass
after it only put the finalizer back and requeued, which held the
upgrade back by at least its 750ms minimum retry delay. A branch that
keeps the finalizer removes that delay, and the backup round-trip
failed on both of its runs there.
The suspension is re-read on a conflict retry as well, since the write
that caused the conflict may be the suspend itself.
The conflicts were in the comments of REST.Update, where this branch
already carries the metadata carry-over of the HelmRelease. The two
Spec.Suspend assignments merged unchanged and the comments read as
they do on main.
Assisted-by: LLM
(cherry picked from commit
|
||
|
myasnikovdaniil
|
6688ddf34e |
[Backport release-1.6] fix(cilium)!: take cilium's own addresses from a block kube-ovn does not hand out (#4918)
## What this PR does Backport of #4778 to `release-1.6`, fixes #3740 on the 1.6 line. On the kube-ovn variants (`isp-full`, `isp-full-generic`) cilium allocates no pod IPs, but it still takes its router IP and the Gateway API ingress IP from `Node.spec.podCIDR`, a /24 out of the same range kube-ovn hands pods from, so sooner or later kube-ovn gives a pod an address cilium already holds. With this change cilium runs `ipam.mode: cluster-pool` with a /29 per node out of the last /21 of `networking.podCIDR`, platform passes the same range to kube-ovn as `--default-exclude-ips`, and a post-upgrade hook in the cilium chart moves existing clusters. Mechanism and hook steps are the same as in #4778, its description has the details. This is breaking for a patch release, please read before merging: - `networking.podCIDR` has to be /20 or wider on the kube-ovn variants, otherwise platform refuses to render and the upgrade stops before anything changes. Widening the value later doesn't help, the hook refuses a block outside the subnet the cluster was installed with. - A /21 of /29s caps these variants at 256 nodes. - Every cilium agent restarts twice, once for the config change and once in the hook. While the cilium release is failed, packages that depend on networking wait for it. - If kube-ovn already handed out an address from the last /21, the hook names that address and stops before it moves any node. Recreate the pods holding it and the next retry goes through. - Rolling back to 1.6.4 brings `ipam.mode: kubernetes` back, agents take their /24 again, and the exclusions stay in `ovn-default`. ### Differences from #4778 - No slim variants on release-1.6, so the `cozystack.platform.slim` gate is gone and the pool is wired in the `isp-full` and `isp-full-generic` branches only. `isp-hosted` renders `noop` and is not touched. - The code around the wiring in `system.yaml` is release-1.6's (no `gateway.http2`, no `networking.encryption`, the older `cozystack.platform.package` call). - The wiring test for `isp-slim` is left out of the cherry-pick, the second commit adds one for `isp-hosted` with a /24 pod CIDR, which has to keep rendering without the /20 requirement. - `packages/system/cilium` has no `make test` target here, so `hack/helm-unit-tests.sh` would skip the new suite without a word. The third commit adds it. - The follow-up from main that loads `test_helper` in `hack/cilium-ipam-migration.bats` is not applied. release-1.6 has no `hack/test_helper.bash` and runs `hack/*.bats` through `hack/cozytest.sh`, with that line the file doesn't load. - release-1.6 ships kube-ovn v1.15.10, #4778 was written against v1.15.26. ### Validation - `helm unittest`: cilium 11/11, platform 113/113 with #4808 merged. `hack/cilium-ipam-migration.bats` passes 27/27 through `hack/cozytest.sh`. - Live hook run on a three-node Talos cluster with kube-ovn v1.15.10. I put cilium on the release-1.6 chart first, then upgraded to this branch with `helm upgrade` (operator stopped, HelmRelease suspended). A pod pinned to `10.244.250.10` made the hook add the block and the old ingress IPs to `excludeIps` of `ovn-default`, name that address and stop before moving any node. After deleting the pod the same upgrade moved all three nodes to /29s from `10.244.248.0/21`, router and ingress IPs inside. The available range of the subnet ends at `10.244.247.255`, no pod IP is duplicated, and pod to pod across nodes, DNS and a ping to a VM pod IP work. A third run of the same upgrade restarted nothing and left the CIDRs as they were. - Rolling the release back on that cluster returned the agents to their /24s with new ingress IPs, and `excludeIps` stayed until I patched it by hand. - Not run: the upgrade through the operator, the generic variant, Gateway API traffic (no gateway on that cluster). kube-ovn still admits a pod with a static `ovn.kubernetes.io/ip_address` inside the block after the migration, the hook looks at it only while migrating. ### Downstream repositories The website note for this change is cozystack/website#739, merged for `docs/next`. The v1.6 docs need the same note, not opened yet, so the box stays empty. - [ ] No downstream repository is affected by this change - [ ] [cozystack/website](https://github.com/cozystack/website) - follow-up: - [ ] [cozystack/terraform-provider-cozystack](https://github.com/cozystack/terraform-provider-cozystack) - follow-up: - [ ] [cozystack/ansible-cozystack](https://github.com/cozystack/ansible-cozystack) - follow-up: - [ ] [cozystack/ccp](https://github.com/cozystack/ccp) - follow-up: - [ ] [cozystack/talm](https://github.com/cozystack/talm) - follow-up: - [ ] [cozystack/cozyhr](https://github.com/cozystack/cozyhr) - follow-up: - [ ] [cozystack/cozy-proxy](https://github.com/cozystack/cozy-proxy) - follow-up: - [ ] [cozystack/cozystack-telemetry-server](https://github.com/cozystack/cozystack-telemetry-server) - follow-up: - [ ] [cozystack/external-apps-example](https://github.com/cozystack/external-apps-example) - follow-up: - [ ] [cozystack/examples](https://github.com/cozystack/examples) - follow-up: ### Release note ```release-note fix(cilium)!: on the kube-ovn variants cilium now takes its router and gateway api ingress ips from the last /21 of networking.podCIDR, which kube-ovn no longer hands out, so pods stop landing on addresses cilium holds. existing clusters move on upgrade through a post-upgrade hook, and each cilium agent restarts twice, once for the config change and once in the hook. networking.podCIDR needs /20 or wider on these variants, and a /21 of /29s caps them at 256 nodes. ```v1.6.5-rc.1 |
||
|
myasnikovdaniil
|
858478cf70 |
[Backport release-1.6] fix(monitoring): send alerts to every Alertmanager replica (#4890)
## What this PR does
Backport of #4889 to `release-1.6`. The commit is cherry-picked from
|
||
|
Myasnikov Daniil
|
c9c21bb2ea |
test(cilium): run the chart's helm unittest suites
hack/helm-unit-tests.sh picks the packages it tests by probing for a make test target, and the cilium package had none, so make unit-tests and CI would skip the IPAM pool suite this package now carries without saying so. Assisted-by: LLM Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com> |
||
|
Myasnikov Daniil
|
8d12955795 |
test(platform): pin the cilium pool wiring to the variants release-1.6 has
The cherry-pick leaves out main's case for the slim variants, which release-1.6 does not have, so that commit's suite stays green on its own. isp-hosted is the one system variant here without kube-ovn, and the /20 requirement must not reach it, so the case renders it with a pod CIDR the kube-ovn variants refuse. Assisted-by: LLM Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com> |
||
|
Yan Bondarenko
|
df320baa14 |
fix(cilium)!: take cilium's own addresses from a block kube-ovn does not hand out
On the kube-ovn variants Cilium allocates no pod addresses, but the agent
still takes its router IP and the Gateway API Ingress IP from its
allocation CIDR. In ipam.mode kubernetes that is Node.spec.podCIDR, which
the documented installs slice from the same range kube-ovn allocates pods
from, so kube-ovn sooner or later hands a pod an address Cilium already
holds.
Cilium now runs ipam.mode cluster-pool on the kube-ovn variants, with a
/29 per node from the last /21 of networking.podCIDR, and kube-ovn
excludes that /21 through --default-exclude-ips. The block stays inside
the pod CIDR on purpose. Envoy reaches Gateway API backends from the
node's Ingress IP, and kube-ovn masquerades host-originated traffic only
when the source lies in one of its subnets, so a block outside them such
as 100.65.0.0/16 breaks Gateway API traffic that crosses nodes.
A post-upgrade hook moves existing clusters. It first checks that the
block has a /29 for every node and lies inside kube-ovn's default
subnet, and stops without changing anything otherwise. It adds the block
and every node's current Ingress IP to excludeIps of that subnet,
because the agent keeps a former Ingress IP in its ipcache as
reserved:ingress. It then waits until kube-ovn stops offering the block
and stops if an address in it is still allocated. kube-ovn leaves
excluded addresses out of the subnet status, so that check reads its IP
objects. Then, one node at a time, it clears the inherited /24 from the
CiliumNode, waits for the operator to allocate from the block and
restarts the agent.
networking.podCIDR now needs a prefix of /20 or shorter on the kube-ovn
variants, and the render fails otherwise. A /21 cut into /29s also caps
these variants at 256 nodes.
Assisted-by: LLM
Signed-off-by: Yan Bondarenko <202671653+yankawai@users.noreply.github.com>
(cherry picked from commit
|
||
|
myasnikovdaniil
|
ec9e105822 |
[Backport release-1.6] fix(velero): bump velero-plugin-for-aws to v1.14.4 so backups work on R2 (#4854)
# Description Backport of #4834 to `release-1.6`. |
||
|
myasnikovdaniil
|
7e8399c057 |
[Backport release-1.6] fix(postgres): read the live Cluster when deciding the WAL-archive prefix (#4592)
# Description Backport of #4299 to `release-1.6`. |
||
|
myasnikovdaniil
|
63dc235b1a |
[Backport release-1.6] fix(api): preserve foreign HelmRelease metadata and repair empty required fields (#4919)
## What this PR does Backport of #2914 and #3956 to `release-1.6`. It sits on top of #4683, which is merged here now. #2914: `Update` on an Application rebuilds the HelmRelease and sends a full-replace PUT, so metadata owned by other controllers was dropped, helm-controller's `finalizers.fluxcd.io` among it. A delete landing before helm-controller added the finalizer back removed the HelmRelease without `helm uninstall` and orphaned every resource of the release. Now `Update` carries over finalizers, ownerReferences and labels/annotations outside the `apps.cozystack.io-` prefix from the live object, `mergeMaps` no longer returns the shared config map that requests wrote into, and a conflict retry rebuilds the carried metadata from the object it just read instead of writing the stale copy back. #3956: a required spec field written with nothing under it (`replicas:`) reached Helm as null, Helm coalescing deletes it together with the chart default before schema validation, and the whole release failed with "missing property" for a property the spec does contain. Such a null is removed on Create and Update now so the chart default applies, and the client gets a warning with the field name. Optional fields, free-form subtrees, user-keyed map entries and array elements keep their nulls. Admission validates the normalized copy, the caller's object is not mutated anymore. On this branch #4683 inlined the garbage collection finalizer merge and the deletion metadata copy, because `applyLiveMetadata` didn't exist yet. They move into `applyLiveMetadata` here, so `Update` and its helpers match main. Suspend preservation (#4411) is not on this branch and not part of this backport. The example field in #3956, `talos.registryMirrors`, doesn't exist in the kubernetes chart on this branch, so the tests use required fields that do (`talos.installerRepository`, `talos.version`, `controlPlane.replicas`). The node group null is its own case, because `nodeGroups` is still a typed map here and its entries require `instanceType`. Three test helpers main has from #3315 are copied into a test-only file. Production code needed one import beyond the cherry-picks. ### Validation - `go build ./...` and `go vet ./pkg/registry/...` are clean and `go test ./pkg/registry/...` passes on the head, rebased onto release-1.6 after #4683 merged. - The Helm coalescing test renders this branch's own chart values and schemas, Helm rejects the empty required fields before the repair and accepts them after it. - Reverting `applyLiveMetadata` to the plain live finalizer list, skipping the retry rebuild, or validating the un-normalized object each turns the related tests red. ### Downstream repositories The change touches the Application REST handler and its tests only: no chart, values, schema, CRD, version enum or `hack/` file, so none of the trigger map entries match. - [x] No downstream repository is affected by this change - [ ] [cozystack/website](https://github.com/cozystack/website) - follow-up: - [ ] [cozystack/terraform-provider-cozystack](https://github.com/cozystack/terraform-provider-cozystack) - follow-up: - [ ] [cozystack/ansible-cozystack](https://github.com/cozystack/ansible-cozystack) - follow-up: - [ ] [cozystack/ccp](https://github.com/cozystack/ccp) - follow-up: - [ ] [cozystack/talm](https://github.com/cozystack/talm) - follow-up: - [ ] [cozystack/cozyhr](https://github.com/cozystack/cozyhr) - follow-up: - [ ] [cozystack/cozy-proxy](https://github.com/cozystack/cozy-proxy) - follow-up: - [ ] [cozystack/cozystack-telemetry-server](https://github.com/cozystack/cozystack-telemetry-server) - follow-up: - [ ] [cozystack/external-apps-example](https://github.com/cozystack/external-apps-example) - follow-up: - [ ] [cozystack/examples](https://github.com/cozystack/examples) - follow-up: ### Release note ```release-note fix(api): updating an Application no longer strips finalizers, ownerReferences and foreign labels/annotations from its HelmRelease, which could make a following delete skip helm uninstall and orphan the release's resources. A required field written with no value in an application spec is treated as unset so the chart default applies, instead of failing the whole release. ``` |
||
|
myasnikovdaniil
|
4334c4b23a |
[Backport release-1.6] feat(openbao): optional static-key auto-unseal and apiserver egress label (#4906)
# Description Backport of #4766 to `release-1.6`. |
||
|
myasnikovdaniil
|
11a0dd2aca |
[Backport release-1.6] fix(dashboard): allow editing free-form objects in application forms (#4905)
# Description Backport of #4682 to `release-1.6`. |
||
|
myasnikovdaniil
|
68d5e5c050 |
[Backport release-1.6] ci(e2e): run nightly and release-tag e2e on the container lane (#4913)
## What this PR does
Backport of #4828 to `release-1.6`.
PR lane on this line runs on Talos containers since the backport of
#4020, but `e2e-tag.yaml` (the rc gate that `tags.yaml` calls for every
rc from `release-1.6`) and `nightly.yaml` still boot QEMU guests. Every
rc tag run here since v1.6.2-rc.1 is red. v1.6.4-rc.1 failed with
kubernetes-latest and kubernetes-previous spending about 32 minutes each
at node-join deadline
(https://github.com/cozystack/cozystack/actions/runs/36124680874), while
the same 41 suites passed on container lane in the v1.6.4 promotion PR,
in a 93 minute job
(https://github.com/cozystack/cozystack/actions/runs/36383277279).
e2e plumbing on `release-1.6` diverged from `main` after #4020, so the
cherry-pick of the first commit has conflicts resolved against this
branch, and there is one prerequisite commit:
- `e2e-tag.yaml` and `nightly.yaml` get the same host module step,
`prepare-env-container`, endpoint and storage class env and two-part
teardown as `pull-requests.yaml` here. `e2e-tag.yaml` still requires the
release to carry its nocloud disk but doesn't download it anymore, and a
dispatch against a tag cut before container lane (v1.6.3 and older)
fails early and says to dispatch with `--ref <tag>`.
- nightly moves to 32-vCPU runner, because `hack/e2e-container-up.sh`
refuses a 24-vCPU host (`main` did the same earlier in
|
||
|
Yasar Rahman
|
b653abd734 |
fix(velero): bump velero-plugin-for-aws to v1.14.4 so backups work on R2
velero-plugin-for-aws v1.14.1 sets x-amz-tagging on every PutObject,
empty when the BackupStorageLocation configures no tags. Cloudflare R2
answers that with 501 NotImplemented ("Header 'x-amz-tagging' with value
'' not implemented"), so Velero cannot write backup metadata and every
backup to an R2 location fails, the cozy-default location included when
the platform bucket is on R2.
The plugin sends the header only when tags are configured since v1.14.3
(velero-plugin-for-aws#309, a backport of #299). v1.14.4 is the current
patch release of the 1.14 line, which upstream lists as the one
compatible with Velero 1.18, and adds only CVE dependency bumps on top
of v1.14.3.
Signed-off-by: Yasar Rahman <yasar.rehman@gmail.com>
Assisted-by: LLM
(cherry picked from commit
|
||
|
Mattia Eleuteri
|
70424ee037 |
fix(postgres): read the live Cluster when deciding the WAL-archive prefix
applyClusterPluginBackup preserves the serverName already on the Cluster, so
that a backup does not flip the archive prefix mid-stream. It read that value
through the manager's cached client, and this controller registers
For(&BackupJob{}) and nothing else, so a Cluster only reaches the cache
through a lazily started informer with no resync tied to its own changes.
An in-place RestoreJob deletes the Cluster and the chart re-renders it with
bootstrap.newServerName seconds later. A read served during that window
describes the object that was purged, so the source's serverName is written
back over the freshly rendered one and the restored cluster archives onto the
source's WAL prefix. barman-cloud-check-wal-archive then refuses to start with
"Expected empty archive" and the RestoreJob ends on its deadline -- the
failure newServerName was added to prevent.
The stale read carries a stale UID too, and that UID owns the ObjectStore this
function applies, so the store is garbage-collected as soon as it is written.
Reading through the dynamic client keeps the preservation rule and makes the
value it rests on truthful.
Assisted-by: LLM
Signed-off-by: Mattia Eleuteri <mattia@hidora.io>
(cherry picked from commit
|
||
|
Myasnikov Daniil
|
77f2d8e9cb |
fix(api): preserve nulls without applicable chart defaults
A schema default cannot fill arbitrary map entries or replacement array
items. Keep those nulls, nullable fields and required fields without a
non-null default unchanged so Helm retains their validation semantics.
Validate the normalized copy on both write paths so admission sees the
values that reach storage without mutating the caller object.
Assisted-By: LLM
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
(cherry picked from commit
|
||
|
Myasnikov Daniil
|
c5ea368b34 |
fix(api): repair an empty required field instead of failing the release
An Application spec reaches flux verbatim as HelmRelease .spec.values,
and Helm's value coalescing deletes a null-valued key together with the
chart default underneath it, before the result is validated against
values.schema.json. A required field written with nothing under it is
therefore rejected for being absent:
talos:
registryMirrors:
fails the whole release with "at '/talos': missing property
'registryMirrors'", naming a property the spec does contain, and nothing
reaching the user points at the empty key they typed.
Remove such a key on the write path, so the chart's own default applies
to it. Filling in the schema default instead would pin today's value
into the stored HelmRelease and freeze the application on it, so a later
bump of that default in the chart would never reach an application that
had once been created with an empty key.
Only required properties are repaired. A required property's null cannot
be load-bearing for anyone, because today it fails the render outright,
so resolving it is pure repair. Where the schema allows the field to be
absent, a null keeps the meaning it has now - the chart default is
suppressed and the key does not reach the template - and that meaning is
worth keeping: 167 optional fields across the catalogue carry a
non-trivial default, placeholder credentials and example S3 buckets
among them, so resolving a user's null to one of those would be worse
than leaving the key out.
Free-form subtrees, null map entries under a user-chosen key (a node
group, a registry host) and array elements are left as written, because
there a null may be the payload rather than an omission. Every removal
is reported back to the client as a warning, so the repair is visible
rather than silent.
Assisted-By: LLM
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
(cherry picked from commit
|
||
|
Mattia Eleuteri
|
b21e4873f9 |
fix(api): redo the HelmRelease metadata carry-over on a conflict retry
A 409 on the HelmRelease PUT means the live object changed after the
read the carry-over was built from, and the writer behind it is normally
helm-controller - the controller whose finalizer the carry-over exists
to protect, and which re-adds it on the reconcile following a
metadata-only update. Retrying with the metadata read before the
conflict wrote that stale copy back and dropped the finalizer the
reconcile had just restored, reopening the orphaning window the
carry-over closes.
Assisted-by: LLM
Signed-off-by: Mattia Eleuteri <mattia@hidora.io>
(cherry picked from commit
|
||
|
mattia-eleuteri
|
1f3b161956 |
fix(api): make mergeMaps always allocate, never return an input map
mergeMaps returned one of its inputs whenever the other was nil. Create
and Update seed the HelmRelease labels with
mergeMaps(r.releaseConfig.Labels, ...) and then write the application
metadata labels into the result in place, so for an Application with no
labels the writes landed on the long-lived config map shared by every
request for the kind: requests cross-contaminate (application.name
varies per request) and concurrent map writes crash the apiserver.
Signed-off-by: mattia-eleuteri <mattia@hidora.io>
(cherry picked from commit
|
||
|
mattia-eleuteri
|
39a6d36920 |
fix(api): preserve foreign HelmRelease metadata on Application update
Update rebuilds the HelmRelease from the Application and issues a
full-replace PUT, which stripped metadata owned by other controllers:
finalizers, ownerReferences, and any labels or annotations outside the
apps.cozystack.io- prefix. Losing helm-controller's
finalizers.fluxcd.io finalizer is the harmful case: a delete landing
before helm-controller re-adds it removes the HelmRelease without
running helm uninstall, orphaning every resource of the release (VMs,
databases, PVCs). A label patch immediately followed by a delete - a
common client pattern - hits that window almost every time.
Fetch the current HelmRelease before the PUT and carry over its
finalizers, ownerReferences, and non-prefixed labels and annotations.
Keys under the apps.cozystack.io- prefix remain owned by the API and
are recomputed from the Application, so label/annotation deletions
still propagate.
Signed-off-by: mattia-eleuteri <mattia@hidora.io>
(cherry picked from commit
|
||
|
myasnikovdaniil
|
13e202a53e |
[Backport release-1.6] feat(monitoring): add optional email receiver to alertmanager (#4614)
## What this PR does Manual backport of #3800 to `release-1.6`. The automated backport, #4609, stopped on a conflict in `packages/system/monitoring-rd/cozyrds/monitoring.yaml` and pushed the markers as its only commit, so it would ship conflict markers in the ApplicationDefinition if merged. That file is generated, and its schema and `keysOrder` lines already differ between main and 1.6 for reasons unrelated to this change. Everything else applies unchanged. I kept the `release-1.6` version of the file and ran `make generate` in `packages/extra/monitoring` with cozyvalues-gen 1.6.0. The README and `values.schema.json` came out identical to the cherry-picked ones, and the regenerated schema adds exactly the eight `alerta.alerts.email` properties that #3800 adds on main, with nothing removed. Verified on this branch: `helm unittest` passes 164 tests in 8 suites for `packages/system/monitoring`, both new email suites included, and 9 tests for `packages/extra/monitoring`. The file set and line counts match #3800. Close #4609 in favour of this one, or tell me to take a different route and I will. ### Screenshots Not a UI change. ### Downstream repositories Same walk as #3800: `packages/extra/monitoring` gains values fields, its reference page on the website regenerates from `README.md` on the next stable tag, and the Terraform provider does not model the monitoring service. No package is added or renamed, and no CRD, tooling or node contract is touched. - [x] No downstream repository is affected by this change - [ ] [cozystack/website](https://github.com/cozystack/website) - follow-up: - [ ] [cozystack/terraform-provider-cozystack](https://github.com/cozystack/terraform-provider-cozystack) - follow-up: - [ ] [cozystack/ansible-cozystack](https://github.com/cozystack/ansible-cozystack) - follow-up: - [ ] [cozystack/ccp](https://github.com/cozystack/ccp) - follow-up: - [ ] [cozystack/talm](https://github.com/cozystack/talm) - follow-up: - [ ] [cozystack/cozyhr](https://github.com/cozystack/cozyhr) - follow-up: - [ ] [cozystack/cozy-proxy](https://github.com/cozystack/cozy-proxy) - follow-up: - [ ] [cozystack/cozystack-telemetry-server](https://github.com/cozystack/cozystack-telemetry-server) - follow-up: - [ ] [cozystack/external-apps-example](https://github.com/cozystack/external-apps-example) - follow-up: - [ ] [cozystack/examples](https://github.com/cozystack/examples) - follow-up: - [ ] [cozystack/community](https://github.com/cozystack/community) - follow-up: ### Release note ```release-note feat(monitoring): add optional email alerting through alerta.alerts.email, with configurable severity and alert-name selection and an SMTP password read from the fixed Secret alertmanager-email-password ``` |
||
|
myasnikovdaniil
|
b50fdf532c |
[Backport release-1.6] fix(dashboard, foundationdb): show the connection ConfigMap to tenants (#4684)
## What this PR does Backport of #4612 to `release-1.6`, together with its follow-up #4789. All three commits are cherry-picked. Two of them needed their `ApplicationDetailPage.test.tsx` cases added by hand, because on this branch that file has none of the virtual machine tab tests they sit next to on main. FoundationDB keeps its connection string in a ConfigMap that tenants may read, and the console had no view for ConfigMaps. The application page gets a ConfigMaps tab for the ConfigMaps named in the application's resource map, with a copy button for each value. Each read uses an exact-name field selector, so no general ConfigMap access is needed. The FoundationDB chart now renders its resource map with monitoring disabled too, and tenant roles may read it. If the resource map stops being readable after a successful read, the tab goes away instead of keeping the old names. ### Validation - All 6 FoundationDB chart tests pass, and so do all 338 console tests in 52 files and the TypeScript check. - Tests cover finding the ConfigMaps through the resource map, reading only the named ones in the active namespace, copying a value, a failed copy, a denied read, malformed resource maps, and a resource map that answers 403 or 404 after a successful read. The four tests for the last case fail without the #4789 commit. ### Screenshots The tab is the same as in #4612, which has a screenshot of it. ### Downstream repositories Walked the trigger map against the diff. It changes a FoundationDB chart template and its test, and the console, with no values, schema, CRD or `hack/` file, and the console is vendored in this repository. No companion repository needs an update. - [x] No downstream repository is affected by this change - [ ] [cozystack/website](https://github.com/cozystack/website) - follow-up: - [ ] [cozystack/terraform-provider-cozystack](https://github.com/cozystack/terraform-provider-cozystack) - follow-up: - [ ] [cozystack/ansible-cozystack](https://github.com/cozystack/ansible-cozystack) - follow-up: - [ ] [cozystack/ccp](https://github.com/cozystack/ccp) - follow-up: - [ ] [cozystack/talm](https://github.com/cozystack/talm) - follow-up: - [ ] [cozystack/cozyhr](https://github.com/cozystack/cozyhr) - follow-up: - [ ] [cozystack/cozy-proxy](https://github.com/cozystack/cozy-proxy) - follow-up: - [ ] [cozystack/cozystack-telemetry-server](https://github.com/cozystack/cozystack-telemetry-server) - follow-up: - [ ] [cozystack/external-apps-example](https://github.com/cozystack/external-apps-example) - follow-up: - [ ] [cozystack/examples](https://github.com/cozystack/examples) - follow-up: - [ ] [cozystack/community](https://github.com/cozystack/community) - follow-up: ### Release note ```release-note fix(dashboard): backport FoundationDB connection ConfigMaps to release-1.6 ``` |
||
|
myasnikovdaniil
|
2388d09965 |
[Backport release-1.6] fix(etcd): leave compaction to etcd and pass the real quota to defrag (#4874)
## What this PR does
backport of #4873 to `release-1.6`. the commit is cherry-picked
unchanged from
|
||
|
myasnikovdaniil
|
fdaa9e1572 |
[Backport release-1.6] fix(mongodb): set the s3 bucket and prefix on the bootstrap restore (#4780)
## What this PR does
backport of #4779 to `release-1.6`. the template change is cherry-picked
unchanged from
|
||
|
myasnikovdaniil
|
48bcb33ca5 |
[Backport release-1.6] fix(linstor): use severity warning in piraeus-datastore alerts (#4740)
## What this PR does Backport of the LINSTOR severity fix and its alert-rule guard from #3799 to `release-1.6`, together with the guard's follow-up #4812. Seven piraeus-datastore rules use `warn`, which the default Alerta alarm model does not accept, and they now use `warning`. Alert names, expressions and thresholds stay unchanged. Cherry-picked `3ade16a380c9d03b83ff28ea02af3b800fdd1b0f` and `bd2cc0a749531433a237a9c8a6e21a6f21dee200` with their authors and cherry-pick references. The KEDA severity commit from the same main PR is left out because the KEDA rule it fixes does not exist on release-1.6. The follow-up from #4812 is cherry-picked too. It makes the guard catch a quoted kind or a kind followed by a comment, and fail on a rule group it cannot see into once template actions are stripped. ### Validation - All nine checks in `hack/alert-severity-contract.bats` pass with `hack/cozytest.sh` on this branch. The wider discovery finds the same 39 rule files as before and no rule group comes out empty. - Against `release-1.6` at `da98ddc08` without the fix, the same contract fails on exactly the seven `warn` rules corrected here. - Delivery through Alertmanager and Alerta was not exercised. ### Screenshots Not a UI change. ### Downstream repositories The file-level trigger map was checked against both changed files: a rule file under `packages/system/piraeus-operator/alerts/` and a new test under `hack/`. No existing tool, make target, API schema, package, output resource or documented workflow is renamed or changed. No companion repository update is required. - [x] No downstream repository is affected by this change - [ ] [cozystack/website](https://github.com/cozystack/website) - follow-up: - [ ] [cozystack/terraform-provider-cozystack](https://github.com/cozystack/terraform-provider-cozystack) - follow-up: - [ ] [cozystack/ansible-cozystack](https://github.com/cozystack/ansible-cozystack) - follow-up: - [ ] [cozystack/ccp](https://github.com/cozystack/ccp) - follow-up: - [ ] [cozystack/talm](https://github.com/cozystack/talm) - follow-up: - [ ] [cozystack/cozyhr](https://github.com/cozystack/cozyhr) - follow-up: - [ ] [cozystack/cozy-proxy](https://github.com/cozystack/cozy-proxy) - follow-up: - [ ] [cozystack/cozystack-telemetry-server](https://github.com/cozystack/cozystack-telemetry-server) - follow-up: - [ ] [cozystack/external-apps-example](https://github.com/cozystack/external-apps-example) - follow-up: - [ ] [cozystack/examples](https://github.com/cozystack/examples) - follow-up: - [ ] [cozystack/community](https://github.com/cozystack/community) - follow-up: ### Release note ```release-note fix(linstor): backport accepted warning severity for seven piraeus-datastore alerts to release-1.6, with a regression guard for first-party alert rules ``` |
||
|
myasnikovdaniil
|
629dcc455d |
[Backport release-1.6] fix(platform): keep the legacy etcd-operator stopped after etcd adoption (#4739)
## What this PR does Backport of #4738 to `release-1.6`, cherry-picked without changes from `6248d458ad57c5991700dc26c5abc1340b1a05f4`. Migration 50 scaled the legacy etcd-operator back to 1 after adopting the legacy etcd clusters. Until a tenant's etcd HelmRelease reconciled the new chart, Flux re-created the legacy EtcdCluster from the old one, and the running legacy operator re-created the legacy StatefulSet and took the legacy `etcd-headless` Service away from the adopted EtcdMembers. The garbage collector deleted the Service when the new chart pruned that EtcdCluster, and the adopted members' `etcd-<i>.etcd-headless` names stopped resolving. This hit every tenant etcd on a cluster upgraded from 1.4.3 to 1.6.4, and upgrades from 1.4 and 1.5 to 1.6 go through this branch. The operator now stays at 0 after a successful adoption until the etcd-operator HelmRelease replaces it, and a failed adoption still restores it through the EXIT trap. The full timeline from the audit log and the repair for already upgraded clusters are in #4738. ### Validation - The commit applies cleanly to `release-1.6` at `da98ddc08`. - `hack/cozytest.sh hack/migration-50-etcd-adopt.bats` passes all 29 tests on this branch. The new test fails against the release-1.6 script with `FAIL: the legacy operator was scaled back up after a successful adoption`. ### Screenshots Not a UI change. ### Downstream repositories Same diff as #4738, where the trigger map was walked file by file. No entry matches. - [x] No downstream repository is affected by this change - [ ] [cozystack/website](https://github.com/cozystack/website) - follow-up: - [ ] [cozystack/terraform-provider-cozystack](https://github.com/cozystack/terraform-provider-cozystack) - follow-up: - [ ] [cozystack/ansible-cozystack](https://github.com/cozystack/ansible-cozystack) - follow-up: - [ ] [cozystack/ccp](https://github.com/cozystack/ccp) - follow-up: - [ ] [cozystack/talm](https://github.com/cozystack/talm) - follow-up: - [ ] [cozystack/cozyhr](https://github.com/cozystack/cozyhr) - follow-up: - [ ] [cozystack/cozy-proxy](https://github.com/cozystack/cozy-proxy) - follow-up: - [ ] [cozystack/cozystack-telemetry-server](https://github.com/cozystack/cozystack-telemetry-server) - follow-up: - [ ] [cozystack/external-apps-example](https://github.com/cozystack/external-apps-example) - follow-up: - [ ] [cozystack/examples](https://github.com/cozystack/examples) - follow-up: - [ ] [cozystack/community](https://github.com/cozystack/community) - follow-up: ### Release note ```release-note fix(platform): backport to 1.6 the fix that keeps the legacy etcd-operator stopped after migration 50 adopts the legacy etcd clusters, so the adopted members keep their etcd-headless DNS names through the upgrade. ``` |
||
|
myasnikovdaniil
|
17f3386453 |
[Backport release-1.6] fix(postgres): cap the default shared_buffers at a quarter of the memory limit (#4725)
## What this PR does Backport of #4724 to `release-1.6`, including the memory-request cap required by CloudNativePG when memory is overcommitted. The chart renders no `shared_buffers`, and CloudNativePG 1.28.2, the operator version on this branch, does not set one either, so PostgreSQL starts with its built-in 128MB. That is the whole memory limit on `t1.nano` and half of it on `t1.micro`, the chart's default preset, and a dump, index scans over a large table or a replica catching up after a failover can fill the pool and get the instance OOMKilled. Below a 512Mi memory limit the chart defaults `shared_buffers` to a quarter of the limit with a 16MB floor, capped at the rendered memory request rounded down to whole MiB. From 512Mi up nothing is rendered and those clusters are unchanged. An explicit `shared_buffers` in `postgresql.parameters` still wins. On upgrade every cluster below 512Mi that does not set `shared_buffers` gets the new value. With the CloudNativePG defaults the chart keeps, `unsupervised` and `restart`, the operator restarts the replicas first and then the primary in place, so writes pause for one PostgreSQL restart, and a single-instance cluster is unavailable for that time. ### Validation - The commit applies cleanly to `release-1.6` at `da98ddc08`. - `helm unittest` passes all 50 tests in 7 suites on this branch. The added cases cover memory overcommit, fractional MiB requests, a request below the 16MB floor, explicit values and the unchanged 512Mi threshold. Four cases fail against the previous PR template. - `helm template` of the chart on this branch renders `t1.small` exactly as before, and the default preset differs only by `shared_buffers: "64MB"`. - `make generate` with cozyvalues-gen v1.6.0, the version this branch's CI pins, leaves the generated files unchanged. ### Screenshots Not a UI change. ### Downstream repositories Same diff as #4724, where the trigger map was walked file by file. No entry matches. - [x] No downstream repository is affected by this change - [ ] [cozystack/website](https://github.com/cozystack/website) - follow-up: - [ ] [cozystack/terraform-provider-cozystack](https://github.com/cozystack/terraform-provider-cozystack) - follow-up: - [ ] [cozystack/ansible-cozystack](https://github.com/cozystack/ansible-cozystack) - follow-up: - [ ] [cozystack/ccp](https://github.com/cozystack/ccp) - follow-up: - [ ] [cozystack/talm](https://github.com/cozystack/talm) - follow-up: - [ ] [cozystack/cozyhr](https://github.com/cozystack/cozyhr) - follow-up: - [ ] [cozystack/cozy-proxy](https://github.com/cozystack/cozy-proxy) - follow-up: - [ ] [cozystack/cozystack-telemetry-server](https://github.com/cozystack/cozystack-telemetry-server) - follow-up: - [ ] [cozystack/external-apps-example](https://github.com/cozystack/external-apps-example) - follow-up: - [ ] [cozystack/examples](https://github.com/cozystack/examples) - follow-up: - [ ] [cozystack/community](https://github.com/cozystack/community) - follow-up: ### Release note ```release-note fix(postgres): backport the small-preset shared_buffers default to 1.6. Without an explicit shared_buffers and below a 512Mi memory limit, PostgreSQL now gets a quarter of the limit with a 16MB floor, capped at the memory request, instead of its built-in 128MB, so a full buffer pool no longer takes the whole limit on t1.nano or half of it on t1.micro. Affected clusters restart their instances once on upgrade, the primary last. ``` |
||
|
myasnikovdaniil
|
29642c105b |
[Backport release-1.6] fix(nats): enable JetStream for the generated account (#4677)
## What this PR does Backport of #4675 to `release-1.6`, cherry-picked without changes from `15b7092f3ada7c26fbaa7c67be26e59ced73992f`. #4675 is merged in main now. With `users` configured and `jetstream.enabled: true`, the application chart enables JetStream on the server but generates account `A` without it. Authentication and ordinary NATS messaging work, while `$JS.API.INFO` returns error 10039, "JetStream not enabled for account". The generated account now gets `jetstream: true` when persistent messaging is enabled and the account does not set JetStream itself. Tenant-supplied limits, explicit disablement, other accounts and the existing generated-user merge are kept. nats-server matches config keys case-insensitively and walks the account map in no fixed order, so a `JetStream` key in any casing counts as set. Otherwise the account would carry both keys and the server would apply either one, changing from restart to restart. Existing instances with `users` pick this up on upgrade. The rendered NATS config changes, so the StatefulSet rolls its pods once, and account `A` gets JetStream without account limits unless `config.merge.accounts.A.jetstream` sets them. ### Validation - The commit applies cleanly to `release-1.6` at `da98ddc08`. - `helm unittest` passes all 65 application-chart tests on this branch. - The run on NATS Server 2.11.10 is described in #4675. ### Screenshots Not a UI change. ### Downstream repositories The diff changes an application template and chart tests only. Public values, schemas, output resource names and tooling contracts are unchanged. The website NATS documentation contains no account-level workaround to remove. No downstream trigger applies. - [x] No downstream repository is affected by this change - [ ] [cozystack/website](https://github.com/cozystack/website) - follow-up: - [ ] [cozystack/terraform-provider-cozystack](https://github.com/cozystack/terraform-provider-cozystack) - follow-up: - [ ] [cozystack/ansible-cozystack](https://github.com/cozystack/ansible-cozystack) - follow-up: - [ ] [cozystack/ccp](https://github.com/cozystack/ccp) - follow-up: - [ ] [cozystack/talm](https://github.com/cozystack/talm) - follow-up: - [ ] [cozystack/cozyhr](https://github.com/cozystack/cozyhr) - follow-up: - [ ] [cozystack/cozy-proxy](https://github.com/cozystack/cozy-proxy) - follow-up: - [ ] [cozystack/cozystack-telemetry-server](https://github.com/cozystack/cozystack-telemetry-server) - follow-up: - [ ] [cozystack/external-apps-example](https://github.com/cozystack/external-apps-example) - follow-up: - [ ] [cozystack/examples](https://github.com/cozystack/examples) - follow-up: - [ ] [cozystack/community](https://github.com/cozystack/community) - follow-up: ### Release note ```release-note fix(nats): enable JetStream on the account generated for users when jetstream.enabled is true, keeping any explicit account-level JetStream setting. Instances with users roll their NATS pods once on upgrade. ``` |
||
|
myasnikovdaniil
|
f50f4a85e5 |
[Backport release-1.6] fix(api): let the garbage collector finalize Applications (#4683)
## What this PR does Backport of #4610 to `release-1.6`. `Update` on this branch has no `applyLiveMetadata`, so the finalizer merge and the copy of the deletion metadata are done inline, in `Update` and in its conflict retry. The tests are the same as on main. An Application and its HelmRelease share one UID, so the garbage collector keeps one graph node for both and may finalize it through the Application endpoint. The API never returned finalizers on an Application, so when the collector dropped `foregroundDeletion` or `orphan` through it, the HelmRelease kept `foregroundDeletion` after Helm had uninstalled the release and the deletion never completed. The Application now carries the two garbage collection finalizers, and an update that adds or removes one of them applies the same change to the HelmRelease. Controller finalizers such as `finalizers.fluxcd.io` stay owned by the live object. ### Validation - `go test ./pkg/registry/apps/application/...` passes on this branch. - Making the finalizer merge return the live list turns four tests red, the conflict-retry test among them. - No API types change, so code generation is not affected. ### Screenshots Not a UI change. ### Downstream repositories Walked the trigger map against the diff. It changes the Application REST handler and its test, with no chart, values, schema, CRD or `hack/` file, so no companion repository needs an update. - [x] No downstream repository is affected by this change - [ ] [cozystack/website](https://github.com/cozystack/website) - follow-up: - [ ] [cozystack/terraform-provider-cozystack](https://github.com/cozystack/terraform-provider-cozystack) - follow-up: - [ ] [cozystack/ansible-cozystack](https://github.com/cozystack/ansible-cozystack) - follow-up: - [ ] [cozystack/ccp](https://github.com/cozystack/ccp) - follow-up: - [ ] [cozystack/talm](https://github.com/cozystack/talm) - follow-up: - [ ] [cozystack/cozyhr](https://github.com/cozystack/cozyhr) - follow-up: - [ ] [cozystack/cozy-proxy](https://github.com/cozystack/cozy-proxy) - follow-up: - [ ] [cozystack/cozystack-telemetry-server](https://github.com/cozystack/cozystack-telemetry-server) - follow-up: - [ ] [cozystack/external-apps-example](https://github.com/cozystack/external-apps-example) - follow-up: - [ ] [cozystack/examples](https://github.com/cozystack/examples) - follow-up: - [ ] [cozystack/community](https://github.com/cozystack/community) - follow-up: ### Release note ```release-note fix(api): an application deleted with foreground or orphan propagation no longer leaves its HelmRelease stuck with the foregroundDeletion or orphan finalizer ``` |
||
|
myasnikovdaniil
|
6086bd1b46 |
[Backport release-1.6] feat(keycloak): expose zone placement for Keycloak and the database proxy (#4856)
# Description Backport of #4606 to `release-1.6`. |
||
|
myasnikovdaniil
|
f95ba62000 |
[Backport release-1.6] fix(cert-manager): enable the Gateway API solver in the host cert-manager (#4808)
# Description Backport of #4039 to `release-1.6`. |
||
|
myasnikovdaniil
|
008c0256b4 |
[Backport release-1.6] fix(cozy-lib): round the sanitized CPU request up to a whole milli-CPU (#4590)
# Description Backport of #3522 to `release-1.6`. |
||
|
myasnikovdaniil
|
e23815ba00 |
[Backport release-1.6] fix(kubernetes): apply worker TalosConfigTemplate server-side (#4575)
# Description Backport of #4163 to `release-1.6`. |
||
|
myasnikovdaniil
|
0c5564aae4 |
[Backport release-1.6] fix(kubernetes): probe Keycloak CRDs by output in oidc-bootstrap cleanup (#4571)
# Description Backport of #3520 to `release-1.6`. |
||
|
myasnikovdaniil
|
6fea44c4a5 |
[Backport release-1.6] chore(hetzner-robotlb): update robotlb to 0.1.0 (#4560)
# Description Backport of #4557 to `release-1.6`. |
||
|
Aleksei Sviridkin
|
f3223c33d3 |
ci(e2e): run nightly and release-tag e2e on the container lane
Nightly and the rc gate still booted the management nodes as QEMU
guests, the substrate the merge-gating lanes left behind. On it the
tenant Kubernetes suites have missed their node-join deadline on most
nights since 2026-10-02, each failure spends the whole deadline, and
the job reaches its timeout before the alphabetically later suites
run. Over the same days those suites passed on every PR run that
selected them, where the nodes are Talos containers and a tenant
worker sits one virtualization level shallower.
Both lanes now use the PR lanes' container substrate. Nightly's e2e no
longer waits for the nocloud disk, which it does not boot; the disk is
still built and published. A manual e2e-tag dispatch against a tag
that predates the container lane fails early and names the ref to
dispatch from instead.
DRBD, the replicated StorageClass and the Cozystack Talos node image
lose their last e2e coverage with this. The docs and comments that
pointed at nightly and the rc gate as that coverage now say so.
Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@lex.la>
(cherry picked from commit
|
||
|
Myasnikov Daniil
|
f3104a9067 |
ci(e2e): give the nightly e2e runner headroom over its nodes
The nightly e2e job runs on a 24-vCPU runner while its three
management nodes take 8 vCPU each. On QEMU that is a 1:1 commit with
nothing left for the host. On the container lane the job would not
start at all: hack/e2e-container-up.sh refuses a host that does not
have strictly more CPUs than the nodes take, and nightly checks out
main's tree, which carries the same check.
The next commit moves nightly onto the container lane, so move the job
first to the 32-vCPU class the pull request and tag lanes on this
branch already use. main made the same move in
|
||
|
Yan Bondarenko
|
6af3583dd8 |
docs(openbao): document the static seal trade-off and the Shamir migration
With the static seal the key sits in a Secret in the same cluster as the
data it unwraps, so the barrier is only as strong as access to Secrets
in that namespace, to etcd and to backups. The README now says so before
the reader picks a seal, and it says what the key identifier is for,
since OpenBAO picks the key for stored data by it.
Tenant roles grant nothing on Secrets and no pods/log, so a cluster
administrator creates the key Secret and reads the log line that
confirms a re-wrap.
The StatefulSet uses the OnDelete strategy, so neither a seal migration
nor the apiserver egress label reaches a running pod until it is
replaced. The README describes the migration from Shamir step by step,
following the OpenBAO seal migration guide, and says that pods created
before the label have to be replaced once.
The migration starts with a backup. The standalone file backend is not
transactional, so its volume is copied with the server stopped or
snapshotted atomically. The upgrade that sets allowMigration is the
point of no return for the chart, and the README says how a cluster
administrator backs out of it before any pod is replaced.
Assisted-by: LLM
Signed-off-by: Yan Bondarenko <202671653+yankawai@users.noreply.github.com>
(cherry picked from commit
|
||
|
Yan Bondarenko
|
80c64869e9 |
fix(openbao): constrain the seal values that reach the server config
The upstream chart passes the server config through tpl, and its start
script replaces upper case placeholders such as HOSTNAME anywhere in the
copied file. A key identifier with template delimiters would run as a
template inside helm-controller, which runs as cluster-admin, and an
upper case one could come out different on every pod. Both key
identifiers now take lowercase alphanumerics, hyphens, dots and
underscores.
The Secret names become pod volume names of the form userconfig-<name>,
which Kubernetes validates as DNS labels. Both name fields now take a
DNS label of at most 52 characters, and the volume entries are quoted.
The apps API only defaults against the generated schema, so Helm
enforces these patterns when it installs or upgrades the release.
A previous Secret equal to the current one mounts the same volume twice,
which the API server rejects for the StatefulSet, and OpenBAO refuses to
start when equal key identifiers name different key material. Both
cases now fail at render. The deepcopy functions for the Seal type are
regenerated as well.
Assisted-by: LLM
Signed-off-by: Yan Bondarenko <202671653+yankawai@users.noreply.github.com>
(cherry picked from commit
|
||
|
txmazing
|
cf4b65ada3 |
feat(openbao): optional static-key auto-unseal and apiserver egress label
The OpenBAO app has no auto-unseal (#2787). Every restart of a server,
after a node drain, an image bump or an OOM kill, leaves it sealed until
an operator enters the Shamir key shares into each replica. In HA mode
the pods also hang at start (#2793). Cozystack's allow-to-apiserver
policy only admits egress from pods labelled
policy.cozystack.io/allow-to-apiserver, the app never set that label,
and service_registration "kubernetes" cannot reach the API server
without it.
A new seal value selects shamir, which stays the default, or OpenBAO's
seal "static". With static the chart renders the static seal stanza into
the standalone and the Raft config and mounts the key Secret named in
seal.secretName through the upstream chart's server.extraVolumes. The
chart never generates, stores or rotates the key, because a missed
lookup would replace it and leave the data unreadable.
seal.previousSecretName and seal.previousKeyId carry the n-1 key that
the static seal accepts during a rotation. The server pods always carry
the apiserver egress label.
Changing the seal of an initialized instance is a seal migration that
OpenBAO performs under bao operator unseal -migrate. The chart reads the
seal in use from the config ConfigMap the previous release rendered and
refuses a different seal.type unless seal.allowMigration acknowledges
the migration. Moving away from static needs the old stanza kept with
disabled = "true", which the chart does not render, so that direction is
refused regardless. The README documents the key Secret, the rotation
with the pod replacement that the OnDelete update strategy requires, and
the log line that confirms the re-wrap.
Signed-off-by: txmazing <txmazing@gmail.com>
Assisted-by: LLM
Signed-off-by: Yan Bondarenko <202671653+yankawai@users.noreply.github.com>
(cherry picked from commit
|
||
|
Yan Bondarenko
|
4ee828e421 |
fix(dashboard): mark a free-form field invalid when the schema rejects it
A JSON object that parses but fails the schema, for example on
minProperties, left the textarea with aria-invalid false, and nothing
linked it to the error list RJSF renders under the field, so assistive
technology announced the field as valid. The field now reports the
schema errors RJSF passes in and points aria-describedby at their list,
unless hideError keeps that list from rendering. The red help text
stays tied to input that is not a JSON object.
Assisted-by: LLM
Signed-off-by: Yan Bondarenko <202671653+yankawai@users.noreply.github.com>
(cherry picked from commit
|
||
|
Yan Bondarenko
|
62e1811219 |
fix(dashboard): allow editing free-form objects in application forms
Signed-off-by: Yan Bondarenko <202671653+yankawai@users.noreply.github.com>
Assisted-by: LLM
(cherry picked from commit
|
||
|
Yan Bondarenko
|
38bd21f3a8 |
fix(monitoring): send alerts to every Alertmanager replica
vmalert had a single notifier, the headless vmalertmanager-alertmanager
Service. It resolves to all three pods, but each alert reached one replica
at a time and moved to another when vmalert reconnected. On clusters running
1.6.4 all active alerts sat on one replica while the other two had none, and
on one of them the alert count of each replica changed about 170 times a
day. The Alertmanager cluster deduplicates notifications only when every
replica receives every alert. The replica an alert left let it expire and
sent a resolved notification, and the replica it reached sent a new firing
one.
vmalert now lists each Alertmanager pod as its own notifier, using the
<name>-<i>.<service>.<namespace>.svc address the operator itself gives
StatefulSet pods. The replica count comes from one helper that also sets
spec.replicaCount of the VMAlertmanager, so the two cannot drift.
Assisted-by: LLM
Signed-off-by: Yan Bondarenko <202671653+yankawai@users.noreply.github.com>
(cherry picked from commit
|