)]}'
{
  "commit": "2d91aa323b5cb576b3c7749eedb91058be1f8f57",
  "tree": "1d4a2a79f2f63cca28614df7f37fd044fd0844da",
  "parents": [
    "b354453656f82d0a38b3f2ed0d1ebf843c14d922"
  ],
  "author": {
    "name": "Serge Bazanski",
    "email": "serge@monogon.tech",
    "time": "Mon Apr 25 13:29:31 2022 +0200"
  },
  "committer": {
    "name": "Sergiusz Bazanski",
    "email": "serge@monogon.tech",
    "time": "Tue May 24 15:31:27 2022 +0000"
  },
  "message": "curator: remove dispatch system\n\nThis vastly simplifies the curator by removing the dispatch and per-RPC\nswitch logic, instead replacing it with the gRPC server stopping\nwhenever the leadership status of a curator switches.\n\nThe downside is technically the possibility of some \u0027stale\u0027 RPC\nhandling, where a leader/follower accepts some new RPC even though it\u0027s\nin the process of switching its leadership.\n\nThe rationale for this change is:\n\n   1. Leadership-exclusive actions are guarded by the etcd leadership\n      lock being held, so there\u0027s no chance a long pending RPC to a\n      leader that just stepped down will cause split brain scenarios.\n\n   2. We\u0027re moving away from follower proxying, and followers will\n      instead just serve a \u0027who\u0027s the leader\u0027 RPC. These are okay to\n      serve stale data (ie. when the contacted follower should\u0027ve\n      switched to be a leader, or a follower of another leader), as\n      during leadership failover we expect clients to perform retry\n      loops until a new leadership connection is established.\n\nAnother downside (or perhaps upside) is that we don\u0027t start the listener\nuntil we\u0027re ready to serve data, either the full API as a leader or a\nreduced API as a follower. The downside is that clients will have to\nretry connections until the leader is running, and that it might be\ndifficult to tell apart a node which isn\u0027t yet running the curator from\na broken node, or one that will not run the curator at all. On the other\nhand, succesfully establishing a connections means that we are sure to\nget a gRPC response instead of a hang because the curator isn\u0027t yet ready\nto serve.\n\nChange-Id: I2ec35f00bce72f0f337e8e25e8c71f5265a7d8bb\nReviewed-on: https://review.monogon.dev/c/monogon/+/685\nReviewed-by: Lorenz Brun \u003clorenz@monogon.tech\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "16bfbfee7222dd09d1d3c6828900c6b58a0dd06a",
      "old_mode": 33188,
      "old_path": "metropolis/node/core/curator/BUILD.bazel",
      "new_id": "681b637e1c446fe11ad4f392ab2a36a3a02ec28c",
      "new_mode": 33188,
      "new_path": "metropolis/node/core/curator/BUILD.bazel"
    },
    {
      "type": "modify",
      "old_id": "d6ec579d0e0de90224600f6877d7da4f5ade35e7",
      "old_mode": 33188,
      "old_path": "metropolis/node/core/curator/curator.go",
      "new_id": "9ad88a8df249550ccb7a3e152f5247c3b71b7bb5",
      "new_mode": 33188,
      "new_path": "metropolis/node/core/curator/curator.go"
    },
    {
      "type": "modify",
      "old_id": "9715c9114bf4ad6e14c990ddba67fc05466b2454",
      "old_mode": 33188,
      "old_path": "metropolis/node/core/curator/listener.go",
      "new_id": "5af644b9100df4f6832394e9fa1ae99a10def6ef",
      "new_mode": 33188,
      "new_path": "metropolis/node/core/curator/listener.go"
    },
    {
      "type": "delete",
      "old_id": "3961bf81d0c06830cbc51b8804a5b405e01c5809",
      "old_mode": 33188,
      "old_path": "metropolis/node/core/curator/listener_test.go",
      "new_id": "0000000000000000000000000000000000000000",
      "new_mode": 0,
      "new_path": "/dev/null"
    }
  ]
}