Open minglumlu opened 1 month ago
All modified and coverable lines are covered by tests :white_check_mark:
Robustness against clock changes is desirable but I question that it can be expected for large clock changes. That's like designing for power outages - it needs to be an explicit goal right from the start.
Robustness against clock changes is desirable but I question that it can be expected for large clock changes. That's like designing for power outages - it needs to be an explicit goal right from the start.
Yes. The robustness is the major concern of this change. The automation testing relies on the large clock changes heavily, although there may not be common cases in production. But I think improving the robustness in xapi would resolve the potential issues in either case.
Rebased with the master branch to resolve the conflict.
Additionally, Host_metrics.last_updated is only set when the object is
created. It's useless in check_host_liveness at all.
I guess it was updated periodically with some time interval in some old version xapi which did not tickle_heartbeat
yet, so it was considered as the heartbeat for the new added heartbeat mechanism, add then it was removed in the new heartbeat version.
As all hosts will tickle_heartbeat
now, it is useless now.
Prior to this commit, the xapi on the coordinator host records the 'Unix.gettimeofday' as the timestamps of the heartbeat with other pool supporter hosts. When the system clock is updated with a huge jump forward, the timestamps would be far back into the past. This would cause the xapi assumes that the hosts are offline as long time no heartbeats.
In this commit, the timestamps are changed to get from a monotonic clock. In this way, the system clock changes will not impact the heartbeats' timestamps any more.
Additionally, Host_metrics.last_updated is only set when the object is created. It's useless in check_host_liveness at all.