docs: Image Digest Pinning#6870
Conversation
Add an "advanced" article to describe how `relatedImages` and image digest pinning works. This includes the use of `RELATED_IMAGE_*` environment variables to digest pin operands deployed by the operator, which is not currently documented. Signed-off-by: Adam Kaplan <adam.kaplan@redhat.com>
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
|
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
|
@sdk-approvers is operator-sdk accepting documentation improvements? |
|
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
|
@openshift-bot: Closed this PR. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Description of the change:
Add an "advanced" article to describe how
relatedImagesand image digest pinning works. This includes the use ofRELATED_IMAGE_*environment variables to digest pin operands deployed by the operator, which is not currently documented.Motivation for the change:
I was very confused by the behavior of
relatedImagesand digest pinning. For example - when attempting to setrelatedImagesin the base CSV manifest, I discovered thatoperator-sdk generate bundlewould always overwrite therelatedImagesfield in tree. It wasn't until I started iterating on a pull request (#6869) that I discovered there is an undocumented environment variable that lets operator authors define and wire in image digests for their operands.Checklist
If the pull request includes user-facing changes, extra documentation is required:
changelog/fragments(seechangelog/fragments/00-template.yaml)website/content/en/docs