Rename field to InfrastructureMachineSelector

docs/proposals/20220209-machinepool-machines.md

@@ -81,26 +81,25 @@ As another example, currently each MachinePool infrastructure provider must impl
 - Implement Cluster Autoscaler MachinePool integration (a separate task, although we have a working POC)
 - Move the MachinePools implementation into a `exp/machinepools` package. The current code location makes its separation from `exp/addons` unclear and this would be an improvement.
 - Improve bootstrap token handling for MachinePools. It would be preferable to have a single, short-lived token for each Machine instead of the current shared, long-lived token.
-- Remove the `ProviderIDList` field from MachinePools. While the initial proposal using an `InfrastructureRefList` made that field arguably unnecessary, it is still used by cluster-autoscaler and perhaps in other integrations.
 ## Proposal
 
-To create MachinePool Machines, a MachinePool in CAPI needs information about the instances or replicas associated with the provider's implementation of the MachinePool. This information is attached to the provider's MachinePool infrastructure resource as new, optional status fields `InfrastructureSelector`. This field may be populated by the infrastructure provider.
+To create MachinePool Machines, a MachinePool in CAPI needs information about the instances or replicas associated with the provider's implementation of the MachinePool. This information is attached to the provider's MachinePool infrastructure resource as new, optional status fields `InfrastructureMachineSelector`. This field may be populated by the infrastructure provider.
 
 ```golang
 // FooMachinePoolStatus defines the observed state of FooMachinePool.
 type FooMachinePoolStatus struct {
-	// InfrastructureSelector is a label query over FooMachinePoolMachines.
+	// InfrastructureMachineSelector is a label query over FooMachinePoolMachines.
 	// More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors
 	// +optional
-	InfrastructureSelector metav1.LabelSelector `json:"infrastructureSelector,omitempty"`
+	InfrastructureMachineSelector metav1.LabelSelector `json:"infrastructureMachineSelector,omitempty"`
 }
 ```
 
 If this field is populated, CAPI's MachinePool controller will query for the provider-specific infrastructure resources. That query uses the Selector field, the API version of the \<Provider\>MachinePool, and the Kind of the \<Provider\>MachinePool with "Machine" appended to it. For example, if the \<Provider\>MachinePool is of Kind "FooMachinePool", the query will be of Kind "FooMachinePoolMachine".
 
 Once found, CAPI will create and connect MachinePool Machines to each resource. A MachinePool Machine is implemented as a Cluster API Machine that is owned by a MachinePool. If the field is empty, no MachinePool Machines will be created, and the overall behavior is the same as before this proposal was implemented.
 
-It is the responsibility of each provider to populate `InfrastructureSelector` and to create provider-specific MachinePool Machine resources behind each Machine. For example, the Docker provider will create a DockerMachinePoolMachine to represent the container instance behind the Machine in the infrastructure provider's MachinePool. It will also ensure that the DockerMachinePoolMachine is labeled such that the `InfrastructureSelector` can be used to find it.
+It is the responsibility of each provider to populate `InfrastructureMachineSelector` and to create provider-specific MachinePool Machine resources behind each Machine. For example, the Docker provider will create a DockerMachinePoolMachine to represent the container instance behind the Machine in the infrastructure provider's MachinePool. It will also ensure that the DockerMachinePoolMachine is labeled such that the `InfrastructureMachineSelector` can be used to find it.
 
 ![MachinePool Controller Infrastructure Reference Changed Sequence](images/machinepool-machines/infraref-changed-sequence.png)
 
@@ -142,7 +141,7 @@ A cluster admin updates a MachinePool to a newer Kubernetes version and would li
 
 ### Implementation Details/Notes/Constraints
 
-- As an alternative, the `InfrastructureSelector` field could be attached to the CAPI MachinePool resource. Then the CAPI MachinePool controller could check it directly and it would be more clearly documented in code.
+- As an alternative, the `InfrastructureMachineSelector` field could be attached to the CAPI MachinePool resource. Then the CAPI MachinePool controller could check it directly and it would be more clearly documented in code.
 
 - Since this is an optional feature, some providers will implement MachinePool Machines and others will not. While having MachinePool Machines represented improves the consistency of the UX when compared to MachineDeployments, they also create a split in the UX between different MachinePool providers: some will show Machines and others won't (the current behavior).
 
@@ -152,7 +151,7 @@ A cluster admin updates a MachinePool to a newer Kubernetes version and would li
 
 ### Risks and Mitigations
 
-- A previous version of this proposal suggested using a pre-populated `infrastructureRefList` instead of the `InfrastructureSelector` and related fields. Effectively, this means the query "what provider resources exist for this MachinePool's instances?" would be pre-populated, rather than run as needed. This approach would not scale well to MachinePools with hundreds or thousands of instances, since that list becomes part of the representation of that MachinePool, possibly causing storage or network transfer issues.
+- A previous version of this proposal suggested using a pre-populated `infrastructureRefList` instead of the `InfrastructureMachineSelector` and related fields. Effectively, this means the query "what provider resources exist for this MachinePool's instances?" would be pre-populated, rather than run as needed. This approach would not scale well to MachinePools with hundreds or thousands of instances, since that list becomes part of the representation of that MachinePool, possibly causing storage or network transfer issues.
 
   It was pointed out that the existing `providerIDList` suffers the same scalability issue as an `infrastructureRefList` would. It would be nice to refactor it away, but doing so is not considered a goal of this proposal effort.