[docs-only] add locking adr

[wkloucek]

Description

add an ADR about locking

Related Issue

• Fixes Evaluate File Locking in the WOPI Server #2678, additional discussion needed
• file locking strategy for migration #2548

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[dragotin]

LGTM

[pmaier1]

Thanks 👍

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[wkloucek]

@pmaier1 @dragotin If we're coming to a quick decision I'm fine with updating it. If this is a longer discussion we can merge this and update the result later.

[glpatcern]

As pointed out by @wkloucek I added some comments from my perspective as "WOPI operator".

To be noted the related cs3org/reva#1786 issue, which won't be entirely superseded by a CS3 Lock API.

[glpatcern]

An additional item for this scenario (pure hypothetical I know, but for the sake of it):
- no locking breaks the WOPI specs, as the CS3 WOPI server won't be capable to honor the WOPI Lock related operations

[dragotin]

Oh yes, good point.

[glpatcern]

The semantic of the lock API would need to include the possibility to decorate the lock with some arbitrary metadata. Currently the CS3 WOPI server is stateless and stores some (JWT-encoded) information in the locks for its operations.

[dragotin]

Couldn't it use the general API to store metadata to files in CS3? Or do you mean that it is lock-specific metadata, ie. who locked (should be considered) or when the lock started, or how long? Even that could, if it is in an unique namespace, be stored through the general API.

[glpatcern]

That's correct indeed: the metadata is lock-specific, but locks and files are 1-to-1 so it is "syntactically equivalent" to use the general metadata API, say with a wopilock xattr.
Yet, there's a semantic catch: as today a user can delete a lock file, with this assumption the user may delete the wopilock xattr, making the lock totally useless from a WOPI perspective. So for the sake of a Lock API - which on top is expected to be atomic (where implementing cs3org/reva#1786 would help, if the lock is ultimately stored somewhere by the storageprovider) - the lock metadata should stay attached to the lock "object" for the whole lock's lifetime.

[dragotin]

No, the user must not have access to this xattr. Good point, we need a distinction between "user-editable" and system meta data.
The lock "object" I think is the file that is locked itself. And that operation does not really have to be atomic, only in the sense that if a lock is created, there must not be another lock exsting. That is a create-if-not-exists operation which in it has somehow to be atomic.