History of a cluster

[cornelius-keller]

History of a cluster

User story

As a cluster admin, I want to see what happened to a cluster over time, so that
I can understand how/why behaviour might have changed.

Rationale

We constantly roll out changes that potentially affect a customer's applications.
In addition, users/admins can issue events like scaling, key pair creation and
more which has an impact on the system.

With this story, we want to give customers/admins simple access to a log of
all events that could effect the behaviour of their installation or guest clusters.

Background

Part of the data we want to make accessible here is the audit log, but it's possible
that we want to extend this by entries form other sources.

Open questions

Possible side effects

• Transparency of user actions, which is regulated under german labour law or
  within certain companies (worker councils).

Dependencies/prerequisites

[teemow]

@puja108 @marians same as #13. This is still interesting for fleet management.

But I guess we have mulitple sources for the "history" of a cluster:

• Kubernetes events from CAPI controllers
• GitOps history
• Loki logs

[puja108]

Agree, these are things we should pick up again thinking about fleet management interfaces, but that will also slightly depend on our o11y stack going forward, so will need some syncing between Honeybadger and Atlas.

[marians]

I'm putting these three related issues on Honeybadger's board for Backstage.

• Status / health of workload clusters #13
• Transparency Regarding Cluster State #75
• History of a cluster #57