Any thoughts on this... experts ? Regards, Shiv (Sent from mobile device. Apologies for brevity and typos)
On Tue, 4 Aug, 2020, 19:40 K B Shiv Kumar, <[email protected]> wrote: > 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 >
