Decide where and make it possible to store per-object metadata for Object Lock

[amwolff]

Goal

This issue is to make meaningful progress on Object Lock implementation within core and edge services. Specifically, to support immutable backups in backup software products like Veeam.

What needs to be done? • Acceptance Criteria

AWS S3 tells us they store the lock information in the metadata for that object version:

When you lock an object version, Amazon S3 stores the lock information in the metadata for that object version.

1. With this context in mind, answer the following questions:

• Is it metadata visible to the user?
• Is it hidden from the user?
• Where in the metabase can we associate the lock information with the specific version?
  • Should this information be denormalized within the objects table?

2. Make changes to the satellite and the metabase

Modify the metainfo database and the methods that directly interact with it.

Summary

Implement this section from the draft design doc.

Depends on…

This issue slightly depends on

• 411

• 399

but in general, these should be possible to be worked on alongside each other.

Links

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

[jewharton]

• Is the Object Lock metadata visible to the user?

Yes, the Object Lock metadata is visible to the user. It's returned by the GetObject and HeadObject actions.

• x-amz-object-lock-legal-hold: Indicates whether an object has an active legal hold.
• x-amz-object-lock-mode: The Object Lock mode that's currently in place for an object.
• x-amz-object-lock-retain-until-date: The date and time when an object's Object Lock will expire.

• Can we store the lock information in the existing System metadata structure?

Yes. The system metadata structure (which I assume refers to (uplink.Object).System) is populated from object metainfo. As long as Uplink is able to retrieve Object Lock information from the metainfo database, it will be able to store it in this structure.

• Should this information be denormalized within the objects table?

Yes. It's best to store this information in the objects table because critical queries will need information about the locks.

[storj-gerrit[bot]]

Change satellite/metabase: add Object Lock retention columns to objects table mentions this issue.