Kong
spike: Cluster API as cluster provisioner
Problem Statement
When this repository was originally created I was considering Cluster API as the provisioning tool for what is now Cluster objects in the environment provisioning portion of this testing framework, but due to concerns of complexity and maturity it was decided to create our own simple cluster provisioners.
Since then cluster-api has matured a lot and is in a v1 release state. At this point it would seem that pivoting to cluster api for provisioning environments would allow us to take advantage of the already existing provisioner implementations for different cloud environments and otherwise reduce our maintenance costs long term while giving us access to all the features of cluster-api and enabling us to help maintain cluster API as part of our use case.
The purpose of this issue is to investigate whether cluster-api would make sense for us as a machinery pivot at this point and create a KEP defining how that would look in practice. Alternatively we may just want to consider the benefits of adding it alongside what we already have.
