Rename 'replicas' to 'current' in KubeadmControlPlane, MachineDeployments and MachineSet kubectl output

[killianmuldoon]

Cluster API should use "current" instead of "replicas" in CLI output to express the number of instances of an object in a scalable resource.
With #6164 we're adding desired to all three of the above objects, showing the number of replicas. In order to be consistent with the Kubernetes output for Daemonsets we should rename the 'replicas' column to 'current'.

In detail:
As of release 1.1 the outputs for KubeadmControlPlane, MachineDeployments and MachineSets are :

KubeadmControlPlane

NAME             CLUSTER    INITIALIZED   API SERVER AVAILABLE   REPLICAS   READY   UPDATED   UNAVAILABLE   AGE   VERSION
cloister-9l2n7   cloister   true          true                   3          3       3         0             24h   v1.21.2

MachineDeployments:

NAME                           CLUSTER    REPLICAS   READY   UPDATED   UNAVAILABLE   PHASE     AGE   VERSION
cloister-linux-workers-jd4qq   cloister   3          3       3         0             Running   24h   v1.21.2

MachineSets:

NAME                                              CLUSTER      REPLICAS   READY   AVAILABLE   AGE   VERSION
my-cluster-default-worker-topo-bjn28-66767779f7   my-cluster   1                              21h   v1.22.0

In a future release the outputs for KubeadmControlPlane, MachineDeployments and MachineSets this change (combined with the change from #6164) result in:

KubeadmControlPlane

NAME             CLUSTER    INITIALIZED   API SERVER AVAILABLE   CURRENT DESIRED   READY   UPDATED   UNAVAILABLE   AGE   VERSION
cloister-9l2n7   cloister   true          true                   3          3       3         0                   3        24h   v1.21.2

MachineDeployments:

NAME                           CLUSTER      CURRENT  DESIRED READY UPDATED   UNAVAILABLE   PHASE     AGE   VERSION
cloister-linux-workers-jd4qq   cloister     3       3           3     3     0          Running   24h   v1.21.2

MachineSets:

NAME                                              CLUSTER    CURRENT  DESIRED READY   AVAILABLE   AGE   VERSION
my-cluster-default-worker-topo-bjn28-66767779f7   my-cluster   1         1                         21h   v1.22.0

/area api

[enxebre]

My +1. See #5304 (comment) for prior discussion.

Let's make sure any convention we come up with https://github.com/kubernetes-sigs/cluster-api/blob/main/CONTRIBUTING.md#crd-additionalprintercolumns

[fabriziopandini]

/milestone Next
Given this should be implemented when we rev the next API version

[sbueringer]

Q: If we want to change it with v1.3 should we add it now to our migration doc as deprecation? (I'm not sure where we should put that info)

[killianmuldoon]

Q: If we want to change it with v1.3 should we add it now to our migration doc as deprecation? (I'm not sure where we should put that info)

Good idea. I think adding this to the migration doc should be enough of a warning to end-users. I think this is a pretty low impact change (Unless someone is using awk to manage clusters 😄 )

[sbueringer]

I would be fine with adding it there, given that we don't really have a better place imho (there is that one other page for clusterctl (https://cluster-api.sigs.k8s.io/tasks/upgrading-cluster-api-versions.html?highlight=upgrade#when-to-upgrade) but I don't think it fits there)

[fabriziopandini]

Based on what we did in the past, breaking changes to columns have been implemented only when revving a new API version. I'm not sure we are going to rev a new API version in v1.3 and If this is not going to happen the deprecation notice will get lost ...

[killianmuldoon]

The two API issues (I still have to create the second one) will work as enough documentation so we can add the deprecation notice whenever there's a new API version. No need to add anything to the book. Is my understanding right?

[Ab-hishek]

Hi @killianmuldoon! If possible, can I work on this whenever we decide to start working on this(i.e next release)?

[killianmuldoon]

@Ab-hishek Sure - we'll probably activate a bunch of these changes just before the next release cycle. I'll ping here when we decide to unblock this.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale