quotas: quota unit conversion server side

[diegodelemos]

Currently, we only return quota usage numbers in canonical units.

We should provide a way of getting the quota usage in human-readable ways (inside the /api/you and from inside Python calls) providing the number and the unit.

This feature will be used by:

• Users: using REANA-UI's your profile page (through /api/you)
• Users: using REANA-Client (through /api/you)
• Admins: consulting quota (through Python API)
• Admins: reading REANA system status report (through Python API)

To enable this change, we need to:

• Disk: Rethink the implementation of REANA-Commons' get_disk_usage function to:

  • Provide a default human-readable value/unit (the one that makes more sense e.g. if the usage is 54000 bytes, return 54 KB and not 0.054 MB).

  • Offer a way of getting the usage in the requested unit (e.g. MB, GB etc..)
    The function's current problems are:

    • Based on du which causes incompatibilities between Mac and Linux (GNU du and BSD du)
      • This can be solved by adding a platform check and depending on the platform type use the correct command options
    • The return value is inconsistent: when a specific unit is required (through block_size param), the return value is a number. However, when no unit is required the return value is a string composed of the number and a suffix with the unit e.g. 334K
      • This could be tackled by returning a tuple/dictionary, splitting the value and its unit (regardless if it was requested or it was auto-discovered).

    Whether we continue using du as the underlying implementation to calculate disk usage or not is indifferent, we should meet the requirement.

• CPU: Implement a new function to give human-readable usage times in REANA-Commons. It should

  • Provide the most human-readable format for a given usage (e.g. 2 days and 3 hours)
  • Offer a way of getting the usage in the requested unit (e.g. days, hours)

It would be great if both implementations implement a similar or even better, the same interface.

[mvidalgarcia]

The logic to display human-readable quotas has been already implemented in this PR. This logic should be moved to the server-side.

[tiborsimko]

I think all the use cases may be covered by returning base units by default (integers, such as 23424234234, implicitly meaning bytes), and human-friendly units on demand (strings, 7.9GB or 4.0MB). We can amend reana-client du to kill -b and -k and introduce -h; it would still keep an analogy with the Unix du command.

[mvidalgarcia]

Disk: Rethink the implementation of REANA-Commons' get_disk_usage function to:
...
The return value is inconsistent: when a specific unit is required (through block_size param), the return value is a number. However, when no unit is required the return value is a string composed of the number and a suffix with the unit e.g. 334K

This could be tackled by returning a tuple/dictionary, splitting the value and its unit (regardless if it was requested or it was auto-discovered).

This part is still missing. We should rethink whether we want to allow users to specify the unit (-b, -k) when running reana-client du or simply allow them to get human-readable by default and bytes if e.g. --raw is passed.

Current situation: Since we're now fetching this value from DB (if exists), we need to perform the conversion to transform bytes into KB, etc. which is not very nice. Ideally, we should convert to a human-readable format by default using our new function human_readable_unit or if --raw is specified just send the DB value in bytes.