Repository navigation
docs(upgrade): give default-variant operators the HTTPCache freeze - #764
Closed
myasnikovdaniil wants to merge 1 commit into
Closed
myasnikovdaniil wants to merge 1 commit into
myasnikovdaniil wants to merge 1 commit into
Conversation
myasnikovdaniil
requested review from
Andrei Kvapil (kvaps),
Timofei Larkin (lllamnyp) and
Timur Tukaev (tym83)
as code owners
October 21, 2026 10:59
✅ Deploy Preview for cozystack ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Contributor
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars.
 |
The v1.7 upgrade page says the HTTPCache steps of migration 58 fall to the operator on the default variant, yet its pre-upgrade checklist never mentions HTTPCache and the entry offered a check with no action. Left alone, the upgrade prunes the HTTPCache PackageSource and leaves http-cache-rd and every tenant release Ready=False for good. HTTPCache now has its own section carrying the migration's steps, so a default cluster can freeze its instances, or remove the application where none exist, before it upgrades. Assisted-by: LLM Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
myasnikovdaniil
force-pushed
the
docs/upgrade-v1.7-httpcache-default
branch
from
October 29, 2026 10:37
08c4c83 to
013dda2
Compare
myasnikovdaniil
added a commit
that referenced
this pull request
Oct 29, 2026
#781) This PR corrects the v1.6 to v1.7 upgrade guide where it disagrees with what v1.7.0 does. Every change was checked against an upgrade of a test cluster from v1.6.5 to v1.7.0-rc.2, its re-run on rc.3, and the code at the rc.3 tag. What was only seen on the test cluster is written as such. Corrected: - migration 59 copies a volume hot-plugged only on the VMI into the VM spec, but on a VMInstance the same upgrade re-renders the VM from `spec.disks` and KubeVirt unplugs it, so the guide now gives the steps to take before upgrading - tenant kube-apiservers roll at least twice, and a tenant with `--enable-admission-plugins` in `extraArgs` runs without NodeRestriction until its kubernetes release upgrades - the API accepts edits of KubernetesNodes `cluster` and `storageClass`, only the dashboard refuses the second one - every PostgreSQL instance restarted once in the CloudNativePG 1.30 upgrade on a test cluster upgraded from v1.6.5 - the two Cilium agent restarts apply only when upgrading from v1.6.4 or earlier - the ApplicationDefinition prefix lives at `spec.release.prefix`, and the migrations run up to 60 with version 61 Added: migration 60 with the FoundationDB release line and its patch downgrade, image overrides of Kubernetes, KubernetesNodes and OpenSearch that are no longer read, a VM disk still importing during the upgrade, reading the migration log right after the upgrade, free disk space on the nodes, drains held by PostgreSQL primaries, leftover PostgreSQL roles being dropped, the stale OpenSearch securityconfig Job, TLSRoutes left unattached, stripped log metadata, the networking variant guard, the golden-image clone refusal and the remaining pod rolls. This edits the same file as [#764](#764). They conflict on one line in Smaller changes: #764 removes the HTTPCache bullet right above the prefix line fixed here, so the second one to land drops the HTTPCache bullet and keeps `spec.release.prefix`.
IvanHunters
reviewed
Oct 30, 2026
IvanHunters
left a comment
IvanHunters
left a comment
Contributor
There was a problem hiding this comment.
The HTTPCache section itself is accurate: I checked every command against migrations/58 on cozystack main (ba0b1ac6e) and they line up, including the cozystack-packages-http-cache pinned source, the PackageSource and Package patches, the cozy:tenant:admin:http-cache-frozen ClusterRole, the digest read, and the empty-listing removal path.
That said, this one looks ready to close rather than merge. #782 states it takes over this content ("I'm not carrying 764 further, this PR takes over its content") and carries it in both next/ and v1.7/ on top of the fixes from #781, so the copy there is newer. This branch is also in conflict with main. Once #782 lands, closing this PR keeps a single source for the section.
myasnikovdaniil
added a commit
that referenced
this pull request
Oct 30, 2026
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>
myasnikovdaniil
added a commit
that referenced
this pull request
Oct 30, 2026
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>
myasnikovdaniil
added a commit
that referenced
this pull request
Oct 30, 2026
) The v1.7 docs were cut from `next/` in #780 while several docs PRs about v1.7.0 behaviour were still open against `next/` only, so `/docs/v1.7/` and the stable `/docs/` copy miss them. This adds their content to `content/en/docs/v1.7/`, checked against the v1.7.0 tag. Every page is the source PR's `next/` file with the same `/docs/next/` rewrite that `hack/release_next.sh` does, except where noted. - #763 - #747, hand-merged after `networking.kubeovn.MASTER_NODES` because main got the `networking.encryption.enabled` row after its base - #761, with four corrections below - #762 - #766 - #764, the HTTPCache section of the upgrade guide, in both `next/` and `v1.7/` on top of the fixes from #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: 2` in the KubernetesNodes example is now `minReplicas: 2` and `maxReplicas: 2`, there is no `replicas` field. The CCM and CSI controller Deployments are `kubernetes-<cluster>-pccm` and `kubernetes-<cluster>-pcsi-controller`. `bundles.enabledPackages` is set on the `cozystack.cozystack-platform` Package, no ConfigMap feeds it. The CSI release depends only on the tenant Cilium release, not on the CCM, so I cut that clause. The `next/` copy in 761 needs the same fixes. The `next/` side of 763, 747, 761, 762 and 766 and the `v1.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 from `v1.7/` at build time. Hugo production and preview builds, `hack/check-i18n.sh` and a link and anchor check of every changed page pass locally, with the same Hugo warnings as main.
Contributor
Author
|
Done via #782 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Upgrade page from #757 says that on
defaultvariant the steps of migrations 54 to 59 for SeaweedFS, VM volume hotplug and HTTPCache are the operator's to take before the upgrade. SeaweedFS and hotplug got a procedure and a line in "Before you upgrade", HTTPCache got neither: checklist doesn't mention it and its entry only says to look for instances withkubectl get httpcaches.apps.cozystack.io -A.HTTPCache leaves the platform in v1.7, so the upgrade prunes its PackageSource, ArtifactGenerator and both ExternalArtifacts go with it, and
http-cache-rdwith every tenanthttp-cache-<name>release stayReady=Falsefor good. Migration 58 prevents that on other variants by freezing the PackageSource on the packages artifact the cluster already runs, or by removing the application where no instance exists.HTTPCache now has its own section next to SeaweedFS with the same steps for a
defaultcluster: instance listing, removal commands when the listing is empty, and otherwise the digest read, the pinnedcozystack-packages-http-cachecopy, PackageSource and Package patches and thecozy:tenant:admin:http-cache-frozenClusterRole. Commands are taken frommigrations/58with name variables written out and the version stamp dropped, same way the SeaweedFS section reuses migration 57. Checklistdefaultline and row 58 of the migrations table link to the new section.I ran the instance listing and the digest read on a live cluster, listing was empty there and digest read printed a
sha256:value. Freeze and removal are checked against the script only, not run on adefaultvariant cluster.Only
next/changed, it is not promoted tov1.7/yet. Checked locally: Hugo 0.164.0 build, in-page anchors, i18n checks.