tagging with upcomingSprint to re-evaluate priority.

We have implemented defaulting for the ProviderSpec this sprint. Will take a look at this and the impact of the change next sprint

I want to make sure that everything is stable from the webhook side before we start digging into this. There's been a few teething issues to look into so dropping this to next sprint

Didn't manage to look into this during the last sprint, should have more time to get to this after feature freeze

Need consensus from the team that this is the right way to go, will try to push this through next sprint

VERIFIED on - 4.6.0-0.nightly-2020-08-31-220837

Steps :
1.Created a machineset with replicas as below- 
.
.
.
spec:
  replicas:
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: wduan0902b-9kmnz
      machine.openshift.io/cluster-api-machineset: wduan0902b-9kmnz-worker-new
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: wduan0902b-9kmnz
        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: wduan0902b-9kmnz-worker-new
.
..
.
2. Machineset created successfully 
[miyadav@miyadav vsphere]$ oc create -f vsp_ms.yaml --config vsp 
machineset.machine.openshift.io/wduan0902b-9kmnz-worker-new created

3.Machines in machineset scaled successfully
[miyadav@miyadav vsphere]$ oc get machineset --config vsp
NAME                          DESIRED   CURRENT   READY   AVAILABLE   AGE
wduan0902b-9kmnz-worker       2         2         2       2           5h26m
wduan0902b-9kmnz-worker-new   1         1         1       1           7m19s
[miyadav@miyadav vsphere]$ oc get machines -o wide --config vsp
NAME                                PHASE     TYPE   REGION   ZONE   AGE     NODE                                PROVIDERID                                       STATE
wduan0902b-9kmnz-master-0           Running                          5h26m   wduan0902b-9kmnz-master-0           vsphere://422b9e4d-ab7a-8d15-4ba9-617925baf5e8   poweredOn
wduan0902b-9kmnz-master-1           Running                          5h26m   wduan0902b-9kmnz-master-1           vsphere://422b65da-7976-acd3-21fa-b64e07a408f0   poweredOn
wduan0902b-9kmnz-master-2           Running                          5h26m   wduan0902b-9kmnz-master-2           vsphere://422b0cf9-f6fb-4aee-3da8-68a8d135f869   poweredOn
wduan0902b-9kmnz-worker-7fd7v       Running                          5h16m   wduan0902b-9kmnz-worker-7fd7v       vsphere://422b5f20-6e50-48f4-4ade-4e6d1529a336   poweredOn
wduan0902b-9kmnz-worker-new-8jhld   Running                          7m40s   wduan0902b-9kmnz-worker-new-8jhld   vsphere://422be203-fc3d-71c9-44ed-e7f921cfb85c   poweredOn
wduan0902b-9kmnz-worker-wwv98       Running                          5h16m   wduan0902b-9kmnz-worker-wwv98       vsphere://422ba102-80ee-2319-b00d-c34f0a9293f0   poweredOn
[miyadav@miyadav vsphere]$ 

All results as expected , moved to VERIFIED.

Additional info:
We cannot use "nil" or  nil in replica field  as it is invalid and will through error :
admission webhook "default.machineset.machine.openshift.io" denied the request: v1beta1.MachineSet.Spec: v1beta1.MachineSetSpec.Replicas: readUint32: unexpected character: �, error found in #10 byte of ...|eplicas":"nil","sele|..., bigger context ...|64f4-44e7-9b3f-b32825c9f54e"},"spec":{"replicas":"nil","selector":{"matchLabels":{"machine.openshift|...

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (OpenShift Container Platform 4.6 GA Images), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:4196