commit 1e39914fbcecda7ec236e67f143bbefc31eee9da
author Serge Bazanski <serge@monogon.tech> Tue Oct 22 10:58:15 2024 +0000
committer Serge Bazanski <serge@monogon.tech> Wed Oct 30 11:42:51 2024 +0000
tree 806a09d23eec324d7ff131f42ddfab13cc0f98e0
parent 20498ddc40079451c83ba3708afc57d820866cb3

metropolis: first pass API for reconfiguring cluster

This implements management.ConfigureCluster. This API is based around
Protobuf FieldMasks, which is a new thing in the Metropolis codebase
(node config mutation is performed via optional fields).

Whether this is the right way to do this is to be discussed.
Alternatives considered are:

1. Always insert a full new config, providing the old one as a base. The
   downside of that is the potential conflicts that will spring up the
   moment we have systems regularly mutate independent parts of the
   config. Additionally, this might lead to some odd behaviour when
   dealing with clients that don't have support for newer versions of
   the config proto.
2. Use optional fields, like in Node role code. However, this has the
   downside of duplicating protos (one for the config state, one for the
   mutation request). Plus, protobuf optionals are still somewhat
   unusual.
3. Provide individual requests for mutating fields (like with Node
   labels). This also results in a lot of boilerplate code.
4. Something akin to JSON Patch, but for protobufs, which doesn't seem
   to exist.

Change-Id: I42e5eabd42076e947f4bc8399b843e0e1fd48548
Reviewed-on: https://review.monogon.dev/c/monogon/+/3591
Tested-by: Jenkins CI
Reviewed-by: Tim Windelschmidt <tim@monogon.tech>