Does any Harbor component trigger blob deletion requests

[djdongjin]

We have harbor running on Azure (blob). We noticed there are object deletion requests on Azure blob (from cloud provider metrics). However,

1. we didn't enable GC;
2. we didn't delete images (at least from harbor core/registry metrics we didn't observe any DELETE requests).

We're still looking into if it's caused by cloud provider or there are unexpected image deletion on our side. Meanwhile curious given 1 and 2, is there any other Harbor component that may send requests to delete blob objects (e.g., even some metadata).

Thanks!

[Vad1mo]

can be reports, that can be stored as OCI artifacts. Or it might be deletion of failed multipart file uploads.

[AllForNothing]

Is there any Push-based replication rule targeted to Azure in your Harbor?

[djdongjin]

@AllForNothing thanks for the info. Yeah we do have another harbor endpoint that has a push-based replication rule targeting this Azure harbor (and enabled the Delete remote ... box).

So this will cause delete operations on the blob storage of target harbor? Can you help explain what this feature does? My understanding is if there is an image deletion on source harbor, it will also be replicated to dst harbor, causing the deletion there as well? (Sorry I could find the "explanation" icon on my harbor UI 😅)

Thanks!

[AllForNothing]

@djdongjin Can you provide the detail content of the deletion requests?

[djdongjin]

We didn't enable azure blob access log so couldn't find the exact deleted content (e.g., filename, etc). I'll update here if I could find some details from other sources. thanks!

[AllForNothing]

So this will cause delete operations on the blob storage of target harbor? Can you help explain what this feature does? My understanding is if there is an image deletion on source harbor, it will also be replicated to dst harbor, causing the deletion there as well? (Sorry I could find the "explanation" icon on my harbor UI 😅)

You can refer to the doc https://goharbor.io/docs/2.9.0/administration/configuring-replication/create-replication-rules/

If you delete an image in your Harbor, then your Harbor will send a delete request to the remote registry(Harbor doesn't care how the remote registry handles this request).

the "explanation" icon was added in version 2.10.0

You can set such a replication rule, delete an image in your Harbor, and see if there is a corresponding deletion request in your Azure registry.

Except for the replication rule, Harbor will not trigger the deletion of the remote registry in any component.

[djdongjin]

@AllForNothing sorry for the late reply!

Actually I found the deletion events also happen in our leader Harbor on AWS (S3), i.e., no any registries replicating TO this harbor. And we don't delete any images (only 1 delete log from long ago).

So I guess these blob deletion events are not related to replication or image deletion.

Actually, if we retag an image and let the tag point to a different image manifest, will that trigger a deletion? (delete the existing tag, recreate the same new tag pointing to the new image manifest)?

[AllForNothing]

@djdongjin

Actually, if we retag an image and let the tag point to a different image manifest, will that trigger a deletion? (delete the existing tag, recreate the same new tag pointing to the new image manifest)?

Yes, that would be possible if you've configured a scheduled tag-retention with the untagged option enabled(or manually run this tag-retention)

[wy65701436]

In essence, from Harbor's standpoint, only GC will initiate the blob deletion request. Any other operation will simply trigger a soft manifest deletion.

Can you share the request received of your cloud provider?

[github-actions[bot]]

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 30 days with no activity. If this issue is still relevant, please re-open a new issue.