Hi Shiv,

I think generally it would make sense to set both the aggregation and execution 
timezone same, the aggregation timezone I think is what gets used while 
aggregating records (generation of records) by some aggregation timeperiod 
(like hourly, daily etc in seconds). On top of my head I'm not sure how they're 
used, you may explore the usage manager class to see what specific global 
settings are used.


Regards.

________________________________
From: K B Shiv Kumar <kbs...@gmail.com>
Sent: Saturday, August 8, 2020 23:20
To: users@cloudstack.apache.org <users@cloudstack.apache.org>
Subject: Re: (Error?) In Usage Documentation

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, <kbs...@gmail.com> 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
>

rohit.ya...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue
  
 

Reply via email to