cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From K B Shiv Kumar <kbs...@gmail.com>
Subject (Error?) In Usage Documentation
Date Tue, 04 Aug 2020 14:10:44 GMT
Hi,

Firstly, apologies if you have received multiple copies of this email.
I am just not able to send using my work id without being marked as
INVALID.

Coming to my observation...

Below is a snippet from the latest documentation on usage found at
http://docs.cloudstack.apache.org/projects/archived-cloudstack-administration/en/latest/usage.html

===BEGIN===

For example, suppose that your server is in GMT, your user population
is predominantly in the East Coast of the United States, and you would
like to process usage records every night at 2 AM local (EST) time.
Choose these settings:

enable.usage.server = true
usage.execution.timezone = America/New_York
usage.stats.job.exec.time = 07:00. This will run the Usage job at 2:00
AM EST. Note that this will shift by an hour as the East Coast of the
U.S. enters and exits Daylight Savings Time.
usage.stats.job.aggregation.range = 1440

With this configuration, the Usage job will run every night at 2 AM
EST and will process records for the previous day’s midnight-midnight
as defined by the EST (America/New_York) time zone.

Note

Because the special value 1440 has been used for
usage.stats.job.aggregation.range, the Usage Server will ignore the
data between midnight and 2 AM. That data will be included in the next
day’s run.

===END===

In the above example, shouldn’t the example mean

usage.aggregation.timezone = America/New York
instead of
usage.execution.timezone = America/New York

In the above example, on one hand the server is in GMT, which has been
overridden by the usage.execution.timezone = America/New_York setting
and on the other hand the explanation goes on to say that 07:00 would
actually be 02:00 EST (which is GMT 07:00). As per the requirement in
the example, since the management server is already in GMT we need not
give any value to usage.execution.timezone nor
usage.aggregation.timezone and it should still suffice with the other
parameters as per the example.

The present context doesn’t make any sense to me (am I missing something ?)

K B Shiv Kumar
@ IndiQus Technologies


-- 
Regards
Shiv

Mime
View raw message