subject:"\[ovirt\-users\] Re\: ETL service and winter hour"

[ovirt-users] Re: ETL service and winter hour

2018-10-29 Thread Shirly Radco

--

SHIRLY RADCO

BI SENIOR SOFTWARE ENGINEER

Red Hat Israel 

TRIED. TESTED. TRUSTED. 


On Sun, Oct 28, 2018 at 5:33 PM fsoyer  wrote:

> Thank you very much for all this detailed informations, Shirly. The only
> point is that we (must I say "I" ?) never really ask for DWH when
> installing ovirt with hosted engine, maybe it's a lake of documentation on
> my part but I never hear about it in the installation procedure. Where I
> deduce that it is installed with ovirt engine, and if it is a Postgre
> functionality, and if the Postgre database is automatically created in the
> engine VM, so it is installed in the engine VM (Q.E.D. :) )
> The warning you point to me maybe is not enough visible in installation
> procedures for who lives in a country subject to the summer/winter time...
> But even apart of that, I don't remember during the hosted engine
> installation a moment where it ask us for a timezone, you see ? So I wonder
> where or when I could have force UTC time, in fact...
> Can you tell me (and maybe for others installing it in France or similar
> countries) if you see when this DWH and timezone questions can be managed
> in the hosted engine installation process ?
>

You are right that there is no option to set this in the installation time.
But it is based on the system timezone of the machine, which I believe you
can set before installing oVirt.

Since 4.0 DWH is installed by default to provide the historic data for the
Admin portal dashboard.
It might be worth mentioning in the installation docs, but I'm not sure it
should be a reason to choose UTC for the machine only based on this.


>
> This said, if I understand correctly your answers below, can I resume as
> this : don't touch anything now, as the error is automatically repaired
> after this "1 hour gap / overlap" (so I have no more messages after
> 3:00AM). Right ?
>

That is correct.

>
> Many thanks again,
> --
>
> Regards,
>
> *Frank*
>
>
>
> Le Dimanche, Octobre 28, 2018 13:26 CET, Shirly Radco 
> a écrit:
>
>
>
> Please see answers below and let me know if you have any other questions.
>
> Best,
>
> --
>
> SHIRLY RADCO
>
> BI SENIOR SOFTWARE ENGINEER
>
> Red Hat Israel 
> 
> TRIED. TESTED. TRUSTED. 
>
> On Sun, Oct 28, 2018 at 12:55 PM fsoyer  wrote:
>
>> Well, I see that I'm late to give the information :) Thank you to
>> pointing me to this, but I have now some other questions now...
>> How can I see the timezone of the DB ?
>
>
> "If no time zone is stated in the input string, then it is assumed to be
> in the time zone indicated by the system's TimeZone parameter, and is
> converted to UTC using the offset for the timezone zone."
>
>
> https://serverfault.com/questions/554359/postgresql-timezone-does-not-match-system-timezone
>
>
>> When it says "all machines", do you confirm that this is physical
>> machines, not VMs ?
>
>
> I mean the machine DWH is installed on. It can be a VM.
> But I'm not saying we recommend all VMs to be set to UTC.
>
>
>> May I apply the solution given on access.redhat or not, as there is no
>> more messages since 3AM ?
>
>
> No need.
>
>
>> And, last question but not least, can this timezone be changed on the
>> machines (and DB ?) without issue ?
>
>
> It is possible to update it, but its not mandatory.
>
> The 1 hour gap / overlap is expected when moving from summer to winter and
> back when not using UTC and I'm not sure if its even worth updating at this
> point,
> at the risk of ending up with a real bug..
>
>>
>> --
>>
>> Regards,
>>
>> *Frank*
>>
>>
>> Le Dimanche, Octobre 28, 2018 11:40 CET, Shirly Radco 
>> a écrit:
>>
>>
>> Hi,
>>
>> Please see here
>>
>> https://www.ovirt.org/documentation/data-warehouse/Data_Collection_Setup_and_Reports_Installation_Overview/
>>
>> "It is recommended that you set the system time zone for all machines in
>> your Data Warehouse deployment to UTC. This ensures that data collection is
>> not interrupted by variations in your local time zone: for example, a
>> change from summer time to winter time."
>>
>> What timezone is your DB configured to?
>>
>> Best,
>>
>>
>> --
>>
>> SHIRLY RADCO
>>
>> BI SENIOR SOFTWARE ENGINEER
>>
>> Red Hat Israel 
>> 
>> TRIED. TESTED. TRUSTED. 
>>
>> On Sun, Oct 28, 2018 at 12:32 PM fsoyer  wrote:
>>
>>> Hi all,
>>> Maybe it has already been posted, but I think I've discoverd a little
>>> bug. This night I had this messages :
>>>
>>> 28 oct. 2018 03:00:00
>>> ETL service aggregation to hourly tables has encountered an error.
>>> Please consult the service log for more details.
>>> 28 oct. 2018 02:40:27
>>> ETL service sampling has encountered an error. Please consult the
>>> service log for more details.
>>> 28 oct. 2018 02:33:42
>>> ETL service sampling has encountered an error. Please consult the
>>> service log

