[Question] regctl image delete behaviour, and regctl image update improvement

[ossfellow]

Question

Currently, if I use regctl to copy a multi-arch image into an OCI registry, I could use regctl image delete to remove the index and all the underlying arch-specific images/blobs; however, if I create a multi-arch index for a group of arch-specific images, then using regctl index delete literally does nothing, and using regctl image delete would only delete the index, and doesn't touch the images.
There could be good reasons for such a behaviour, but it's not apparent, and seems like an inconsistent behaviour from a user perspective; so, I'd appreciate it if you clarify why is that.

Another question, or rather suggestion, is about regctl image mod, which is a great assistance in converting docker format to OCI, or adding attributes like annotations; the only thing it doesn't support, or do, is adding platform information to images, which miss such information and are created by blackbox operations (i.e. user doesn't have control over image creation process to address the problem there).
Are there any reasons why this isn't supported?

Version

VCSTag:     v0.5.7
VCSRef:     832109d4e9ef96982c4a4a8614b276b752509e5b
VCSCommit:  832109d4e9ef96982c4a4a8614b276b752509e5b
VCSState:   clean
VCSDate:    2024-02-06T21:25:52Z
Platform:   darwin/arm64
GoVer:      go1.21.6
GoCompiler: gc

Environment

• Running as binary or container: binary
• Host platform: macOS (arm64)
• Registry description: Zot registry

[Brandon Mitchell]

Currently, if I use regctl to copy a multi-arch image into an OCI registry, I could use regctl image delete to remove the index and all the underlying arch-specific images/blobs; however, if I create a multi-arch index for a group of arch-specific images, then using regctl index delete literally does nothing, and using regctl image delete would only delete the index, and doesn't touch the images. There could be good reasons for such a behaviour, but it's not apparent, and seems like an inconsistent behaviour from a user perspective; so, I'd appreciate it if you clarify why is that.

The delete operation is for a specific tag, manifest, or blob. Presently, there isn't a recursive delete because of the risk that other content may share the same child objects. The preference is to allow the registry to garbage collect that data if it is unused.

For example, two versions of an image could be based on the same Alpine layers, and deleting one image shouldn't delete the base image layers out from the other image. Similar with manifests, the AMD64 image could be updated without changing the ARM64 image, and pushed as a second index. If the child manifests were also deleted, that would break the reference to the ARM64 image in the remaining index.

Another question, or rather suggestion, is about regctl image mod, which is a great assistance in converting docker format to OCI, or adding attributes like annotations; the only thing it doesn't support, or do, is adding platform information to images, which miss such information and are created by blackbox operations (i.e. user doesn't have control over image creation process to address the problem there). Are there any reasons why this isn't supported?

The features on regctl image mod have been added as needed. I'm curious what tool you are using that doesn't populate the platform values of the config. I'll mark this as a feature request to add in a future release.

[ossfellow]

Thanks very much for the clarification regarding the delete behaviour.
In respect to missing platform information, it's a containerized image build, from another open source project, which creates platform-specific images, but doesn't add the information.
I talked to the maintainers, which argue that since the produced image is platform specific, adding or not adding the platform information to the image is a user preference, not a necessity.
I wrote a script to do that as I'm building multi-arch images (amd64 and arm64) and stitch them together, but it looks too hacky, and the functionality seems useful for similar scenarios.
Thank you for considering this as an enhancement.

[Brandon Mitchell]

Thanks again for the suggestion. If you have any trouble with the fix in #693, let me know and we can reopen this.