cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From K B Shiv Kumar <s...@indiqus.com.INVALID>
Subject (Error?) in Usage Documentation
Date Tue, 04 Aug 2020 13:31:31 GMT
Hi,

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
<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 overriden 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 



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message