Add MachineNodeHealthyCondition to Machine’s Ready condition

[fabriziopandini]

User Story

As a user, I would like to get a summary of machine status by looking at the machine's ready condition

Detailed Description

#3670 & #3890 introduced the NodeHealthy conditions on machines, however
as per discussion #3670 (comment) we decided to not include this condition in the machine's ready condition and to open an issue outlining the contract changes for v1alpha4.

The impact of this change, if implemented, is that a machine will not get ready until a CNI is installed in the cluster.

Is there any objection to implementing this in v1alpha4? Should we consider backporting?

Anything else you would like to add:

From the conditions proposal:

• A Ready condition SHOULD be provided at object level to represent the overall operational state of the component (and IMO for a machine, this includes having the node with a CNI)
• The Ready condition MUST be based on the summary of more detailed conditions existing on the same object
• An object SHOULD NEVER be in status Ready=True if one of the object's conditions are false or if one of the object dependents is in status Ready=False.

/kind feature

[fabriziopandini]

/milestone v0.4.0
/area machine

[srm09]

IMO adding CNI to cluster sounds like a necessary step to make the cluster usable. And if we always want the cluster to have some CNI solution installed, then making sure that the Machine's Ready condition reflects that prerequisite only solidifies that contract.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[fabriziopandini]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[fabriziopandini]

@vincepri @CecileRobertMichon opinions about including this in v1alpha4?

[CecileRobertMichon]

This shouldn't be a breaking change correct? I'm +1 on getting this in as soon as we can but I don't think it's blocking for v0.4.0

[fabriziopandini]

Given that we are going to change the semantic of the Ready condition for the machines, from a certain PoV this could be considered breaking (this was at least what we assumed when we decided to not include the the condition in the summary during v1alpha3)