Bug 1822472 - namespace-persistentvolumeclaim-usage query returns unexpected values
Summary: namespace-persistentvolumeclaim-usage query returns unexpected values
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Metering Operator
Version: 4.3.z
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.7.0
Assignee: Brett Tofel
QA Contact: Peter Ruan
URL:
Whiteboard:
Depends On: 1841882
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-04-09 06:49 UTC by Alexis Solanas
Modified: 2024-06-13 22:33 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1841882 1841883 (view as bug list)
Environment:
Last Closed: 2021-02-11 17:02:26 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Alexis Solanas 2020-04-09 06:49:46 UTC
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:

Comment 2 tflannag 2020-06-01 14:19:37 UTC
Re-targeting to 4.6 as this isn't a blocker bug.

Comment 8 tflannag 2020-08-21 16:29:20 UTC
Adding the UpcomingSprint keyword now as we prioritized other bugs and work this last sprint. We plan on tackling this bug in 4.6/master this next sprint.

Comment 12 tflannag 2021-02-11 17:02:26 UTC
This is targeted a 4.3.z version, which isn't supported. This has been fixed in 4.7/master and will likely be backported to 4.6.


Note You need to log in before you can comment on or make changes to this bug.