Less noisy redeployment

rudi commented 3 months ago

As reported by @robert-sanfeliu

If no nodes added or removed (received solution is identical to current state), do not relabel nodes and re-send the KubeVela file.
When an app is not in state RUNNING, discard incoming solver messages; the app will be redeploying or failed.
But also, do not set app state to FAILED just because we managed to ask for redeployment while not in state RUNNING.

GeirHo commented 3 months ago

Regarding second bullet: This is already handled by the Solver. All SLO Violation messages recevied when the application state is different from "RUNNING" will be ignored.

Regarding the third bullet: I do not understand this. How can something ask for a redeployment without having going through the proper reconfiguration loop issuing an SLO Violation? Only the Solver should decide on the application's configuration, and thus only the initial deployment can be done without the intervention of the Solver

rudi commented 3 months ago

Bullet 2 and 3 are just explicitly handling "impossible" cases. As we know, in a distributed system impossible cases become possible, so I'm going for a belt-and-suspenders approach :)

eu-nebulous / optimiser-controller

Less noisy redeployment #12