Create a gateway-only partial implementation of Object Lock

[ferristocrat]

Goal

Completing this will make it possible to enable some object lock tests and determine how well we understand Object Lock.

What needs to be done? • Acceptance Criteria

Gateway-only/shim implementation means all tricks allowed. The state related to object lock can be stored in the object version's user metadata and can be modifiable outside the gateway (or even within the gateway!). The purpose of this is to make tests pass and figure out if there's anything that we missed during requirements gathering.

We only need to implement a small subset of Object Lock (for example, Legal Hold is out of scope at this moment). What needs to be implemented is defined in Object Lock milestone MVP section. To recap, it's:

• Adjust DeleteObject satellite endpoint (object retention) #401
• Adjust DeleteBucket (forceful deletion) satellite endpoint (object retention) #402
• Adjust PutObject satellite endpoint (object retention) #403
• GetObject
• HeadObject

So you only need to implement the above gateway-side only. This is very similar to what JT did for object versioning: miniogw/versioning: introduce object versioning wrapper

Depends on…

This issue does not depend on anything and can be worked on immediately.

Links

• an easy-to-read and insightful introduction to Object Lock: Using S3 Object Lock

[pwilloughby]

should this include retention periods set on the bucket?

[kaloyan-raev]

@pwilloughby Our current understanding is that Veeam sets the retention period on each object, not on the bucket. See my comment here: storj/roadmap#47 (comment)

[storj-gerrit]

Change cmd: force enable object lock mentions this issue.

[storj-gerrit]

Change cmd: force enable object lock config mentions this issue.