You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
cldmstr
changed the title
Create multiple check flows
Decouple check flow code from the checks
Mar 17, 2023
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.
The text was updated successfully, but these errors were encountered: