17b3b3b351
test(agent): Wrote first few tests for Primary workflow use cases : initializing to healthy, healthy to failed
01a775a01f
wip(agent): workflow now return new cluster state when they decide to alter it, primary taking control of current_primary case handled but using wrong ID
50aa545bd9
wip(harmony_agent): It compiles, contains most if not all of the required skeleton, now time to review it carefully, complete a few details and battle test it
0cff1e0f66
feat: Harmony agent new algorithm based on heartbeat counters basics. Old code will need to be refactored completely
Don't duplicate an identical match arm, rust allows a single body for multiple match cases. Look up the syntax if needed.
Good step in the right direction. I made comments as I read the code, it will probably require some discussion, unless everything I am saying really makes sense.
Delete this impl. These todo! are a huge smell. And I think it is fine that a decentralized topology does not know how to deploy nats asite of a NatsSupercluster. At least for the current use case. The end user deploying a postgresql will deploy it to a failovertopology, then the failovertopology will depend on a topology that supports a natssupercluster. At least for now.
Once again, this contains way too many implementation details. There should be a NatsK8s module that contains the nats specific logid, then k8s anywhere only does the dispatching depending on its own logic/state (which k8s is the anywhere pointing to right now). K8sAnywhere should not know how to deploy nats. It should tell a natsk8s module "deploy to okd" or something along those lines.
This does not belong in this file or as part of an impl K8sAnywhereTopology .