AAP-45856 updated metrics-utility content

[emurtoug]

AAP-45856 [Doc] Update published subscription and metrics-utility content in configuring automation execution

Files modified:

• proc-configuring-the-metrics-utility.adoc

Title:

• controller-admin-guide

[himdel]

lines 83/84 still mention

0 */1 * * * metrics-utility gather_automation_controller_billing_data --ship --until=10m
0 4 2 * *  metrics-utility build_report

should be

0 */1 * * * /home/my-user/cron-gather
0 4 2 * * /home/my-user/cron-report

EDIT: resolved 👍

[himdel]

Suggested change

	chmod a+x /home/my-user/cron-gather
	/home/my-user/cron-report
	chmod a+x /home/my-user/cron-gather /home/my-user/cron-report

should be one line, not two, otherwise we're running the script, not making it runnable

EDIT: resolved 👍

[himdel]

This doesnt belong here?

If this section is about setting up a cron job, we probably don't want everyone to build a report while setting the cronjob?

(This may still make sense in a "after gather happened, you can try this to test if things will work ... but unless the user waits a month, build_report will fail because there would be no gathered data for the previous month - and all the variables are only set in the script, so just a bare metrics-utility build_report will fail on missing config.)

Let me know if you want to keep it and what for, I can suggest a way to run it that works, but I'd just remove running reports from the setting up cronjobs section.

EDIT: resolved 👍

[emurtoug]

Thanks, @himdel ! Can you clarify which lines you are recommending removing? Lines 115-122? These are the lines that reference building a report, but I just want to be sure.

[himdel]

Those are the ones, yes, 115-122.

Because you wouldn't want to build a report when just trying to configure things, right?

Unless it's to check that things are configured right and that something was collected to build the report from .. but then you probably want to do the checking right away, so the command would be different because it'd hhave to run for "this month" instead of the default "last month" (and you'd need all the env variables that we've just hidden in the script).

(If we wanted to do that, then i'd suggest changing line 61 from metrics-utility build_report to metrics-utility build_report "$@", to accept extra parameters when given, and then we'd change line 120 from metrics-utility build_report to something like /home/my-user/cron-build --since=2d, to make sure it picks up the freshly gathered data.)

[emurtoug]

Ok! I see what you mean. In line 94, we offer a procedure to check that data is being collected. Do you think that would be sufficient to check that something was collected to build the report from? If so, I think we should remove lines 115-122, since we already have a procedure to check that things are configured correctly. @himdel

[himdel]

Do you think that would be sufficient to check that something was collected to build the report from?

Hm, depends on how thorough we want to be, but I'd say yes :).

The cat /var/log/cron IS sufficient to see that the scheduled command did run, didn't error out, and did produce output.
(Specifically the CMDOUT line on line 93 tells us that a tarball was created, and where.)

So the user now knows the schedule is configured properly (or at least the half that doesn't run monthly), and that the monthly task would not fail on not having any data.

But they won't be able to check if the generated report will have the right headers without ..generating it first.
(Some of the values set in the environment variables are copied to the report headers, so, for example if the user creates the script with METRICS_UTILITY_REPORT_COMPANY_NAME="IBM" and they wanted "Red Hat" in the headers, they won't be able to tell without building the report.)

[emurtoug]

Ok! I have commented out this step for now with a summary of our reasoning. If someone wants to add a build report example down the line, it should be easy to do. Thanks @himdel !

[himdel]

missing space now

Suggested change

	chmod a+x /home/my-user/cron-gather/home/my-user/cron-report
	chmod a+x /home/my-user/cron-gather /home/my-user/cron-report

EDIT: resolved 👍

[himdel]

(line 78)

every second day of each month

Doesn't this sound like every other day?

I wonder if we need to change it to something like "on the second day of each month"?

EDIT: resolved 👍

[himdel]

Looks good to me 👍 :)

[michellemacrh]

Hi @emurtoug, is this PR still relevant or can it be closed out?

[himdel]

@emurtoug @michellemacrh Were any of these changes ever merged?

Is there a PR that replaces this one?

AAP-45856 is still open so I suspect our team is still waiting for these docs?

[emurtoug]

Hi @himdel - this PR was replaced and added on to by #3660 I have closed AAP-45856, as these changes were made and merged in June 2025 (see Jira comments). My apologies for leaving both this PR and the Jira open!

[himdel]

Ah, thanks! No worries, I missed that PR :)