Feature request: Support for object lock functionality when using S3 remote target for backup shipping

[TheBitFighter]

Hello and first of all thank you for this amazing piece of software.
We run Linstor as the storage provider for our Proxmox cluster and I would like to use an S3 remote as a backup shipping target. Since my threat model for planning this architecture includes an intruder possibly gaining control over the cluster itself, I want my backups to be resilient against deletion or encryption by an attacker.

For this reason I would like to set object lock policies on my S3 remote when shipping a snapshot. I know through testing that setting default policies on the side of the S3 provider will break the snapshot shipping. Furthermore, my provider recommends setting these policies through the backup software anyway.
I have already identified which modifications would be needed to com.linbit.linstor.api.BackupToS3.java and started implementation.

My question would be how to best add this to the Linstor command line interface so it makes sense (e.g. adding a parameter called --lock-days to linstor remote create s3) and which other configuration points would benefit from additions (what about linstor.toml)?
Additionally, when setting up a remote to have retention time, should linstor automatically turn on object lock on the s3 bucket if it is not enabled or fail unless something like --enable-object-lock is given?

Also if there are any other rules concerning contribution that I have not been able to find, please let me know.

[ghernadi]

• --lock-days: I'm not sure if linstor.toml would make sense here. I think I get your reasoning to add --locks-days to remote create but honestly I would rather add that option as a property so that it can be overridden on different levels. Controller, resource-group and -definition would come to my mind (remotes currently do not have properties, but if necessary we could also add that as well, but as mentioned, I do not think that remote would be the right place).

• --enable-object-lock: I'd rather leave that configuration to the admin and let LINSTOR fail if someone tries to upload with "lock-days" into a non-locked (or unlocked? not sure how to call it) bucket.

• Contribution: We do have a few coding guidelines but we are always happy about contributions. The only weirdness I can think about right now is that we developing LINSTOR in a non-public git and push the code here to GitHub when we do a release. That means that we usually handle contributions the following way: We give you feedback here until the point where we would hit the "merge" button. But instead of merging your PR here on GitHub we will pull it into our internal git, merge it there and push the new master branch here to GitHub.

[TheBitFighter]

Alright, I will make sure to implement it like this. I have some (currently not yet working) code that was storing it as additional info for S3 remotes in the database using an argument when creating the remote (by adding --retention-days when creating or modifying a remote), I will look into how I can store it as a property instead.
As you might understand, this is a bit of a side quest at work for me, but I will definitely try to get this over the line.
I'll open up PRs on the respective repos once I have something working.