An e2e CI test pipeline should be in place so that each time when there is an update to the CAPI provider or the infrastructure operator, this e2e CI pipeline should be triggered.

The e2e CI should be using the yaml manifests similar to generated by Sylva to deploy  CAPI provider and the infrastructure operator and ultimate workload cluster deployment.

This e2e CI will use KIND as the bootstrap cluster and virtual machines to emulate the baremetal servers.

We should assume the manifests will stay the same, so if the manifests fail to deploy the CAPI provider or the infrastructure operator or the OKD workload cluster fails to deploy, we can assume it is the code change in the CAPI provider repo or the infrastructure provider that is causing the problem.  

3. Why does the customer need this? (List the business requirements here)

To guarantee the backward compatibility and quality, and do not break the current Sylva user when CAPI provider is updated or the infra operator is updated.

4. List any affected packages or components.

CAPI provider, infrastructure operator.