Open rfranzke opened 4 years ago
Dupe of https://github.com/gardener/machine-controller-manager/issues/476 . Closing in favor of the other.
/close
status
field. These appear to be different issues, and hence are not duplicate.Reopening this.
@rfranzke currently the .status.failedMachines
field in the machine deployment is reset only when all the machines controlled by the machine deployment are healthy (running and have joined the cluster). Until then it contains the latest set of failed machine operations.
Refer:
Otherwise for some of the fail scenarios it can get difficult to catch the failed operations and reasons because of very quick create and delete operations. As a quick experiment, return a random failure here: https://github.com/gardener/machine-controller-manager/blob/e21b931ce25cc57b4267fce80e69839179854c20/pkg/controller/machine_bootstrap_token.go#L56
In the observation reported in the issue, once the machine joins and the machine deployment becomes healthy (all machines join the cluster), the failedMachines
field would have been cleared.
Please let me know if there is any issue created because of current behaviour. We can take corrective measures accordingly. Thanks.
I still think this should be improved, i.e., the status
should reflect the actual state of the world (which it currently does not - the machine is in the processing of joining the cluster and no longer failed). It's not too critical/important in the sense that we need it tomorrow, but it would improve user and ops experience/productivity to not show false negative status information.
What happened: MCM does not update the
.status.failedMachine
of theMachineDeployment
after the.status.lastOperation
of theMachine
changes (e.g., fromFailed
->Processing
(e.g., after the credentials have been fixed)):(compare the timestamps)
What you expected to happen: The
.status.failedMachines
is properly updated when.status.lastOperation
ofMachine
objects are changed.