Bug 1790601 - Metering reports needs documentation improvement about "runImmediately" spec
Summary: Metering reports needs documentation improvement about "runImmediately" spec
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Metering Operator
Version: 4.2.z
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.4.0
Assignee: Brett Tofel
QA Contact: Peter Ruan
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-01-13 17:20 UTC by Pedro Amoedo
Modified: 2023-03-24 16:42 UTC (History)
5 users (show)

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
Clone Of:
Environment:
Last Closed: 2020-05-04 11:24:06 UTC
Target Upstream Version:
Embargoed:
tflannag: needinfo+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github operator-framework operator-metering pull 1094 0 None closed Bug 1790601: Fix description of runImmediately 2020-04-21 19:49:25 UTC
Red Hat Product Errata RHBA-2020:0581 0 None None None 2020-05-04 11:24:32 UTC

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


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