I'm concerned with two (different) time keeping issues: 1. Timezone - we need to ensure all VMs have the same timezone (At least by default). Best option would be to edit the deploy scripts and set the timezone to the host timezone? should be fairly easy to add @TIMEZONE@ variable to the deploy script in a similar manner to what we do today in the domain XML. It'll be in a command like 'ln -s /usr/share/zoneinfo/@TIMEZONE@ /etc/localtime 2. Time drifting - I have a feeling there's a time drift when we do all the freeze-thaw and snap/revert... Perhaps we should run 'ntpdate' after such actions?
On 03/14 11:46, Yaniv Kaul wrote:
I'm concerned with two (different) time keeping issues: 1. Timezone - we need to ensure all VMs have the same timezone (At least by default). Best option would be to edit the deploy scripts and set the timezone to the host timezone? should be fairly easy to add @TIMEZONE@ variable to the deploy script in a similar manner to what we do today in the domain XML. It'll be in a command like 'ln -s /usr/share/zoneinfo/@TIMEZONE@ /etc/localtime
For this there's already an issue: https://github.com/lago-project/lago/issues/2
2. Time drifting - I have a feeling there's a time drift when we do all the freeze-thaw and snap/revert... Perhaps we should run 'ntpdate' after such actions?
Yes, that might be happening, not sure though if we should get bound to ntpdate in specific or we should try to do something more generic (have to investigate if there's anything generic :/)
_______________________________________________ lago-devel mailing list lago-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/lago-devel
-- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro@redhat.com IRC: dcaro|dcaroest@{freenode|oftc|redhat} Web: www.redhat.com RHT Global #: 82-62605
On Mon, Mar 14, 2016 at 12:01 PM, David Caro <dcaro@redhat.com> wrote:
I'm concerned with two (different) time keeping issues: 1. Timezone - we need to ensure all VMs have the same timezone (At least by default). Best option would be to edit the deploy scripts and set the timezone to
On 03/14 11:46, Yaniv Kaul wrote: the
host timezone? should be fairly easy to add @TIMEZONE@ variable to the deploy script in a similar manner to what we do today in the domain XML. It'll be in a command like 'ln -s /usr/share/zoneinfo/@TIMEZONE@ /etc/localtime
For this there's already an issue:
https://github.com/lago-project/lago/issues/2
2. Time drifting - I have a feeling there's a time drift when we do all
the
freeze-thaw and snap/revert... Perhaps we should run 'ntpdate' after such actions?
Yes, that might be happening, not sure though if we should get bound to ntpdate in specific or we should try to do something more generic (have to investigate if there's anything generic :/)
Installed ntpdate and ran it on each host before running the oVirt tests. The result was that at some point the engine decide the internal user account has expired and locked it down after few attempts, resulting in complete test failure :( I guess we need to track time more closely, or I've messed something up (leaning towards the latter). Y.
_______________________________________________ lago-devel mailing list lago-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/lago-devel
-- David Caro
Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605 Email: dcaro@redhat.com IRC: dcaro|dcaroest@{freenode|oftc|redhat} Web: www.redhat.com RHT Global #: 82-62605
participants (2)
-
David Caro -
Yaniv Kaul