kubernetes-sigs / kubernetes-sigs/cluster-api

Improve UX of MachineHealthCheckStatus fields

Open
#5,291 15 comments 0 reactions 0 assignees View on GitHub
help wanted kind/api-change kind/feature priority/important-longterm triage/accepted
Dominant language
Go
Stars
4.3k
Forks
1.6k
Avg merge
1d 3h
Merged PRs (30d)
113

Description

**Description**

MHC currently has the following columns: `MaxUnhealthy`, `ExpectedMachines`, `CurrentHealthy`. Based on this columns it's a bit hard to grasp what's going on.

The fields have the following semantic (or at least godoc):
* .spec.maxUnhealthy: Any further remediation is only allowed if at most "MaxUnhealthy" machines selected by "selector" are not healthy.
* .status.expectedMachines: total number of machines counted by this machine health check
* .status.currentHealthy: total number of healthy machines counted by this machine health check

A few examples:
* field name: unhealthy vs healthy (would be easier to have either healthy or unhealthy twice, if possible)
* expectedMachines: what does expected mean? according to the godoc it's (probably) the number of machines which match the selector
* currentHealthy: not sure if we need current if it's part of the status (as far as I can see in our other types we're not using the current prefix)

/kind feature

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the godoc and semantics for .spec.maxUnhealthy, .status.expectedMachines, and .status.currentHealthy. The issue does not identify files or tests, so first determine where these MachineHealthCheckStatus fields are defined and used. Done means an agreed naming and semantic change that makes the status easier to understand.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
api
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.