To create consistent and user-friendly status change.
Goals
$subject
Approach
Instead of using Running and Updating status along with available pods, we change the status to Ready and Not Ready.
When minimal required pods are available in a SiddhiProcess, the SiddhiProcess's status becomes ready.
Initially, the status was Pending. But when updating the SiddhiProcess if the required pods are not available then it becomes Not Ready.
User stories
The status change will happen as follow.
After the first kubectl apply comes to the Pending state.
$ kubectl get sp
NAME STATUS READY AGE
power-consume-app Pending 7s
After the deployment creation, the status move to Not Ready status because the pods are not ready to get the requests.
$ kubectl get sp
NAME STATUS READY AGE
power-consume-app Not Ready 0/2 98s
After all the pods up and ready(according to health check) then it becomes Ready. Note that, here to become Ready all the stateful/stateless apps should be available and having one replica should be enough for stateless apps.
$ kubectl get sp
NAME STATUS READY AGE
power-consume-app Ready 2/2 5m58s
Purpose
To create consistent and user-friendly status change.
Goals
$subject
Approach
User stories
The status change will happen as follow.
kubectl applycomes to thePendingstate.Not Readystatus because the pods are not ready to get the requests.Ready. Note that, here to become Ready all the stateful/stateless apps should be available and having one replica should be enough for stateless apps.Related PRs
111, #110
Test environment
minikube version: v1.4.0 commit: 7969c25a98a018b94ea87d949350f3271e9d64b6