Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1790601

Summary: Metering reports needs documentation improvement about "runImmediately" spec
Product: OpenShift Container Platform Reporter: Pedro Amoedo <pamoedom>
Component: Metering OperatorAssignee: Brett Tofel <btofel>
Status: CLOSED ERRATA QA Contact: Peter Ruan <pruan>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.2.zCC: btofel, scuppett, sd-operator-metering, sreber, tflannag
Target Milestone: ---Flags: tflannag: needinfo+
Target Release: 4.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
We've updated the description of runImmediately in the upstream and downstream documentation. Here is the new description: https://docs.openshift.com/container-platform/4.3/metering/reports/metering-about-reports.html#metering-runImmediately_metering-about-reports
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-05-04 11:24:06 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Pedro Amoedo 2020-01-13 17:20:01 UTC
Description of problem:

As per documentation[1], the "runImmediately" option states the following:

~~~
Set spec.runImmediately to true to run the report immediately with all available data, regardless of the reportingStart or reportingEnd values, and without checking if there is any data for the report period. For reports with a schedule set, it will not wait for each period’s reportingEnd to elapse before processing and all reportPeriods between reportingStart and reportingEnd.
~~~

However, when using that spec, the following issues appear:

1) Not all available data is gathered, it seems that it only takes the data from the moment when you apply the immediately spec until the "reportingEnd" spec, is this expected?

2) If setting the spec without "reportingEnd" parameter, it throws the following error, is this also expected? shouldn't be ignoring both "reportingStart" "reportingEnd" parameters when using "runImmediately" as documented?

~~~
message: spec.reportingEnd must be set if report.spec.runImmediately is true
~~~

Version-Release number of selected component (if applicable):

OCP 4.2

How reproducible:

Always

Steps to Reproduce (quotting consultant's feedback):

1. For the test case I cloned:
 - weekly report: report-cs-application-storage-raw-weekly-02555157.yaml
 - the ReportQuery used: reportquery-cs-application-storage-raw-02555157.yaml

2. I created the report before the ReportQuery so it will be invalid.

```
status:
  conditions:
    - lastTransitionTime: '2020-01-13T10:16:44Z'
      lastUpdateTime: '2020-01-13T10:16:44Z'
      message: ReportQuery (cs-application-storage-raw-02555157) does not exist
      reason: InvalidReport
      status: 'False'
      type: Running
```

3. Let's create the ReportQuery and Recover the failed report with Retroactive date.

oc patch report cs-application-storage-raw-weekly-02555157 --type json --patch "$(< patch-without-runImmediately.json)"

```
status:
  conditions:
  - lastTransitionTime: 2020-01-13T10:19:11Z
    lastUpdateTime: 2020-01-13T10:19:11Z
    message: 'Report cs-application-storage-raw-weekly-02555157 scheduled: reached
      end of reporting period [2020-01-05 00:00:00 +0000 UTC to 2020-01-12 00:00:00
      +0000 UTC].'
    reason: Scheduled
    status: "True"
    type: Running
  tableRef:
    name: report-openshift-metering-cs-application-storage-raw-weekly-02555157

```
```
status:
  conditions:
  - lastTransitionTime: 2020-01-13T10:19:13Z
    lastUpdateTime: 2020-01-13T10:19:13Z
    message: 'Report has finished reporting. Report has reached the configured spec.reportingEnd:
      2020-01-12 00:00:00 +0000 UTC'
    reason: Finished
    status: "False"
    type: Running
  lastReportTime: 2020-01-12T00:00:00Z
  tableRef:
    name: report-openshift-metering-cs-application-storage-raw-weekly-02555157
```

5. Check data:

presto:metering> select * from report_openshift_metering_cs_application_storage_raw_weekly_02555157;
      period_start       |       period_end        | sender_optionid | evidence1_domainid |      evidence2_domainid       |        evidence2         |     ev
-------------------------+-------------------------+-----------------+--------------------+-------------------------------+--------------------------+-------
....
(11 rows)

6. Remove the patch.

  oc patch report cs-application-storage-raw-weekly-02555157 --type json --patch "$(< remove-patch.json)"

  Schedule period back to normal
```
status:
  conditions:
  - lastTransitionTime: 2020-01-13T10:19:13Z
    lastUpdateTime: 2020-01-13T10:20:56Z
    message: Next scheduled report period is [2020-01-12 00:00:00 +0000 UTC to 2020-01-19
      00:00:00 +0000 UTC]. next run time is 2020-01-19 00:00:00 +0000 UTC.
    reason: ReportingPeriodWaiting
    status: "False"
    type: Running
  lastReportTime: 2020-01-12T00:00:00Z
  tableRef:
    name: report-openshift-metering-cs-application-storage-raw-weekly-02555157
```

Actual results:

Using "runImmediately" produces unexpected results not gathering all available data, therefore, a workaround (that needs your supervision) was implemented as showed above (PFA the referenced yaml files if needed).

Expected results:

IMHO, using "runImmediately" should gather all available data (as documented) without having to set "reportingStart" nor "reportingEnd".

Additional info:

[1] - https://docs.openshift.com/container-platform/4.2/metering/reports/metering-about-reports.html#metering-runImmediately_metering-about-reports

Comment 11 errata-xmlrpc 2020-05-04 11:24:06 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:0581