Skip to content

proto: Introduce transactional voting phases

Patrick Steinhardt requested to merge pks-tx-voting-phases into master

Transactional votes currently only contain information about the vote that we actually want to cast, but it doesn't contain any sort of metadata which would allow us to more precisely track the nature of a specific vote. Most importantly, while we already use "preparatory" and "committing" votes in almost all places, they are only preparatory and committing votes by convention: there is no metadata which would allow us to discern these cases.

Amend the voting RPC call to use "phases", which currently knows three different phases:

- "unknown": this is the current default which we'll need to support
  until all voting callsites have been converted to use proper
  phases.

- "prepared": the change has been prepared to be committed. Locks
  have been taken already, but no change has yet been committed to
  disk such that they would be visible to the user.

- "committed": changes have been committed to disk and are thus both
  persistent and visible to the user.

With these phases, we can eventually build additional logic into Praefect which makes use of them. This includes creating less replication jobs if no change was committed, making two-phase voting a necessity instead of a convention, and potentially others.

Changelog: added

Part of #3709 (closed)

Merge request reports