scality / backbeat

Zenko Backbeat is the core engine for asynchronous replication, optimized for queuing metadata updates and dispatching work to long-running tasks in the background.
https://www.zenko.io
Apache License 2.0
53 stars 19 forks source link

Set 'null' as version id when replicating non versioned objects #2408

Closed Kerkesni closed 1 year ago

Kerkesni commented 1 year ago

Non versioned object are also considered a null version when in a versioned bucket, we should specify 'null' as query version id for Cloudserver to properly replicate these objects

Issue: BB-403

bert-e commented 1 year ago

Hello kerkesni,

My role is to assist you with the merge of this pull request. Please type @bert-e help to get information on this process, or consult the user documentation.

Status report is not available.

bert-e commented 1 year ago

Waiting for approval

The following approvals are needed before I can proceed with the merge:

Kerkesni commented 1 year ago

/approve

bert-e commented 1 year ago

In the queue

The changeset has received all authorizations and has been added to the relevant queue(s). The queue(s) will be merged in the target development branch(es) as soon as builds have passed.

The changeset will be merged in:

The following branches will NOT be impacted:

There is no action required on your side. You will be notified here once the changeset has been merged. In the unlikely event that the changeset fails permanently on the queue, a member of the admin team will contact you to help resolve the matter.

IMPORTANT

Please do not attempt to modify this pull request.

If you need this pull request to be removed from the queue, please contact a member of the admin team now.

The following options are set: approve

bert-e commented 1 year ago

I have successfully merged the changeset of this pull request into targetted development branches:

The following branches have NOT changed:

Please check the status of the associated issue BB-403.

Goodbye kerkesni.

nicolas2bert commented 1 year ago

Just to clarify, there seems to be 2 different cases:

Lifecycle Bucket Processor: In this case, the entry MD is sourced from either the listObject or listObjectVersions, and thus the "null" version is already appropriately set.

All the other processes: Here, we receive the pure object MD, and if the version id is undefined, a "null" version id is used for both getMetadata and putMetadata operations. CloudServer.putMetadata() will then determine how to handle the null version without a version id.

It would be interesting to consolidate/abstract the logic, so that when we utilize a versionId, we don't need to consider whether it has already been "processed" or not.

This task can be addressed in a subsequent ticket.