Skip to content

Fixes a few errors in the Use Red Hat guide #596

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Feb 7, 2023
Merged

Fixes a few errors in the Use Red Hat guide #596

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions modules/proxy-cache-arch.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,9 +16,9 @@ image:updated-layers-in-cache.png[Updating opposing layers overview]

If the upstream image and cached version are the same, no layers are pulled and the cached image is delivered to the user.

In some cases, users initiate pulls when the upstream registry is down. If this happens with the configured staleness period, the image stored in cache is delivered. If the pull happens after the configured staleness period, the error is propagated to the user. The following image depicts an architectural overview when a pull happens after the configured staleness period:
In some cases, users initiate pulls when the upstream registry is down. If this happens with the configured staleness period, the image stored in cache is delivered. If the pull happens after the configured staleness period, the error is propagated to the user. The following image depicts an architectural overview when a pull happens after the configured staleness period:

image: cache-proxy-staleness-pull.png[Staleness pull overview]
image:cache-proxy-staleness-pull.png[Staleness pull overview]

Quay administrators can leverage the configurable size limit of an organization to limit cache size so that backend storage consumption remains predictable. This is achieved by discarding images from the cache according to the frequency in which an image is used. The following image depicts an architectural overview of this scenario:

Expand Down
2 changes: 1 addition & 1 deletion modules/quay-as-cache-proxy.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,6 @@ With the {productname} cache proxy technology preview, the following features ar
Because cache proxy is still marked as `Technology Preview`, there is no storage quota support yet. When this feature goes `General Availability` in a future release of {productname}, the expiration timer will be supplemented by another timer that protects against intermittent upstream registry issues.
====
* Global on/off configurable via the configuration application.
* Caching of entire upstream registries or just a single namespace, for example, all of `\docker.io` or just `\docker.io/library`.
* Caching of entire upstream registries or just a single namespace, for example, all of `docker.io` or just `docker.io/library`.
* Logging of all cache pulls.
* Cached images scannability by Clair.