cli: add command to update users disk quota usage

[mvidalgarcia]

closes reanahub/reana-workflow-controller#333
closes #88

[mvidalgarcia]

This update probably needs to be done in some other places:

• Workflow deletion
• File upload (reana-client upload -w roofit myscript.py)
• Some others?

WDYT?

[mvidalgarcia]

Another thing, here we're calculating and storing WorkflowResource for the CPU but we're no calculating that anywhere else for disk. How should we address this? I think for disk is trickier as it's not necessarily accumulative as a user can add and remove files from the workflow workspace. Probably in this case it needs to be calculated every time? I think the value corresponds to get_workspace_disk_usage function directly.

[diegodelemos]

I think:

1. Workflow deletion (reana-client delete -w w1) -> rerun the full calculation

2. File upload/deletion (reana-client rm/reana-client upload) -> we can run the full calculation for now but, this can become dangerous:

   • Doing this calculation on every upload could be a very expensive server-side operation, as we upload each file on a different HTTP request.
   • We know how big those files are when uploaded, so in theory we can just increment/decrement the disk usage by the number of bytes the files occupy at workflow and user level.

   We could deal with this outside this PR group, as a standalone issue.

3. Interactive session closed (reana-client close -w w1) -> run full calculation, no way around it

4. Workflow finishes/fails/stops (addressing the second question)-> run a full calculation, and overwrite the value in WorkflowResource using get_workspace_disk_usage even at the risk of not being fully correct in the overall as a function of time for now (it could be correct if we implement the fix for 2.). This way we make the workflow list request (mostly coming from the UI) more light (see here). get_workspace_disk_usage could be checking the DB (WorkflowResource) and if there is not calculated disk usage run du and update WorkflowResource.

Fix for 2. and going beyond full calculation in 4. are probably outside of the scope of this PR.

[mvidalgarcia]

• 1. Addressed
• RE 3., what do you think about creating a status change listener in the new InteractiveSession model to run update_users_disk_quota.
• Maybe we can ticketize the other two based on your comment?

[diegodelemos]

RE 3., what do you think about creating a status change listener in the new InteractiveSession model to run update_users_disk_quota.

Tracked through here #90 (comment)

Maybe we can ticketize the other two based on your comment?

Let's create the tickets once we merge this? That would be a ticket for 2. and another for the improvement of 4., right? I can do it if you want.