Repository navigation
docs: add v1.6 to v1.7 upgrade notes and bring Gateway API, Backup Classes and Platform Package up to 1.7 - #757
Conversation
The page still described pre-1.7 behaviour as fact. TLS-passthrough hostnames are now reserved by the TenantGateway spec alone (cozystack/cozystack#3342, #4638): under HTTP-01 such a name gets no HTTPS listener and no certificate, route or no route, and a hostname only a TLSRoute claims earns neither. The three platform passthrough listeners render only on the publishing tenant, while gateway.enabled is on, for the names publishing.exposedServices lists, so a removed service loses its listener as well. The listener budget, the HTTP-01 listener layout and the rate-limit note are corrected to match. The route hostname policy now requires a non-empty spec.hostnames (cozystack/cozystack#3475) and has a third policy for GRPCRoute (cozystack/cozystack#3872). The Layer 5 text, the diagram label and the troubleshooting entry, whose quoted message changed, follow. Adds a section for TenantGateway tlsPassthroughListeners, the native-port passthrough form from #3342. Assisted-By: LLM Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Four platform values that 1.7 adds had no row on the Platform Package reference: - authentication.oidc.realmName (cozystack/cozystack#4237), with the character rule, the refusal of `master` and what a rename on a live cluster does. The keycloakInternalUrl row is corrected next to it: its default is now unset and derived from the realm name. - networking.encryption.enabled (cozystack/cozystack#2984), with the variants that apply, refuse or ignore it. - backupStrategyController, the pass-through that sizes the Redis backup strategy Pod. - kubernetesWorkerImage (cozystack/cozystack#4171), the values of the opt-in golden worker image catalog. cozystackOperator.systemNamespaceMemoryLimit is an installer value, not a platform one, so it is not part of this page. Assisted-By: LLM Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
The website copy of the Backup Classes page had drifted from docs/operations/backup-classes.md in cozystack/cozystack. It listed seven applications and none of the drivers 1.7 adds. The body now follows the product page at v1.7.0-rc.1: - MongoDB (cozystack/cozystack#3562, #3967), Kafka topic metadata (#4000), RabbitMQ definitions (#3990) and Redis (#3992) bound by cozy-default, with their endpoint forms, credentials keys, storage flows and restore semantics. - The corrected PostgreSQL point-in-time recovery text from cozystack/cozystack#4443: base-backup selection, the recoverable window bounded by the last archived transaction, the one-second margin after stoppedAt, and archives with several timelines. This covers the corrections listed in #716. - Password handling after a restore, the default-objects gate and its metrics, the backupStrategyController override, concurrent restores and the Barman Cloud plugin upgrade notes. Adapted to the site: front matter and See also kept, relative links to the monorepo turned into GitHub links, `users[].password` written as the map path `users.<name>.password` the charts use, a test-run remark and the stale CloudNativePG version in the plugin note dropped. Assisted-By: LLM Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
The docs had no page for moving between v1.x releases; the actions a v1.7 upgrade needs lived only in the release notes. Adds "Upgrading from v1.6 to v1.7" next to the generic upgrade procedure, which now points to it. The page names 1.7 in its title and path, so it stays correct once the trunk is promoted to v1.7 and copied again later. It covers the platform migrations 54 to 59 and the default variant, which runs none of them; the drbd_transport_tcp module Talos v1.14 needs before a node is upgraded, and the etcd metrics port; worker pools as KubernetesNodes resources, the FluxCD addon removal and the Kamaji update with its extraArgs refusals; the Cilium address block, Multus CNI plugin staging and the Gateway API route and passthrough changes; KubeVirt eviction and declarative hotplug; Redis, PostgreSQL and OpenSearch exposure rules, generated database passwords, FoundationDB 7.1, the Kafka KRaft migration and the SeaweedFS volume size limit; and the smaller breaking changes. Every statement was checked against cozystack/cozystack at v1.7.0-rc.1. The listing commands were run against local fixtures. Assisted-By: LLM Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
✅ Deploy Preview for cozystack ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configuration
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The upgrade notes said the pool adoption changes the bootstrap template of each MachineDeployment, without saying why or that this is intended. v1.7 names each pool's TalosConfigTemplate after a hash of its content (cozystack/cozystack#3523), so every pool's MachineDeployment refers to a new template and Cluster API rolls the Talos workers once. The page now states the roll as expected, one-time behaviour with that cause and the rollout strategy, asks to plan the window for it, and notes that the same roll brings stale machine configuration up to date and gives GPU pools their NVIDIA kernel modules. The pre-upgrade checklist gains an entry for it. Assisted-By: LLM Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Instances with a memory limit below 512Mi and no explicit shared_buffers get a new default that needs a PostgreSQL restart, unless the cluster already runs v1.6.5. Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com> Assisted-by: LLM
IvanHunters
left a comment
IvanHunters
left a comment
There was a problem hiding this comment.
LGTM, with two optional notes.
This is a big, careful docs update, and the parts an operator actually acts on hold up against the v1.7.0-rc.1 tree (38d6ac7) rather than on trust. I checked the migration table (54 through 59, target version 60), the Kamaji owned-flags jq list (byte-identical to $kamajiManagedArgs in packages/apps/kubernetes/templates/cluster.yaml, 23 of 23), drbd_transport_tcp, the Talos v1.14.2 / DRBD 9.3.4 / ZFS 2.4.4 pins, realmName defaulting to cozy with master refused, the Redis external-TLS policy, the VM resources validation, and the default-variant SeaweedFS pin script, which is a verbatim copy of migration 57. The keycloakInternalUrl default moving from the v1.6 literal URL to null derives back to the same URL when realmName is cozy, so the row change is a doc fix with no upgrade impact. Netlify preview builds and i18n-lint is green, so refs and anchors resolve.
Two notes inline, both non-blocking.
| - Gateway API: check the certificate served on `api.<apex>` and the hostnames of routes in tenant namespaces. See [Gateway API](#gateway-api). | ||
| - VM instances: fix `resources` values that cannot size a VM. See [Smaller changes](#smaller-changes). | ||
| - Kafka: plan a maintenance window for every instance. See [Kafka moves to KRaft](#kafka-moves-to-kraft). | ||
| - `default` variant only: pin the SeaweedFS volume size limit and look for volumes hotplugged on a VM instance only. See [SeaweedFS volume size limit](#seaweedfs-volume-size-limit) and [Declarative volume hotplug](#declarative-volume-hotplug). |
There was a problem hiding this comment.
[MINOR] Before-you-upgrade checklist omits the default-variant HTTPCache step
The warning box at the top of the page names SeaweedFS, VM volume hotplug and HTTPCache as the three things a default-variant operator has to handle by hand, and the HTTPCache note at line 305 repeats that a default cluster should check for instances. This checklist covers only SeaweedFS and declarative hotplug; HTTPCache is missing. An operator working from the checklist alone will not know to check.
Unlike the SeaweedFS and hotplug entries, the HTTPCache note also stops at "check for instances" and gives no action. On other variants migration 58 freezes a live instance so it keeps serving after the chart leaves the tree; on default nothing does, and per the migration's own rationale an unfrozen instance goes Ready=False once cozystack-packages is re-pointed. Worth adding an HTTPCache bullet here, and saying what a default operator should do with a live instance (freeze it the way migration 58 does, or migrate off it before upgrading).
|
|
||
| ### FoundationDB 7.1 | ||
|
|
||
| The FoundationDB operator no longer ships the 7.1 client, so it cannot manage or upgrade a cluster that runs FoundationDB 7.1.x. Before upgrading the platform, move every such cluster to 7.3 through its `cluster.version` value. |
There was a problem hiding this comment.
[NIT] FoundationDB target is 7.3 or 7.4, not only 7.3
The v1.7 FoundationDB operator ships both the 7.3 and 7.4 clients (only 7.1 was dropped; charts/fdb-operator/values.yaml carries 7.3 and 7.4), so a 7.1.x cluster can move to either. "to 7.3" reads as if 7.4 were not supported yet; "to 7.3 or later" would be accurate. Same wording in the checklist entry at line 23.
2 participants
This prepares
next/for the 1.7 promotion, which copies the trunk intov1.7/as is.Gateway API page described pre-1.7 behaviour. TLS-passthrough hostnames are now reserved by the TenantGateway spec alone (cozystack/cozystack#3342, #4638): under HTTP-01 such a name gets no HTTPS listener and no certificate, and the three platform passthrough listeners render only on the publishing tenant. Tenant routes must declare
spec.hostnames(#3475), and GRPCRoute is covered by its own policy (#3872). The page says so now and documentstlsPassthroughListeners. I also removed one sentence about the Cloudflare Tunnel package from it, the package doesn't ship in 1.7.There was no page for upgrading between v1.x releases. "Upgrading from v1.6 to v1.7" sits next to the generic upgrade procedure. It lists pre-upgrade checks, platform migrations 54 to 59 (the
defaultvariant runs none of them) and every breaking change with the action it needs:drbd_transport_tcpfor Talos v1.14, worker pools asKubernetesNodes, FluxCD addon removal, Kamaji andextraArgs, Cilium address block, Multus CNI staging, KubeVirt eviction and declarative hotplug, Redis, PostgreSQL and OpenSearch exposure, generated database passwords, FoundationDB 7.1, Kafka KRaft migration and SeaweedFS volume size limit. I checked each statement against v1.7.0-rc.1 code, and where the draft release notes and the code disagree the page follows the code.The page tells operators to plan for a one-time roll of Talos workers in every existing tenant cluster.
TalosConfigTemplateis now named by a content hash (cozystack/cozystack#3523), so each pool gets a new template and Cluster API replaces its workers. No action is needed on the pools, but data on a worker's own system disk (local-path volumes, for example) doesn't survive the replacement.Backup Classes is re-synced with the product doc: MongoDB, Kafka, RabbitMQ and Redis drivers and the corrected PostgreSQL point-in-time recovery text (covers #716 for
next/).Platform Package reference gets
authentication.oidc.realmName,networking.encryption.enabled,backupStrategyControllerandkubernetesWorkerImage. I also fixed thekeycloakInternalUrlrow, it contradicted the newrealmNamerow.Checked locally: Hugo 0.164.0 preview build, refs and in-page anchors, i18n checks.