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
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?
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)
engine=#
So I should use the db statement too, correct?
Any need to restart engine service after or before that?