[ovirt-users] Re: ETL service and winter hour

2018-10-28 Thread fsoyer

Thank you very much for all this detailed informations, Shirly. The only point
is that we (must I say "I" ?) never really ask for DWH when installing ovirt
with hosted engine, maybe it's a lake of documentation on my part but I never
hear about it in the installation procedure. Where I deduce that it is
installed with ovirt engine, and if it is a Postgre functionality, and if the
Postgre database is automatically created in the engine VM, so it is installed
in the engine VM (Q.E.D. :) )
The warning you point to me maybe is not enough visible in installation
procedures for who lives in a country subject to the summer/winter time... But
even apart of that, I don't remember during the hosted engine installation a
moment where it ask us for a timezone, you see ? So I wonder where or when I
could have force UTC time, in fact...
Can you tell me (and maybe for others installing it in France or similar
countries) if you see when this DWH and timezone questions can be managed in
the hosted engine installation process ?

This said, if I understand correctly your answers below, can I resume as this :
don't touch anything now, as the error is automatically repaired after this "1
hour gap / overlap" (so I have no more messages after 3:00AM). Right ?

Many thanks again,
--

Regards,

Frank

Le Dimanche, Octobre 28, 2018 13:26 CET, Shirly Radco a
écrit:
Please see answers below and let me know if you have any other questions.
Best,--
SHIRLY RADCO
BI SENIOR SOFTWARE ENGINEER
Red Hat IsraelTRIED. TESTED. TRUSTED. On Sun, Oct 28, 2018 at 12:55 PM fsoyer
wrote:Well, I see that I'm late to give the information :)
Thank you to pointing me to this, but I have now some other questions now...
How can I see the timezone of the DB ? "If no time zone is stated in the input
string, then it is assumed to be in the time zone indicated by the system's
TimeZone parameter, and is converted to UTC using the offset for the timezone
zone."
https://serverfault.com/questions/554359/postgresql-timezone-does-not-match-system-timezone
When it says "all machines", do you confirm that this is physical machines,
not VMs ? I mean the machine DWH is installed on. It can be a VM.But I'm not
saying we recommend all VMs to be set to UTC. May I apply the solution given on
access.redhat or not, as there is no more messages since 3AM ? No need. And,
last question but not least, can this timezone be changed on the machines (and
DB ?) without issue ? It is possible to update it, but its not mandatory. The 1
hour gap / overlap is expected when moving from summer to winter and back when
not using UTC and I'm not sure if its even worth updating at this point,at the
risk of ending up with a real bug..
--
Regards,

Frank

Le Dimanche, Octobre 28, 2018 11:40 CET, Shirly Radco a
écrit:
Hi, Please see
herehttps://www.ovirt.org/documentation/data-warehouse/Data_Collection_Setup_and_Reports_Installation_Overview/
"It is recommended that you set the system time zone for all machines in your
Data Warehouse deployment to UTC. This ensures that data collection is not
interrupted by variations in your local time zone: for example, a change from
summer time to winter time." What timezone is your DB configured to? Best, --
SHIRLY RADCO
BI SENIOR SOFTWARE ENGINEER
Red Hat IsraelTRIED. TESTED. TRUSTED. On Sun, Oct 28, 2018 at 12:32 PM fsoyer
wrote:Hi all,
Maybe it has already been posted, but I think I've discoverd a little bug. This
night I had this messages :
28 oct. 2018 03:00:00
ETL service aggregation to hourly tables has encountered an error. Please
consult the service log for more details.
28 oct. 2018 02:40:27
ETL service sampling has encountered an error. Please consult the service log
for more details.
28 oct. 2018 02:33:42
ETL service sampling has encountered an error. Please consult the service log
for more details.
28 oct. 2018 02:27:42
ETL service sampling has encountered an error. Please consult the service log
for more details.
28 oct. 2018 02:22:27
ETL service sampling has encountered an error. Please consult the service log
for more details.
28 oct. 2018 02:16:37
ETL service sampling has encountered an error. Please consult the service log
for more details.
28 oct. 2018 02:11:06
ETL service sampling has encountered an error. Please consult the service log
for more details.
28 oct. 2018 02:05:06
ETL service sampling has encountered an error. Please consult the service log
for more details.
28 oct. 2018 02:00:06
ETL service sampling has encountered an error. Please consult the service log
for more details
28 oct. 2018 02:00:00
ETL service aggregation to hourly tables has encountered an error. Please
consult the service log for more details.and, coincidence, here in France we
have change to winter hour at... 2AM :) So regarding this post:
https://access.redhat.com/solutions/3338001
speaking about a time problem, I've supposed that this is related ! No ?
access.redhat says that the cause was not yet

