Open paigerube14 opened 3 weeks ago
Hello @paigerube14 I recently found krkn and was looking for ways to help, I came across this issue and started looking through the code a bit to understand the context of it. Just to see if I understood it correctly, the idea would be to remove from the native scenarios (let's say the node_scenarios) the whole file of kubernetes_functions.py and instead use an instance of KrknKubernetes throughout the plugins accordingly?
@Josecespedesant Awesome! We love any contributions we can get! Yes exactly, if any functions are missing feel free to also add them to krkn-lib as needed. This might also require some rework in the general set up the scenario. But overall should align with other node scenarios like this and this scenario file Let us know if you need any other help and we would be happy to review any draft PR's as you start working. Thanks for your contributions
Great! Really appreciated! I also joined the krkn channel in Slack, is that a good way to communicate with the team as well?
@Josecespedesant yes! thats a great way to reach us as well
While working on adding the ability to connect to private clusters (Pr), I found that I would have to add the same set of changes in 5+ places because of the current implementation of the "native" scenarios. This is because each of the native scenarios defines its own set of connection and functions to a set cluster (example: pod_network_scenario) I think that we should remove the kubernetes functions that are duplicately defined in krkn and instead use the same configuration that is defined in krkn-lib. This will help align the connection type and reduce the duplication of functions. I think it will also reduce the ease of adding new scenarios if we have one common place with all functions and libraries for interacting with the kubernetes cluster