After seeing how the state of a service has been used in the different templates that have been created so far, there is a scheme that seems to come out.
Usually we keep 2 kind of state information:
state that as been asked: this is done by calling action
state of the reality: this is done by watching the system actual state.
The idea of this FR is to formalize these 2 type of state into the API of the 0-robot.
So a template could manage these 2 types of states and some interesting behavior could be derived from it. For example, we could automatically detect if a service is healthy or not by comparing the asked state with the reality state. If the two state matches, we know the service is healthy and doing what is expected from it.
On the other hand, if the two state mismatch, we know there is something that needs to happens. Can be self-healing that needs to kick in or human interaction. All these decision could be automated.
Issue migrated from [https://api.github.com/repos/zero-os/0-robot/issues/257](), opened by @zaibon
After seeing how the state of a service has been used in the different templates that have been created so far, there is a scheme that seems to come out. Usually we keep 2 kind of state information:
The idea of this FR is to formalize these 2 type of state into the API of the 0-robot. So a template could manage these 2 types of states and some interesting behavior could be derived from it. For example, we could automatically detect if a service is healthy or not by comparing the asked state with the reality state. If the two state matches, we know the service is healthy and doing what is expected from it. On the other hand, if the two state mismatch, we know there is something that needs to happens. Can be self-healing that needs to kick in or human interaction. All these decision could be automated.