[ovirt-users] Re: ETL service and winter hour

2018-10-28 Thread Shirly Radco

Please see answers below and let me know if you have any other questions.

Best,

--

SHIRLY RADCO

BI SENIOR SOFTWARE ENGINEER

Red Hat Israel 

TRIED. TESTED. TRUSTED. 


On Sun, Oct 28, 2018 at 12:55 PM fsoyer  wrote:

> Well, I see that I'm late to give the information :) Thank you to pointing
> me to this, but I have now some other questions now...
> How can I see the timezone of the DB ?
>

"If no time zone is stated in the input string, then it is assumed to be in
the time zone indicated by the system's TimeZone parameter, and is
converted to UTC using the offset for the timezone zone."
https://serverfault.com/questions/554359/postgresql-timezone-does-not-match-system-timezone


> When it says "all machines", do you confirm that this is physical
> machines, not VMs ?
>

I mean the machine DWH is installed on. It can be a VM.
But I'm not saying we recommend all VMs to be set to UTC.


> May I apply the solution given on access.redhat or not, as there is no
> more messages since 3AM ?
>

No need.

And, last question but not least, can this timezone be changed on the
> machines (and DB ?) without issue ?
>

It is possible to update it, but its not mandatory.

The 1 hour gap / overlap is expected when moving from summer to winter and
back when not using UTC and I'm not sure if its even worth updating at this
point,
at the risk of ending up with a real bug..

