Repository navigation
Conversation
Call out that customized DATA_MODEL_CACHE_CONFIG with managed Redis requires cache.managed: false (or removing the custom config) before upgrading, matching the Operator upgrades.md guidance for PROJQUAY-14267. Co-authored-by: Cursor <cursoragent@cursor.com>
9f39878 to
2e2e668
Compare
LiZhang19817
left a comment
LiZhang19817
left a comment
There was a problem hiding this comment.
Reviewed the cache upgrade guidance against the Quay 3.18 CRD and 5.0 operator behavior. The main issue is the timing of the keep-custom-configuration workaround: the 3.18 CRD rejects the new cache component. Details and suggested changes are in the inline comments.
| managed: false | ||
| ---- | ||
|
|
||
| . Apply the updated `QuayRegistry` resource, then proceed with the Operator upgrade. |
There was a problem hiding this comment.
[P1] Correct the version-dependent ordering of Option 1
This instructs a 3.18 customer to apply kind: cache before upgrading, but the 3.18 CRD's component enum does not include cache, so the API server rejects the update. See the 3.18 CRD.
Please distinguish the two paths: removing custom DATA_MODEL_CACHE_CONFIG can happen before the upgrade; retaining it requires the 5.0 CRD and operator to be installed before setting cache.managed: false. Explain that the latter path can temporarily reach the known rollout block and then resume after editing the CR. Update the equivalent before-upgrading claims in the technical-change and feature release notes as well. Redis should remain managed.
| include::modules/upgrading-minor-red-hat-quay.adoc[leveloffset=+2] | ||
| include::modules/manually-approving-pending-operator-upgrade.adoc[leveloffset=+2] | ||
| include::modules/upgrading-quayregistry.adoc[leveloffset=+2] | ||
| include::modules/upgrading-cache-component-custom-config.adoc[leveloffset=+2] |
There was a problem hiding this comment.
[P2] Present the cache preflight before upgrade approval
This prerequisite is currently included after the channel/upgrade guidance and the manual InstallPlan approval section. A customer reading sequentially can start the upgrade before learning that their custom cache configuration needs attention.
Please move the preflight ahead of those upgrade actions and link to it from the approval guidance. Explain how to control automatic approval while preparing the upgrade, and make clear that the keep-custom-config action itself must wait for the 5.0 CRD/operator; it cannot be applied to the 3.18 CRD.
|
|
||
| .Verification | ||
|
|
||
| . After the upgrade completes, confirm that the registry advanced to the Operator version and that the rollout is not blocked: |
There was a problem hiding this comment.
[P2] Add recovery steps and explicit success criteria for an already-blocked registry
Please cover the reproduced state where the operator has reached 5.0 but the QuayRegistry remains at 3.18.2. Identify the condition precisely as RolloutBlocked=True, reason ConfigInvalid, with the cache-conflict message. Direct the user to edit the existing CR, preserve all other component entries and overrides, set cache.managed: false, retain redis.managed: true, and keep the custom config bundle unchanged.
Explain that normal reconciliation resumes automatically after the edit; another operator upgrade is not required. Verification should check the target status.currentVersion, registry availability, and that the rollout block is cleared. Availability alone is insufficient because the old registry can remain available while its upgrade is blocked.
|
|
||
| . Apply the updated `QuayRegistry` resource, then proceed with the Operator upgrade. | ||
|
|
||
| .. *Option 2*: Use Operator-managed cache defaults |
There was a problem hiding this comment.
[P2] Make the two options separate, consistently structured procedures
The list levels currently switch from . Option 1 to .. Edit, back to . Apply, and then .. Option 2. This makes Option 2 subordinate to the apply step rather than a sibling alternative, obscuring which steps belong to each choice.
Please use separate titled procedures or consistent sibling option items with nested steps. Render the document to verify the numbering and the placement of the IMPORTANT block. I checked the source markup but did not run an AsciiDoc build.
| [role="_abstract"] | ||
| {productname} 5.0 introduces a `cache` component on the `QuayRegistry` custom resource. Before you upgrade, review whether your deployment uses a customized `DATA_MODEL_CACHE_CONFIG` with managed Redis, and take the required action so the upgrade is not blocked. | ||
|
|
||
| In previous releases, each {productname} pod used an internal Memcached instance for data model caching, and cached data was not shared between pods. Starting in {productname} {producty}, the Operator can configure {productname} to use Redis as the shared cache store. Redis-backed caching reduces database pressure and helps prevent stale cache scenarios across pods. |
There was a problem hiding this comment.
[P3] Qualify the previous Memcached behavior as the default
Previous releases could already use a shared Redis or Redis Cluster data-model cache through DATA_MODEL_CACHE_CONFIG; they did not invariably use per-pod Memcached. The 3.18 cache implementation already selects RedisDataModelCache for those engines.
Please say that previous releases used per-pod Memcached by default, while customers could configure another backend. Apply the same qualification to the new-feature release note. This matters here because existing custom Redis configurations are among the affected upgrade scenarios; the new capability is operator management/defaulting of the cache component.
Summary
cachecomponent upgrade prerequisite from PROJQUAY-14267: if a customizedDATA_MODEL_CACHE_CONFIGis present and Redis is managed, setcache.managed: falseor remove the custom config before upgradingcachecomponent to the managed components referenceTest plan
cacheappears in managed components table and example YAMLMade with Cursor