+++ This bug was initially created as a clone of Bug #1822472 +++ Description of problem: Reports using the query namespace-persistentvolumeclaim-usage show values that do not match the actual space used. Version-Release number of selected component (if applicable): # oc version Client Version: 4.3.9 Server Version: 4.3.9 Kubernetes Version: v1.16.2 How reproducible: Always Steps to Reproduce: 1. Create the following two reports: apiVersion: metering.openshift.io/v1 kind: Report metadata: name: ns-pvc-usage namespace: openshift-metering spec: query: namespace-persistentvolumeclaim-usage reportingEnd: "2020-04-08T19:30:00Z" reportingStart: "2020-04-08T18:40:00Z" apiVersion: metering.openshift.io/v1 kind: Report metadata: name: ns-pvc-usage-hourly namespace: openshift-metering spec: query: namespace-persistentvolumeclaim-usage reportingStart: "2020-04-08T18:50:00Z" schedule: hourly: {} period: hourly 2. Create a new project, add a pod, and a PVC, and fill up some space in the PV. In this case I created a 3GB PVC, and wrote 512MB: sh-4.2$ df /data Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdd 2819104 532884 2269836 20% /data 3. Wait for the reports to execute. Actual results: The report that only runs for a defined period of time shows the following data: period_start,period_end,namespace,persistentvolumeclaim_usage_bytes 2020-04-08 18:40:00 +0000 UTC,2020-04-08 19:30:00 +0000 UTC,test-metering,27283660800.000000 Those 27283660800 bytes do not match with the 512MB actually written in the PVC, or with the block size, that would be 2886762496 bytes. The value shown is one order of magnitude larger than the block device. The report that runs hourly shows completely different values from the other report, even though they use the same reportquery: The first execution shows a completely different value from the other report, even though no more data was written in the volume, and the second and subsequent executions show a new value. None of those three values represent the actual space usage on the PVC: 2020-04-08 18:50:00 +0000 UTC,2020-04-08 19:00:00 +0000 UTC,test-metering,5456732160.000000 2020-04-08 19:00:00 +0000 UTC,2020-04-08 20:00:00 +0000 UTC,test-metering,32740392960.000000 2020-04-08 20:00:00 +0000 UTC,2020-04-08 21:00:00 +0000 UTC,test-metering,32740392960.000000 2020-04-08 21:00:00 +0000 UTC,2020-04-08 22:00:00 +0000 UTC,test-metering,32740392960.000000 2020-04-08 22:00:00 +0000 UTC,2020-04-08 23:00:00 +0000 UTC,test-metering,32740392960.000000 2020-04-08 23:00:00 +0000 UTC,2020-04-09 00:00:00 +0000 UTC,test-metering,32740392960.000000 2020-04-09 00:00:00 +0000 UTC,2020-04-09 01:00:00 +0000 UTC,test-metering,32740392960.000000 2020-04-09 01:00:00 +0000 UTC,2020-04-09 02:00:00 +0000 UTC,test-metering,32740392960.000000 2020-04-09 02:00:00 +0000 UTC,2020-04-09 03:00:00 +0000 UTC,test-metering,32740392960.000000 2020-04-09 03:00:00 +0000 UTC,2020-04-09 04:00:00 +0000 UTC,test-metering,32740392960.000000 2020-04-09 04:00:00 +0000 UTC,2020-04-09 05:00:00 +0000 UTC,test-metering,32740392960.000000 2020-04-09 05:00:00 +0000 UTC,2020-04-09 06:00:00 +0000 UTC,test-metering,32740392960.000000 Expected results: The reports should show accurate and consistent values of the space used. Additional info:
Re-targeting to 4.6 as this isn't a blocker bug.
*** This bug has been marked as a duplicate of bug 1841883 ***