On 24. 9. 2021, at 11:28, Gianluca Cecchi
<gianluca.cecchi(a)gmail.com> wrote:
On Fri, Sep 24, 2021 at 11:05 AM Michal Skrivanek <michal.skrivanek(a)redhat.com
<mailto:michal.skrivanek@redhat.com>> wrote:
> On 24. 9. 2021, at 9:43, Gianluca Cecchi <gianluca.cecchi(a)gmail.com
<mailto:gianluca.cecchi@gmail.com>> wrote:
>
> BTW: there are two things that are not so clear to me:
> 1. Is this only impacting SHE environments or is it a general problem also with
external standalone engine ones?
it’s affecting all VMs, in standalone envs engine is not a VM
Of course... I meant if I have standalone external engine that manages VM1 and VM2 and I
update from 4.4.7 to 4.4.8-5, will VM1 and VM2 impacted?
I presume yes from your answer
yes
> 2. Is it correct to say that if I already upgraded in the past to 4.4.7 and at that
time I updated my cluster level from 4.5 to 4.6 (both in case of SHE and external engine),
then I shouldn't have this kind of problems if then I updated to the impacted 4.4.8-5
version? And then I can go and continue updating to 4.4.8-6 without any risk/problems?
the cluster level update problem is just a side effect of the time zone missing. You will
see problems in other flows, or next time you upgrade to 4.7 if we ever have one.
So I don't understand if I need to rollback or if I can anyway update to 4.4.8-6 and
eventually modify from database.
By the way in my env all my VMs in 4.4.7 had timezone set to the default value
"Etc/GMT". Does this imply no impact at all?
you should set it to something.
It sets it to default on its own whenever that VMs get "touched" in some way,
and since Etc/GMT is the default you won't really notice much, but there might be
places where it may cause issues (dunno, OVF export maybe)
Eg on another environment I see that after updating from 4.4.7 to
4.4.8-5 and then 4.4.8-6, in Web Admin GUI if I select a VM, in general subtab I have for
2 of them
Hardware Clock Time Offset: Etc/GMT
for all the other ones there isn't the "Hardware Clock Time Offset"
item...
Fot these VMs under edit virtual machine -> system -> Hardware Clock Time Offset I
see they have the value
default:(GMTZ) Greenwich Standard Time
and from database point of view:
engine=# select time_zone,count(*) from vm_static group by time_zone;
time_zone | count
-----------+-------
| 18
Etc/GMT | 2
(2 rows)
engine=#
engine=# select vm_name from vm_static where time_zone='Etc/GMT';
vm_name
-----------
testcl1
c76client
(2 rows)
yeah, so those are vms which you have probably edited and saved in the meantime.
engine=#
So I should use the db statement too, correct?
Hard to say, to minimize changes HE might be enough as long as you do not see any other
issues anywhere else and you would use the default anyway.
Any need to restart engine service after or before that?
Not really needed.
Thanks,
michal
Thanks
Gianluca