Harbor: Add support for replicating multi-arch images / manifests.

[darkl0rd]

Expected behavior and actual behavior:
When pushing an updated image/manifest with the same tag, I would expect this to be replicated as well.
In reality, harbor decides that the tag already exists in the remote repository and does not overwrite it.

Steps to reproduce the problem:
Build an image for ARM, build an image for AMD64, push the images. Create a manifest for the newly pushed images, with an existing tag (e.g. latest). Now push the manifest.
The local repository will have the manifest, but it will not be replicated to the remote repositories.

Versions:
Please specify the versions of following systems.

• harbor version: [1.7.0]
• docker engine version: [18.09.1-ce]
• docker-compose version: [1.21.2]

[darkl0rd]

To further clarify:

Build some images:

docker build -f Dockerfile -t image:tag-amd64
docker build -f Dockerfile -t image:tag-arm
docker push image:tag-amd64
docker push image:tag-arm

Create a manifest

docker manifest create --amend image:tag image:tag-amd64
docker manifest create --amend image:tag image:tag-arm

We now have a 'image:tag', referring the other two images, let's push the manifest:

docker manifest push --purge image:common_tag

The images (image:tag-amd64, image:tag-arm) are in the remote repository as expected.
However, the manifest is never replicated.

[darkl0rd]

Anything I can do here to move this forward?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Richard-Payne]

Are you saying that push and pull from the repo is broken? It seems to work fine for us. My issue, that you referenced, is only to do with the Harbor api, not the repo itself.

[darkl0rd]

No, push and pull works fine if you explicitly specify the tags (e.g. tag-amd64, tag-arm64). What doesn't work is replicating the manifest list (e.g. tag) which contains the references to the architecture specific tags -- see recently opened referenced issue.

[jloaiza]

This is also happening to me, but in my case the manifest tag is unique, but the replication job is not automatically triggered. @darkl0rd have you tried with a non-common tag?
Also, if I manually trigger a replication specifying the tag, it works; but only under those conditions: with a specific filter and manually trigger.
Same harbor version [1.7.0]

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Richard-Payne]

This hasn't been fixed, so don't try to auto-close it.

[darkl0rd]

See also #8855.

[ddompe]

Please, this is a critical feature, any idea of when will be supported? Or at least provide a flag to allow to push, even if the replication is broken?

[Jack47]

Please, this is a critical feature, any idea of when will be supported? Or at least provide a flag to allow to push, even if the replication is broken?

[l0nax]

Any updates about this Issue?

Has it been fixed by #10448?

[xaleeks]

This feels like a couple of issues mixed together. I didn't see a replication job configured, was this step omitted? This is referring to pushes with an existing tag on the registry isn't replicated over to a configured target registry? Sorry if I'm misunderstanding

[volschin]

As @ddompe said, there is a whole feature missing. If I do a replication from traefik:latest and the Harbor platform is amd64 only the amd64 image is replicated, not taken into account the arm64 and arm32 images also to be find in the same tag.
So this cant be used for deploying multiarch, if you have Intel but also arm machines in your fleet.
Or another example debian:stable-slim where you have 7 architectures in it.

[xaleeks]

First of all, multi arch was not really supported prior to latest release of 2.0 so behavior is anyone's guess, now please try out the newest release now to see if it's inline with your expectations.

@volschin From harbor to harbor (both 2.0 since only same version is supported), the replication is invoking a docker pull or push basically, and the behavior of docker for pulling multi arch images is indeed that it pulls the OS version of that image matching itself and nothing else. It's not dictated by harbor in any way.

@darkl0rd As for whether it should override existing images with a matching tag, there's an override option at the bottom. Are you saying that this function is broken with respect to any particular tag?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[l0nax]

I don't think this issue is "stale".

Are there any updates on this?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.