Add validation to Machines

Goal

We introduced support for the Control Plane Machine Set Operator (CPMSO) in OSASINFRA-3100. This allows users to configure their control plane Machine resources via a ControlPlaneMachineSet custom resource (CR). However, as noted in e.g. OCPBUGS-17153 or OCPBUGS-16597, we do no validation of resource identifiers (network IDs, subnet IDs, volume types, availability zones, ...) specified in the CR: if a user specifies e.g. an invalid volume availability zone when creating or updating a ControlPlaneMachineSet, CPMSO will blindly accept it. Because the resource doesn't exist, the machine created by Machine API Operator (MAO) will be stuck in pending state forever.

We should add validation of resource identifiers in either CPMSO or MAO, allowing us to identify obvious misconfigurations like these and report them to the user via events or logs.

Why is this important?

This will significantly improve the UX of CPMS and MAO by surfacing obvious user errors and allowing users to quickly address these errors.

Scenarios

1. When creating an initial ControlPlaneMachineSet, if a user does any of the following then either CPMS or MAO should fail gracefully and provide enough context to allow the user to correct their mistake:
   • ...specifies a network ID that they don't have access to or that doesn't exist
   • ...specifies a subnet ID that they don't have access to or that doesn't exist
   • ...specifies a volume type that they don't have access to or that doesn't exist
   • ...specifies a volume or compute availability zone that doesn't exist

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Documentation

Dependencies (internal and external)

1. OSASINFRA-3100
2. OSASINFRA-3134

Previous Work (Optional):

1. https://github.com/openshift/cluster-control-plane-machine-set-operator/pull/225

Open questions::

1. Where should this logic live? In CPMS or MCO?

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Technical Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>