Aria Automation 8.x Deployments Display Incorrect 'Created On' Timestamp Due to NTP Drift
search cancel

Aria Automation 8.x Deployments Display Incorrect 'Created On' Timestamp Due to NTP Drift

book

Article ID: 435392

calendar_today

Updated On:

Products

VCF Operations/Automation (formerly VMware Aria Suite)

Issue/Introduction

In Aria Automation development environments, new deployments are displaying an incorrect "Created On" timestamp. Specifically, the User Interface (UI) is stamping the creation event exactly 15 minutes prior to the actual time the deployment was triggered, even while the provisioning process is still actively running.

This discrepancy was verified through live testing and backend command-line validation. Triggering a new test deployment resulted in the UI immediately reporting the event as being created "15 minutes ago." Executing the vracli service status command via SSH confirmed that a time synchronization discrepancy was impacting the internal Kubernetes (K8s) services, specifically the Event Broker Service (EBS) pods.

Environment

VMware Aria Automation 8.x

Cause

The underlying cause of the incorrect timestamps is a Time Skew (NTP Drift) across the internal Kubernetes Pods.

Aria Automation relies on a Kubernetes service mesh to handle all backend operations. The Event Broker Service (EBS) is the component responsible for processing, stamping, and routing lifecycle events (such as the creation of a deployment). Timestamps are generated by the backend database and event broker at the exact moment the API request is received, not by the local browser.

If the underlying virtual appliance experiences a clock drift and loses synchronization with its NTP source—which can occasionally happen if the underlying ESXi host is under heavy load or if communication with the designated NTP server is temporarily interrupted—the internal K8s pods inherit this skewed time. The database then records the drifted timestamp, which the UI displays to the user. A drift of 15 minutes is significant enough to cause visible UI discrepancies and can eventually lead to authentication failures (like expired SAML tokens) if left uncorrected.

Resolution

To resolve the time skew and resynchronize the backend services, perform a graceful power cycle of the appliance. This forces the appliance OS and its embedded Kubernetes cluster to re-initialize and pull the correct, current time from the configured NTP servers.

  1. Graceful Shutdown: Perform a graceful Power OFF of the Aria Automation appliance from the vSphere Client (or Aria Suite Lifecycle Manager) to safely stop the embedded Kubernetes cluster and database.

  2. Power ON: Initiate a Power ON of the appliance to force a fresh boot sequence. This ensures the EBS pods spin up with the corrected system clock.

  3. Verification: Log into the Aria Automation UI and trigger a new test deployment. Verify that the 'Created On' timestamp accurately displays the correct time (e.g., "a few seconds ago"), confirming the system time has been corrected.