Repository navigation
docs(v1.7): carry the pending docs PRs into the released v1.7 docs - #782
Conversation
✅ 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.
|
IvanHunters
left a comment
There was a problem hiding this comment.
LGTM on the content, with a draft caveat and a couple of non-blocking notes.
This carries the pending v1.7 docs that were cut from next/ in #780, so I checked each page against its source.
Faithful carries: the five moved guides (gateway-classes, system-memory-limits, distributed-tracing, capacity-for-backups, storage-class-immutability) are byte-for-byte copies of their docs/ sources on cozystack main, apart from the dropped H1 and the one gateway-classes link rewritten to an absolute URL. backup-classes and resource-management carry the same edits as #763, and the "which this PR removes" phrasing is correctly reworded to "that pin has since been removed" for the site. The next/ and v1.7/ copies of upgrade-to-v1.7 are identical except for the {{% ref %}} paths, rewritten from /docs/next to /docs/v1.7 as expected.
HTTPCache section: the freeze commands match migrations/58 on cozystack main, including the pinned cozystack-packages-http-cache source, the PackageSource and Package patches, the cozy:tenant:admin:http-cache-frozen ClusterRole, the digest read, and the removal path.
Proxmox page: I checked the corrections against the v1.7.0 tag. KubernetesNodes uses minReplicas/maxReplicas with no replicas field (kubernetes-nodes/values.yaml), and the controllers render as -pccm and -pcsi-controller (kubernetes/templates/ccm-proxmox and csi-proxmox; the chart README states the same names). substrate: proxmox is present in v1.7.0, not v1.6.
CI is green (i18n-lint, DCO, license, Netlify preview).
Notes, none blocking:
- The PR is still a draft, so this is a content approval. Mark it ready once the source-PR coordination is settled.
- resource-management drops the only pointer to docs/operations/resource-presets.md, which still exists on cozystack main. Same note I left on #763.
- The pre-pull example in upgrade.md uses FROM=v1.6.4 / TO=v1.6.5 inside the v1.7 guide. It reads as a generic illustration, but v1.7 versions would be less confusing here.
836fe98 to
a02b86d
Compare
The v1.7 docs were cut from next/ before #763 landed, so the released version and the stable /docs/ copy lack the five guides it moves onto the site, and its edits to the backup classes and resource management pages. All of it holds for v1.7.0: each new page is the copy of a file the v1.7.0 tag ships under docs/, and the values, flags, annotations, conditions and alerts the pages are built on are in the code at that tag. The Valkey binding, the Strategy CR wait for its CRD and the migration 39 dry-run note are in the tag as well. The pages are #763's next/ files with the rewrite release_next.sh applies. next/ stays with #763. Assisted-By: LLM Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
The v1.7 upgrade guide tells operators to decide whether the reference CNI plugins may be staged on every node, but the v1.7 Platform Package reference has no row for the key that decides it, nor for the multus resources override that ships in the same release. #747 adds both rows to next/ only. Both keys are in the v1.7.0 platform chart with the behaviour the rows describe: unset stages the plugins on every variant that installs multus, an unrecognised spelling or a non-map resources value fails the platform render, and the multus chart refuses to render without a memory limit and request. The rows go right after networking.kubeovn.MASTER_NODES, where #747 puts them; the networking.encryption.enabled row that main added after #747 was opened stays below them. next/ stays with #747. Assisted-By: LLM Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
v1.7.0 ships the Proxmox VE substrate for tenant Kubernetes workers and its release notes lead with it, yet the v1.7 docs have no page for it: #761 adds one to next/ only. The page is #761's with the rewrite release_next.sh applies, checked against the v1.7.0 tag. Four things did not hold there and are corrected in this copy: - KubernetesNodes has no replicas field; a pool is sized by minReplicas and maxReplicas, which the tag's own Proxmox e2e manifest sets. - The CCM and CSI controller Deployments are <release>-pccm and <release>-pcsi-controller, and a Kubernetes release is named kubernetes-<name>, so the cluster px runs kubernetes-px-pccm. The verify command and the troubleshooting row now name those. - bundles.enabledPackages is read only from the platform values on the cozystack.cozystack-platform Package; no cozystack ConfigMap feeds it. - The CSI HelmRelease depends on the tenant's Cilium release, not on the CCM, which is a plain Deployment, so the troubleshooting fix only says to wait for the CCM. next/ stays with #761. Assisted-By: LLM Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
An upgrade to or within v1.7 restarts many platform components at once, and on Talos the parallel image pulls share the EPHEMERAL volume with etcd, which can stall the leader long enough to force elections. #762 documents pulling the images one control plane node at a time first, but only in next/ and v1.6/. The step holds for v1.7.0: its images are published as ghcr.io/cozystack/cozystack/<name>:<version>@sha256:..., which the filter in the step selects, and nothing in the release overrides the kubelet image garbage collection threshold the step relies on. No page in v1.7 links to the renumbered steps. The change is #762's next/ diff with the rewrite release_next.sh applies. next/ and v1.6/ stay with #762. Assisted-By: LLM Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
On the Kube-OVN + Cilium stack Cilium runs chained in generic-veth mode, where its Layer 7 policy, toFQDNs included, is not reliable, and a CiliumNetworkPolicy the API accepts can still do nothing on the dataplane. #766 warns about it and points to a managed Kubernetes cluster with Cilium as its primary CNI, but only in next/ and v1.6/. Both hold for v1.7.0: the kubeovn variant of the cilium package still sets chainingMode: generic-veth, and a tenant Kubernetes cluster always installs Cilium as its CNI. The change is #766's next/ diff with the rewrite release_next.sh applies. next/ and v1.6/ stay with #766. Assisted-By: LLM Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
The v1.7 upgrade guide says the default variant runs no platform migration and leaves HTTPCache to the operator, but only offers a command to list instances. Upgrading such a cluster prunes the HTTPCache PackageSource and the chart sources it owns, which leaves http-cache-rd and every tenant HTTPCache release Ready=False for good while the pods keep serving. The new HTTPCache section gives those operators the steps migration 58 takes on every other variant: remove the application where no instance exists, or freeze it on the packages artifact the cluster already runs and keep the tenant admin grant that v1.7 drops from cozy:tenant:admin:base. The commands, names and selectors are those of migration 58 at the v1.7.0 tag. The checklist and the migrations table now point at the section, which replaces the HTTPCache bullet under Smaller changes. This is #764's change as merged with the corrections from #781, in next/ and, with the rewrite release_next.sh applies, in v1.7/. Assisted-By: LLM Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
a02b86d to
83ef88a
Compare
The page used the capmox token in step 1 and created it in step 2, and showed bundles.enabledPackages as a values fragment without saying how to set it. Order the steps so each uses only what exists, give the Package patch, and add the CCM Secret the example references. Link the page from the deployment guide, which had no path to it. Carry the four v1.7 corrections from cozystack#782 to next/. v1.7.0 runs proxmox-cloud-controller-manager:v0.15.0, a tag that now resolves to a build that panics at start, so the v1.7 copy gets the image override until the backport in cozystack/cozystack#5150 is released. Assisted-by: LLM Signed-off-by: Marian Koreniuk <moriarti@cp.if.ua>
The v1.7 docs were cut from
next/in #780 while several docs PRs about v1.7.0 behaviour were still open againstnext/only, so/docs/v1.7/and the stable/docs/copy miss them. This adds their content tocontent/en/docs/v1.7/, checked against the v1.7.0 tag. Every page is the source PR'snext/file with the same/docs/next/rewrite thathack/release_next.shdoes, except where noted.networking.kubeovn.MASTER_NODESbecause main got thenetworking.encryption.enabledrow after its basenext/andv1.7/on top of the fixes from docs(upgrade): correct the v1.7 upgrade guide against the upgrade test #781. I'm not carrying 764 further, this PR takes over its content.Four lines of the Proxmox page are wrong for v1.7.0 and are fixed in the v1.7 copy only.
replicas: 2in the KubernetesNodes example is nowminReplicas: 2andmaxReplicas: 2, there is noreplicasfield. The CCM and CSI controller Deployments arekubernetes-<cluster>-pccmandkubernetes-<cluster>-pcsi-controller.bundles.enabledPackagesis set on thecozystack.cozystack-platformPackage, no ConfigMap feeds it. The CSI release depends only on the tenant Cilium release, not on the CCM, so I cut that clause. Thenext/copy in 761 needs the same fixes.The
next/side of 763, 747, 761, 762 and 766 and thev1.6/side of 763, 762 and 766 stay in their own PRs, so they still merge without conflicts with this one. Nothing generated is committed, the stable/docs/copies are built fromv1.7/at build time.Hugo production and preview builds,
hack/check-i18n.shand a link and anchor check of every changed page pass locally, with the same Hugo warnings as main.