>
> --
>
> Regards,
>
> *Frank*
>
>
> Le Dimanche, Octobre 28, 2018 11:40 CET, Shirly Radco 
> a écrit:
>
>
> Hi,
>
> Please see here
>
> https://www.ovirt.org/documentation/data-warehouse/Data_Collection_Setup_and_Reports_Installation_Overview/
>
> "It is recommended that you set the system time zone for all machines in
> your Data Warehouse deployment to UTC. This ensures that data collection is
> not interrupted by variations in your local time zone: for example, a
> change from summer time to winter time."
>
> What timezone is your DB configured to?
>
> Best,
>
>
> --
>
> SHIRLY RADCO
>
> BI SENIOR SOFTWARE ENGINEER
>
> Red Hat Israel 
> 
> TRIED. TESTED. TRUSTED. 
>
> On Sun, Oct 28, 2018 at 12:32 PM fsoyer  wrote:
>
>> Hi all,
>> Maybe it has already been posted, but I think I've discoverd a little
>> bug. This night I had this messages :
>>
>> 28 oct. 2018 03:00:00
>> ETL service aggregation to hourly tables has encountered an error. Please
>> consult the service log for more details.
>> 28 oct. 2018 02:40:27
>> ETL service sampling has encountered an error. Please consult the service
>> log for more details.
>> 28 oct. 2018 02:33:42
>> ETL service sampling has encountered an error. Please consult the service
>> log for more details.
>> 28 oct. 2018 02:27:42
>> ETL service sampling has encountered an error. Please consult the service
>> log for more details.
>> 28 oct. 2018 02:22:27
>> ETL service sampling has encountered an error. Please consult the service
>> log for more details.
>> 28 oct. 2018 02:16:37
>> ETL service sampling has encountered an error. Please consult the service
>> log for more details.
>> 28 oct. 2018 02:11:06
>> ETL service sampling has encountered an error. Please consult the service
>> log for more details.
>> 28 oct. 2018 02:05:06
>> ETL service sampling has encountered an error. Please consult the service
>> log for more details.
>> 28 oct. 2018 02:00:06
>> ETL service sampling has encountered an error. Please consult the service
>> log for more details
>> 28 oct. 2018 02:00:00
>> ETL service aggregation to hourly tables has encountered an error. Please
>> consult the service log for more details.
>>
>> and, coincidence, here in France we have change to winter hour at... 2AM
>> :) So regarding this post:
>> https://access.redhat.com/solutions/3338001
>> speaking about a time problem, I've supposed that this is related ! No ?
>> access.redhat says that the cause was not yet determined, but maybe it can
>> be interesting to propose this cause ? But the bug is actually closed.
>>
>> Question : does this repair all alone (as there is no more messages after
>> 3AM) or may I applied the solution with postgres updates (I must say that
>> I'm not very enthousiast for that...) ?
>>
>> Regards,
>>
>> --
>>
>> *Frank*
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/GNGAQKTA5PDJUYMTFJABDLZA27FHUY7O/
>
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:

[ovirt-users] Re: ETL service and winter hour

2018-10-28 Thread fsoyer

Well, I see that I'm late to give the information :) Thank you to pointing me
to this, but I have now some other questions now...
How can I see the timezone of the DB ?
When it says "all machines", do you confirm that this is physical machines, not
VMs ?
May I apply the solution given on access.redhat or not, as there is no more
messages since 3AM ?
And, last question but not least, can this timezone be changed on the machines
(and DB ?) without issue ?

Regards,

Frank

Question : does this repair all alone (as there is no more messages after 3AM)
or may I applied the solution with postgres updates (I must say that I'm not
very enthousiast for that...) ?

Regards,

--
Frank ___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/GNGAQKTA5PDJUYMTFJABDLZA27FHUY7O/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/D46VJJ5LHQP4JTLMWL6L2QBMPL2SCU3W/

[ovirt-users] Re: ETL service and winter hour

2018-10-28 Thread Shirly Radco

Hi,

Please see here
https://www.ovirt.org/documentation/data-warehouse/Data_Collection_Setup_and_Reports_Installation_Overview/

"It is recommended that you set the system time zone for all machines in
your Data Warehouse deployment to UTC. This ensures that data collection is
not interrupted by variations in your local time zone: for example, a
change from summer time to winter time."

What timezone is your DB configured to?

Best,

--

SHIRLY RADCO

BI SENIOR SOFTWARE ENGINEER

Red Hat Israel 

TRIED. TESTED. TRUSTED. 


On Sun, Oct 28, 2018 at 12:32 PM fsoyer  wrote:

> Hi all,
> Maybe it has already been posted, but I think I've discoverd a little bug.
> This night I had this messages :
>
> 28 oct. 2018 03:00:00
> ETL service aggregation to hourly tables has encountered an error. Please
> consult the service log for more details.
> 28 oct. 2018 02:40:27
> ETL service sampling has encountered an error. Please consult the service
> log for more details.
> 28 oct. 2018 02:33:42
> ETL service sampling has encountered an error. Please consult the service
> log for more details.
> 28 oct. 2018 02:27:42
> ETL service sampling has encountered an error. Please consult the service
> log for more details.
> 28 oct. 2018 02:22:27
> ETL service sampling has encountered an error. Please consult the service
> log for more details.
> 28 oct. 2018 02:16:37
> ETL service sampling has encountered an error. Please consult the service
> log for more details.
> 28 oct. 2018 02:11:06
> ETL service sampling has encountered an error. Please consult the service
> log for more details.
> 28 oct. 2018 02:05:06
> ETL service sampling has encountered an error. Please consult the service
> log for more details.
> 28 oct. 2018 02:00:06
> ETL service sampling has encountered an error. Please consult the service
> log for more details
> 28 oct. 2018 02:00:00
> ETL service aggregation to hourly tables has encountered an error. Please
> consult the service log for more details.
>
> and, coincidence, here in France we have change to winter hour at... 2AM
> :) So regarding this post:
> https://access.redhat.com/solutions/3338001
> speaking about a time problem, I've supposed that this is related ! No ?
> access.redhat says that the cause was not yet determined, but maybe it can
> be interesting to propose this cause ? But the bug is actually closed.
>
> Question : does this repair all alone (as there is no more messages after
> 3AM) or may I applied the solution with postgres updates (I must say that
> I'm not very enthousiast for that...) ?
>
> Regards,
>
> --
>
> *Frank*
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/GNGAQKTA5PDJUYMTFJABDLZA27FHUY7O/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/TR43YODT2XLK5NUVPMFRZ7DQBLHMUUVJ/

[ovirt-users] Re: ETL service and winter hour

[ovirt-users] Re: ETL service and winter hour

[ovirt-users] Re: ETL service and winter hour

[ovirt-users] Re: ETL service and winter hour

[ovirt-users] Re: ETL service and winter hour

5 matches

Site Navigation

Mail list logo

Footer information