[EPIC] Import Wrangler controllers/clients and cache interfaces to Automation Framework

[igomez06]

• [x] #1177
• [ ] #1178
• [x] #1179
• [ ] #1180
• [x] #1212
• [ ] #1495

[floatingman]

Adding notes from Jake Hyde to further clarify this task. The current steve API (not REST API, but go API) is far too cumbersome and verbose. Consider the following example for getting all machine deployments belonging to a cluster:

h.machineDeploymentCache.List(cluster.Namespace, labels.SelectorFromSet(labels.Set{capi.ClusterLabelName: cluster.Name})) versus using the go automation framework today:

query, err := url.ParseQuery(fmt.Sprintf("filter=metadata.labels.%s=%s", capi.ClusterLabelName, clusterName)) require.NoError(r.T(), err) machineDeploymentsResp, err := client.Steve.SteveType("machinedeployments.cluster.x-k8s.io").List(query) require.NoError(r.T(), err) assert.True(r.T(), len(machineDeploymentsResp.Data) > 0) for _, mdResp := range machineDeploymentsResp.Data { md := capi.MachineDeployment{} require.NoError(r.T(), steveV1.ConvertToK8sType(mdResp.JSONResp, &md)) } We should be testing steve, but then essentially wrapping our steve interface in one that is similar or even wrangler compatible so we can call our functions without having to sit down and figure out how to translate our k8s functions into steve calls. I'm having to manually sit and convert label selectors in REST requests and that results in a lot of wasted hours writing tests, which in turn leads to fewer tests being written. The appropriate places to use this functionality would be in areas where steve is not the right tool for the job. For example, in order to start encryption key rotation, we increment the spec.rkeConfig.rotateEncryptionKeys.generation. This is suitable for doing through steve, since the expected flow would be to verify if an operator can click the "Rotate Encryption Keys" button within the UI which performs the equivalent steve call. However during execution we want to verify status fields on the RKEControlPlane object, an object which never interacts with the UI through normal execution and its status fields are not copied to the provisioning cluster. In this instance we would prefer to just use wrangler, because as far as integration testing goes the easiest thing to do is use wrangler to set up a k8s watch and verify the fields move as expected, as trying to do watches with Steve is much more involved. Another way of saying this, is use Steve for the things a user is expected to do (making requests), use wrangler where we want to observe the system for correctness.

Now that the context is out of the way, these are the following test suites I think would be suitable:

• validation/certrotation
• same as encryption key rotation
• validation/delete_cluster_test
• need access to CAPI objects which are not typically controlled via UI
• validation/nodescaling
• need access to CAPI objects which are not typically viewed via UI (machine deployments and machines can be deleted/scaled via UI, but it is more idiomatic to use wrangler to access the object and view state during deletion).
• validation/provisioning
• need access to CAPI objects which are not typically controlled via UI snapshot
• need access to CAPI objects which are not typically controlled via UI
• v2prov
• encryption key rotation

[igomez06]

We'll need to create tickets for these.

• generate management.cattle.io controllers and implement session cleanup
• generate project.cattle.io controllers and implement session cleanup
• import wrangler controllers and implement session cleanup
• generate k8s controllers or clients implement session cleanup