add more upload session filters

[butonic]

This PR deprecates the ocis storage-users uploads list command:

NAME:
   ocis storage-users uploads list - Print a list of all incomplete uploads (deprecated, use sessions)

USAGE:
   ocis storage-users uploads list [command options] [arguments...]

OPTIONS:
   --help, -h  show help

It also introduces the ocis storage-users uploads sessions command:

NAME:
   ocis storage-users uploads sessions - Print a list of upload sessions

USAGE:
   ocis storage-users uploads sessions [command options] [arguments...]

OPTIONS:
   --id value      filter sessions by upload session id
   --processing    filter sessions by processing status
   --expired       filter sessions by expired status
   --output value  output format to use (can be 'plain' or 'json',  experimental) (default: plain)
   --help, -h      show help

In oc10 occ we also added cli flags to allow rendiring output as json. I marked that as experimental, let me know what you think.

The storageprovider only has a boolean processing flag. Before we can expose processing step outcomes via the upload session interface we need to change the persistence of upload sessions. Currently, it lives in the node metadata, we should move it to the upload session so every uploed session can track its own processing status.

The filter currently only allows an expired true/false flag. I don't think we need a full timestamp filter, yet.

Should we add a --purge option to the session command? it would allow purging specific upload sessions ... or multiple based on filter. or is that too much of a shotgun?

How do we restart postprocessing? should we add a --restart option and then trigger postprocessing?

Let me know what you think!

[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.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
4 Code Smells

0.0% Coverage
16.1% Duplication

[butonic]

• add command to restart all unprocessed uploads

[micbar]

@butonic please add dev docs about the new command.

[butonic]

@kobergj Hm, how do we actually determine if an upload session is stuck in postrocessing? Only postprocessing service really knows. Currently, the storage provider derives the session IsProcessing() response by calling node.IsProcessing() so all uploads to the same file share the same processing state ...

Only the postrocessing service knows the state. The storage provider will emit an UploadReady{Failed: true}. I'll need to check what that does. If all is well the postprocessing service can iterate over all UploadReady events with failed true and just restart them? But how do we differentiate that from an upload that aborted because of a policy or virus found? In case of outcome PPOutcomeAbort or PPOutcomeDelete an UploadReady{Failed: true} event is emitted. No way to distinguish them.

[kobergj]

It does nothing, but it should probably. 😄 Let's pair on it tomorrow!

[butonic]

the command to restart upload sessions needs to go into the postprocessing service, so this PR is complete.

[kobergj]

I can't believe you commented your exported funcs! Finally the linter can be happy even without me 😄

Code looks good in general, just some nitpicks as always 👍

[kobergj]

the command to restart upload sessions needs to go into the postprocessing service, so this PR is complete.

Already working on this, but needs a round trip through reva: cs3org/reva#4477

ocis PR: #8287

[sonarqubecloud]

Quality Gate passed

The SonarCloud Quality Gate passed, but some issues were introduced.

3 New issues
0 Security Hotspots
0.0% Coverage on New Code
13.9% Duplication on New Code

See analysis details on SonarCloud

[kobergj]

LGTM