Hi @dweomer. Thanks for your PR.

I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Containerd folks: this is something of a magic trick / hack that we will likely be carrying a patch for in the k3s-io/containerd fork specifically for RKE2 and I wanted to at least share with upstream. I am open to alternative methods of achieving the desired functionality.

Additional caveat: only works for images pulled via CRI.

Build succeeded.

• containerd-build-arm64 : SUCCESS in 5m 40s (non-voting)

Cool - love this PR!!

Do you think this can be used or enhanced in a way that we can also rewrite based on the source namespace/path?

I.e. rewrite

1. registry.example.com:5000/namespace1/directory1/image:123 -> own.registry.local:5000/abc/def/image:123

AND at the same time (source is only different in namespace but on same source registry)

2. registry.example.com:5000/namespace99/directory5/image:456 -> own.registry.local:5000/xyz/aaa/image:456

@Martin-Weiss these use cases are supported as the rewrite rules are regular expressions for matching/replacing anything after the registry root path for actual resources (typically /v2).

Build succeeded.

• containerd-build-arm64 : SUCCESS in 5m 40s (non-voting)

This feature feels to me like it stretches the scope of the containerd project, as it's a bit of higher-level feature. Since the CRI plugin is now a core part of containerd, I think it makes sense for the CRI plugin to stay as close to just implementing CRI as possible rather than adding additional non-standard features.

I am open to alternative methods of achieving the desired functionality.

I have two ideas here that might be alternatives:

1. Because this is focused on CRI/K8s, have you considered doing this as a mutating webhook? It would then be independent of the ultimate container runtime on the node and could be controlled at the cluster level instead of on an individual node.
2. Rather than building something specific for rewriting the image name, there might be an opportunity to introduce a new extension point into containerd that could allow one plugin to modify an incoming API request, similar to the concept of "middleware" in a web app. If this extension point existed, you could then write a image rewrite plugin that used that mechanism.

Trying to give some additional thoughts - please forgive me if these are invalid because I am not deep enough into the details..

This feature feels to me like it stretches the scope of the containerd project, as it's a bit of higher-level feature. Since the CRI plugin is now a core part of containerd, I think it makes sense for the CRI plugin to stay as close to just implementing CRI as possible rather than adding additional non-standard features.

I am open to alternative methods of achieving the desired functionality.

I have two ideas here that might be alternatives:

1. Because this is focused on CRI/K8s, have you considered doing this as a mutating webhook?  It would then be independent of the ultimate container runtime on the node and could be controlled at the cluster level instead of on an individual node.

One challenge is that we need the "rewrite" before k8s is up and running at all - so it must be "below". So I am not sure if this makes sense on a higher level that is not yet available when we have to bootstrap / load initial images and containers into containerd.

2. Rather than building something specific for rewriting the image name, there might be an opportunity to introduce a new extension point into containerd that could allow one plugin to modify an incoming API request, similar to the concept of "middleware" in a web app.  If this extension point existed, you could then write a image rewrite plugin that used that mechanism.

Basically the "registry mirror" feature is "just" missing functionality we need in on premise deployments where we just have one central registry with namespaces and where we have to map "external registry/namespace/image to an internal registry/other namespace".
So "enhancing" the registry mirror" by supporting namespaces was the idea.. in case of adding a new extension point - could it be that this increases testing complexity? Is supporting "namespaces" for images on the registry not part of the scope?

@mikebrow do we still think this can get accepted?

For reference cri-o provides the equivalent logic in their container runtime

@dmcgowan heads up... let's discuss

Wonder if this PR is still valid, because I see it's remained open w/o any update quite long time. I'm having the same problem where I need to map the image into a different namespace.

Wonder if this PR is still valid, because I see it's remained open w/o any update quite long time. I'm having the same problem where I need to map the image into a different namespace.

PR would need to be ported to the hosts model ..

Thanks @mikebrow ! Do you know when this will be done?

Thanks @mikebrow ! Do you know when this will be done?

no I don't

Hadn't checked in on this one in a while, folks, my apologies. I should have the time next week to incorporate requested changes and any necessary contortions to accommodate the newer config model.

2. Rather than building something specific for rewriting the image name, there might be an opportunity to introduce a new extension point into containerd that could allow one plugin to modify an incoming API request, similar to the concept of "middleware" in a web app. If this extension point existed, you could then write a image rewrite plugin that used that mechanism.

So, 14 months later, I like this idea! @samuelkarp has there been any work on such an effort you could point me to? (I am looking to dial into this project once again but I haven't done a full review of what I have "missed". Any pointers appreciated!)

has there been any work on such an effort you could point me to?

I'm not aware of any right now, but I've also been somewhat disconnected while between employers.

So, apologies again, after avoiding the 'rona for over 2 years it has overrun my home. Will be looking to get this refactor off my plate as soon as I am able.

I've decided to not work on this. If you need this functionality it is carried on the k3s fork at https://github.com/k3s-io/containerd/tree/k3s-release/1.5

I've decided to not work on this. If you need this functionality it is carried on the k3s fork at https://github.com/k3s-io/containerd/tree/k3s-release/1.5

Some pointers on getting the k3s fork of containerd:

• Built for RKE2 via https://github.com/rancher/image-build-containerd (with goboring on linux/amd64)
  • Pushed to Docker Hub: https://hub.docker.com/r/rancher/hardened-containerd/tags (all binaries in /usr/local/bin)
• Built for K3s via https://github.com/k3s-io/k3s/blob/master/scripts/build (used to be embedded but is now shipped as distinct executable)
  • Pushed to Docker Hub: https://hub.docker.com/r/rancher/k3s/tags (/bin/{containerd/containerd-shim-runc-v2})