From cef89bdfa1a3408831773f6fb3d8bd698a31eb7a Mon Sep 17 00:00:00 2001 From: Austin Abro Date: Thu, 5 Dec 2024 20:23:32 +0000 Subject: [PATCH] docs Signed-off-by: Austin Abro --- site/src/content/docs/ref/init-package.mdx | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/site/src/content/docs/ref/init-package.mdx b/site/src/content/docs/ref/init-package.mdx index f00a6725e5..3bc4833f84 100644 --- a/site/src/content/docs/ref/init-package.mdx +++ b/site/src/content/docs/ref/init-package.mdx @@ -161,12 +161,6 @@ The `zarf-agent` modifies [ArgoCD applications](https://argo-cd.readthedocs.io/e > Support for mutating `Application` and `Repository` objects in ArgoCD is in [`beta`](/roadmap#beta) and should be tested on non-production clusters before being deployed to production clusters. -When the agent mutates an image that is not pinned to a digest, it appends a [CRC32 hash](https://en.wikipedia.org/wiki/Cyclic_redundancy_check) to the tag. For example, if the original image is `ghcr.io/stefanprodan/podinfo:6.4.0` and the Zarf registry address is `127.0.0.1:31999`, the mutated image will be tagged as `127.0.0.1:31999/stefanprodan/podinfo:6.4.0-zarf-298505108`. The CRC32 hash, 298505108, is generated using the original image name, ghcr.io/stefanprodan/podinfo, to prevent collisions. - -Without this unique hash, images with the same path but from different registries—such as `docker.io/stefanprodan/podinfo:6.4.0`-would overwrite each other when pushed to the Zarf registry. Zarf pushes both the regular tag and unique tag so no images are lost during a push, and the agent can always mutate to the correct image. To which image a pod used before mutation, check the `zarf.dev/original-image-` annotation. - -Similarly, when Git repositories are pushed to the Zarf Git server their name is appended with a CRC32 hash. - :::note During the [`zarf init`](/commands/zarf_init) operation, the Zarf Agent will add the `zarf.dev/agent: ignore` label to prevent the Agent from modifying any resources in that namespace. This is done because there is no way to guarantee the images used by pods in existing namespaces are available in the Zarf Registry. @@ -175,7 +169,13 @@ If you would like to adopt pre-existing resources into a Zarf deployment you can ::: -### Mutating +#### Image Mutation to Unique Hashed Tags + +When the agent mutates an image that is not pinned to a digest, it appends a [CRC32 hash](https://en.wikipedia.org/wiki/Cyclic_redundancy_check) to the tag. For example, if the original image is `ghcr.io/stefanprodan/podinfo:6.4.0` the mutated image tag will be `6.4.0-zarf-298505108`. The CRC32 hash `298505108` is generated using the original image name `ghcr.io/stefanprodan/podinfo`. + +Without this unique hash, images from different registries with the same path—such as `docker.io/stefanprodan/podinfo:6.4.0`-would overwrite each other when pushed to the Zarf registry. Zarf pushes both the regular tag and the unique tag for non pinned images. This ensures no images are lost during a push, and the agent can always mutate to the correct image. To see which image a pod used before mutation, check the `zarf.dev/original-image-` annotation. + +Additionally, when Git repositories are pushed to the Zarf Git server their name is appended with a CRC32 hash to prevent similar collisions. #### Excluding Resources from `zarf-agent`