On Fri, Sep 24, 2021 at 11:05 AM Michal Skrivanek < michal.skrivanek@redhat.com> wrote:
On 24. 9. 2021, at 9:43, Gianluca Cecchi <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
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? Thanks Gianluca