Currently, the flow implemented by livelint checks a deployment and expects it to have a service and an ingress. Any other case will fail. To prepare the code for being able to implement other flows or checks, the flow (e.g. which checks are run in which order and what state of a specific check either calls for another check or is a leaf in the check flow chart) should be decoupled from the checks themselves and from the UI. the RunChecks(...) function currently has 3 responsibilities: 1. load data from kubernetes 2. run checks in a specific order 3. communicate with the user. These responsibilities should be distributed to different components.
-
Data loading
So that the checks themselves can work in an efficient manner, this will also require a kind of decoupled kubernetes resource reading and caching mechanism, so that the checks can get the required information, but so that not every check
-
Different flow implementations should be possible so that the available checks can be easily extended (i.e. deployments without service, just pods, ingress, etc.)
-
Errors or communication should be run over a standard interface where the flow does not need to know the exact form that user interaction takes or even if there is any kind of interaction. Check results and flow state should be continually reported to a standard interface.
Currently, the flow implemented by livelint checks a deployment and expects it to have a service and an ingress. Any other case will fail. To prepare the code for being able to implement other flows or checks, the flow (e.g. which checks are run in which order and what state of a specific check either calls for another check or is a leaf in the check flow chart) should be decoupled from the checks themselves and from the UI. the
RunChecks(...)function currently has 3 responsibilities: 1. load data from kubernetes 2. run checks in a specific order 3. communicate with the user. These responsibilities should be distributed to different components.Data loading
So that the checks themselves can work in an efficient manner, this will also require a kind of decoupled kubernetes resource reading and caching mechanism, so that the checks can get the required information, but so that not every check
Different flow implementations should be possible so that the available checks can be easily extended (i.e. deployments without service, just pods, ingress, etc.)
Errors or communication should be run over a standard interface where the flow does not need to know the exact form that user interaction takes or even if there is any kind of interaction. Check results and flow state should be continually reported to a standard interface.