Surface the most recent deployment time and most recent restart time for each deployed application, so the Fabric UI (and other consumers) can display them without log scraping.
Motivation
Customer-driven feature ask: surface deploy and restart timestamps per application in the Fabric UI without log scraping.
Design considerations — needs discussion before implementation
Harper's existing model treats the root configuration file as the primary system of record for deployments (especially when an application is deployed by reference), and backup configurations form the historical record of past deployments and configuration changes that affect deployments. There are two broad directions:
- Double down on configuration as the system of record — make deployment-affecting configuration changes more descriptive (a documented "what changed and when" for each backup config), and derive
deployedAt from the latest deployment-relevant config-change timestamp. Restart timestamps would be a separate, lighter mechanism (process- or component-local).
- Track deployment/restart timestamps as first-class state alongside the config-as-record model — explicit
deployedAt / restartedAt per application, persisted (deployedAt) or refreshed-at-startup (restartedAt), exposed via the existing status/describe endpoint.
The first approach keeps the configuration history coherent and avoids a parallel source of truth; the second is simpler to consume but risks drifting from config history. Decision needs product/engineering alignment before this is marked Ready.
Open questions
- "Deployment" granularity: install only, or every redeploy / deployment-affecting config change?
- Per-component vs. per-application timestamps?
- Cluster behavior: per-node (restart is local) vs. aggregated?
Acceptance criteria (regardless of approach)
- Deploy and restart timestamps are queryable per application via the standard component/operations API, without log scraping.
- Persistence semantics defined (
deployedAt survives restart; restartedAt updates on restart).
Tracked in Jira: CORE-3076
🤖 Filed by Claude on behalf of Kris.
Surface the most recent deployment time and most recent restart time for each deployed application, so the Fabric UI (and other consumers) can display them without log scraping.
Motivation
Customer-driven feature ask: surface deploy and restart timestamps per application in the Fabric UI without log scraping.
Design considerations — needs discussion before implementation
Harper's existing model treats the root configuration file as the primary system of record for deployments (especially when an application is deployed by reference), and backup configurations form the historical record of past deployments and configuration changes that affect deployments. There are two broad directions:
deployedAtfrom the latest deployment-relevant config-change timestamp. Restart timestamps would be a separate, lighter mechanism (process- or component-local).deployedAt/restartedAtper application, persisted (deployedAt) or refreshed-at-startup (restartedAt), exposed via the existing status/describe endpoint.The first approach keeps the configuration history coherent and avoids a parallel source of truth; the second is simpler to consume but risks drifting from config history. Decision needs product/engineering alignment before this is marked Ready.
Open questions
Acceptance criteria (regardless of approach)
deployedAtsurvives restart;restartedAtupdates on restart).Tracked in Jira: CORE-3076
🤖 Filed by Claude on behalf of Kris.