Determine final list of fields for 0.2 Status

[jberkus]

Per #136 we need to decide the final list of fields for cluster status. Here's the current proposal from @ballista01 :

status:
  observedGeneration: 5                    # NEW: Top-level field indicating the latest .metadata.generation processed by the controller
  currentReplicas: 3                       # Unchanged: Matches the StatefulSet replica count
  currentVersion: 3.6.0-rc.3               # Unchanged: Represents the running etcd version of the cluster
  leaderId: 975eab669fe7b560               # Unchanged: Leader member ID for status observability
  memberCount: 3                           # Unchanged: Total number of etcd members
  readyReplicas: 3

  # lastDefragTime could be optionally added if controller manages defragmentation
  # lastDefragTime: "2025-07-20T12:00:00Z"   # OPTIONAL: Cluster-level defragmentation completion time; not included in this PR

  members:
    - id: 22f4b6fa7639917a
      name: test-cluster-2
      version: 3.6.0-rc.3
      isHealthy: true
      isLearner: false                     # NEW: Added to support learner promotion logic and troubleshooting
      # REMOVED: dbSize/dbSizeInUse → considered too dynamic; suggested to be exposed via /metrics
      # clientURL and peerURL omitted here for minimal diagnostic view, can be re-added under a feature gate

    - id: 52117ab448fed65d
      name: test-cluster-1
      version: 3.6.0-rc.3
      isHealthy: true
      isLearner: false

    - id: 4f8c9e671cbd2233
      name: test-cluster-0
      version: 3.6.0-rc.3
      isHealthy: true
      isLearner: false

  conditions:
    - type: Available
      status: "True"
      reason: ClusterReady
      message: Cluster is fully available and healthy
      observedGeneration: 5
      lastTransitionTime: "2025-07-02T18:52:06Z"
      # Unchanged: Matches K8s convention for status.conditions

    - type: Progressing
      status: "False"
      reason: ReconcileSuccess
      message: Cluster reconciled to desired state
      observedGeneration: 5
      lastTransitionTime: "2025-07-02T18:52:06Z"
      # Unchanged: Indicates that spec and observed state are aligned

    - type: Degraded
      status: "False"
      reason: ClusterReady
      message: Cluster is healthy
      observedGeneration: 5
      lastTransitionTime: "2025-07-02T18:50:57Z"
      # Unchanged: Used to signal partial failures if any member is unhealthy

  # Note: dbSize and dbSizeInUse fields are REMOVED in this revision.
  # Rationale: These are volatile metrics not suitable for status fields;
  # better exposed via Prometheus-compatible /metrics endpoint for observability.

Please discuss below!

[jberkus]

Question 1:

These three fields seem confusingly similar for the user:

currentReplicas: 3
readyReplicas: 3
memberCount: 3

Do we actually need both ReadyReplicas and MemberCount? Under what circumstances would these two numbers be different?

[jberkus]

Aside from that one question, I'm pretty happy with the list of fields above; it seems like a good starting point.

[hakman]

Maybe also add isLeader?

[ivanvc]

I agree with the points above, @jberkus (consolidating readyReplicas and memberCount SGTM) and @hakman. This is looking good for a first version.

[ahrtr]

Overall looks good for now, with a couple of minor comments:

• leaderId or IsLeader can be dynamic, but the controller may not get notified. It is unlikely in a stable environment. So I'm to add leaderId for now. (Note: we don't have a isLeader field/attribute by default in etcd; it's just a derived attribute in etcdctl by comparing leaderId with each member ID)
• suggest to keep both currentReplicas and memberCount for now. Usually they should match, if not then means the cluster isn't probably healthy or in progress of reconciliation/converge.

[ivanvc]

We discussed this issue at the community meeting. We agreed that it’s better to have more status fields, as the user may not be able to use the etcd API.