rpcpb

const (
	// SIGTERM_ONE_FOLLOWER stops a randomly chosen follower (non-leader)
	// but does not delete its data directories on disk for next restart.
	// It waits "delay-ms" before recovering this failure.
	// The expected behavior is that the follower comes back online
	// and rejoins the cluster, and then each member continues to process
	// client requests ('Put' request that requires Raft consensus).
	Case_SIGTERM_ONE_FOLLOWER Case = 0
	// SIGTERM_ONE_FOLLOWER_UNTIL_TRIGGER_SNAPSHOT stops a randomly chosen
	// follower but does not delete its data directories on disk for next
	// restart. And waits until most up-to-date node (leader) applies the
	// snapshot count of entries since the stop operation.
	// The expected behavior is that the follower comes back online and
	// rejoins the cluster, and then active leader sends snapshot
	// to the follower to force it to follow the leader's log.
	// As always, after recovery, each member must be able to process
	// client requests.
	Case_SIGTERM_ONE_FOLLOWER_UNTIL_TRIGGER_SNAPSHOT Case = 1
	// SIGTERM_LEADER stops the active leader node but does not delete its
	// data directories on disk for next restart. Then it waits "delay-ms"
	// before recovering this failure, in order to trigger election timeouts.
	// The expected behavior is that a new leader gets elected, and the
	// old leader comes back online and rejoins the cluster as a follower.
	// As always, after recovery, each member must be able to process
	// client requests.
	Case_SIGTERM_LEADER Case = 2
	// SIGTERM_LEADER_UNTIL_TRIGGER_SNAPSHOT stops the active leader node
	// but does not delete its data directories on disk for next restart.
	// And waits until most up-to-date node ("new" leader) applies the
	// snapshot count of entries since the stop operation.
	// The expected behavior is that cluster elects a new leader, and the
	// old leader comes back online and rejoins the cluster as a follower.
	// And it receives the snapshot from the new leader to overwrite its
	// store. As always, after recovery, each member must be able to
	// process client requests.
	Case_SIGTERM_LEADER_UNTIL_TRIGGER_SNAPSHOT Case = 3
	// SIGTERM_QUORUM stops majority number of nodes to make the whole cluster
	// inoperable but does not delete data directories on stopped nodes
	// for next restart. And it waits "delay-ms" before recovering failure.
	// The expected behavior is that nodes come back online, thus cluster
	// comes back operative as well. As always, after recovery, each member
	// must be able to process client requests.
	Case_SIGTERM_QUORUM Case = 4
	// SIGTERM_ALL stops the whole cluster but does not delete data directories
	// on disk for next restart. And it waits "delay-ms" before  recovering
	// this failure.
	// The expected behavior is that nodes come back online, thus cluster
	// comes back operative as well. As always, after recovery, each member
	// must be able to process client requests.
	Case_SIGTERM_ALL Case = 5
	// SIGQUIT_AND_REMOVE_ONE_FOLLOWER stops a randomly chosen follower
	// (non-leader), deletes its data directories on disk, and removes
	// this member from cluster (membership reconfiguration). On recovery,
	// tester adds a new member, and this member joins the existing cluster
	// with fresh data. It waits "delay-ms" before recovering this
	// failure. This simulates destroying one follower machine, where operator
	// needs to add a new member from a fresh machine.
	// The expected behavior is that a new member joins the existing cluster,
	// and then each member continues to process client requests.
	Case_SIGQUIT_AND_REMOVE_ONE_FOLLOWER Case = 10
	// SIGQUIT_AND_REMOVE_ONE_FOLLOWER_UNTIL_TRIGGER_SNAPSHOT stops a randomly
	// chosen follower, deletes its data directories on disk, and removes
	// this member from cluster (membership reconfiguration). On recovery,
	// tester adds a new member, and this member joins the existing cluster
	// restart. On member remove, cluster waits until most up-to-date node
	// (leader) applies the snapshot count of entries since the stop operation.
	// This simulates destroying a leader machine, where operator needs to add
	// a new member from a fresh machine.
	// The expected behavior is that a new member joins the existing cluster,
	// and receives a snapshot from the active leader. As always, after
	// recovery, each member must be able to process client requests.
	Case_SIGQUIT_AND_REMOVE_ONE_FOLLOWER_UNTIL_TRIGGER_SNAPSHOT Case = 11
	// SIGQUIT_AND_REMOVE_LEADER stops the active leader node, deletes its
	// data directories on disk, and removes this member from cluster.
	// On recovery, tester adds a new member, and this member joins the
	// existing cluster with fresh data. It waits "delay-ms" before
	// recovering this failure. This simulates destroying a leader machine,
	// where operator needs to add a new member from a fresh machine.
	// The expected behavior is that a new member joins the existing cluster,
	// and then each member continues to process client requests.
	Case_SIGQUIT_AND_REMOVE_LEADER Case = 12
	// SIGQUIT_AND_REMOVE_LEADER_UNTIL_TRIGGER_SNAPSHOT stops the active leader,
	// deletes its data directories on disk, and removes this member from
	// cluster (membership reconfiguration). On recovery, tester adds a new
	// member, and this member joins the existing cluster restart. On member
	// remove, cluster waits until most up-to-date node (new leader) applies
	// the snapshot count of entries since the stop operation. This simulates
	// destroying a leader machine, where operator needs to add a new member
	// from a fresh machine.
	// The expected behavior is that on member remove, cluster elects a new
	// leader, and a new member joins the existing cluster and receives a
	// snapshot from the newly elected leader. As always, after recovery, each
	// member must be able to process client requests.
	Case_SIGQUIT_AND_REMOVE_LEADER_UNTIL_TRIGGER_SNAPSHOT Case = 13
	// SIGQUIT_AND_REMOVE_QUORUM_AND_RESTORE_LEADER_SNAPSHOT_FROM_SCRATCH first
	// stops majority number of nodes, deletes data directories on those quorum
	// nodes, to make the whole cluster inoperable. Now that quorum and their
	// data are totally destroyed, cluster cannot even remove unavailable nodes
	// (e.g. 2 out of 3 are lost, so no leader can be elected).
	// Let's assume 3-node cluster of node A, B, and C. One day, node A and B
	// are destroyed and all their data are gone. The only viable solution is
	// to recover from C's latest snapshot.
	//
	// To simulate:
	//  1. Assume node C is the current leader with most up-to-date data.
	//  2. Download snapshot from node C, before destroying node A and B.
	//  3. Destroy node A and B, and make the whole cluster inoperable.
	//  4. Now node C cannot operate either.
	//  5. SIGTERM node C and remove its data directories.
	//  6. Restore a new seed member from node C's latest snapshot file.
	//  7. Add another member to establish 2-node cluster.
	//  8. Add another member to establish 3-node cluster.
	//  9. Add more if any.
	//
	// The expected behavior is that etcd successfully recovers from such
	// disastrous situation as only 1-node survives out of 3-node cluster,
	// new members joins the existing cluster, and previous data from snapshot
	// are still preserved after recovery process. As always, after recovery,
	// each member must be able to process client requests.
	Case_SIGQUIT_AND_REMOVE_QUORUM_AND_RESTORE_LEADER_SNAPSHOT_FROM_SCRATCH Case = 14
	// BLACKHOLE_PEER_PORT_TX_RX_ONE_FOLLOWER drops all outgoing/incoming
	// packets from/to the peer port on a randomly chosen follower
	// (non-leader), and waits for "delay-ms" until recovery.
	// The expected behavior is that once dropping operation is undone,
	// each member must be able to process client requests.
	Case_BLACKHOLE_PEER_PORT_TX_RX_ONE_FOLLOWER Case = 100
	// BLACKHOLE_PEER_PORT_TX_RX_ONE_FOLLOWER_UNTIL_TRIGGER_SNAPSHOT drops
	// all outgoing/incoming packets from/to the peer port on a randomly
	// chosen follower (non-leader), and waits for most up-to-date node
	// (leader) applies the snapshot count of entries since the blackhole
	// operation.
	// The expected behavior is that once packet drop operation is undone,
	// the slow follower tries to catch up, possibly receiving the snapshot
	// from the active leader. As always, after recovery, each member must
	// be able to process client requests.
	Case_BLACKHOLE_PEER_PORT_TX_RX_ONE_FOLLOWER_UNTIL_TRIGGER_SNAPSHOT Case = 101
	// BLACKHOLE_PEER_PORT_TX_RX_LEADER drops all outgoing/incoming packets
	// from/to the peer port on the active leader (isolated), and waits for
	// "delay-ms" until recovery, in order to trigger election timeout.
	// The expected behavior is that after election timeout, a new leader gets
	// elected, and once dropping operation is undone, the old leader comes
	// back and rejoins the cluster as a follower. As always, after recovery,
	// each member must be able to process client requests.
	Case_BLACKHOLE_PEER_PORT_TX_RX_LEADER Case = 102
	// BLACKHOLE_PEER_PORT_TX_RX_LEADER_UNTIL_TRIGGER_SNAPSHOT drops all
	// outgoing/incoming packets from/to the peer port on the active leader,
	// and waits for most up-to-date node (leader) applies the snapshot
	// count of entries since the blackhole operation.
	// The expected behavior is that cluster elects a new leader, and once
	// dropping operation is undone, the old leader comes back and rejoins
	// the cluster as a follower. The slow follower tries to catch up, likely
	// receiving the snapshot from the new active leader. As always, after
	// recovery, each member must be able to process client requests.
	Case_BLACKHOLE_PEER_PORT_TX_RX_LEADER_UNTIL_TRIGGER_SNAPSHOT Case = 103
	// BLACKHOLE_PEER_PORT_TX_RX_QUORUM drops all outgoing/incoming packets
	// from/to the peer ports on majority nodes of cluster, thus losing its
	// leader and cluster being inoperable. And it waits for "delay-ms"
	// until recovery.
	// The expected behavior is that once packet drop operation is undone,
	// nodes come back online, thus cluster comes back operative. As always,
	// after recovery, each member must be able to process client requests.
	Case_BLACKHOLE_PEER_PORT_TX_RX_QUORUM Case = 104
	// BLACKHOLE_PEER_PORT_TX_RX_ALL drops all outgoing/incoming packets
	// from/to the peer ports on all nodes, thus making cluster totally
	// inoperable. It waits for "delay-ms" until recovery.
	// The expected behavior is that once packet drop operation is undone,
	// nodes come back online, thus cluster comes back operative. As always,
	// after recovery, each member must be able to process client requests.
	Case_BLACKHOLE_PEER_PORT_TX_RX_ALL Case = 105
	// DELAY_PEER_PORT_TX_RX_ONE_FOLLOWER delays outgoing/incoming packets
	// from/to the peer port on a randomly chosen follower (non-leader).
	// It waits for "delay-ms" until recovery.
	// The expected behavior is that once packet delay operation is undone,
	// the follower comes back and tries to catch up with latest changes from
	// cluster. And as always, after recovery, each member must be able to
	// process client requests.
	Case_DELAY_PEER_PORT_TX_RX_ONE_FOLLOWER Case = 200
	// RANDOM_DELAY_PEER_PORT_TX_RX_ONE_FOLLOWER delays outgoing/incoming
	// packets from/to the peer port on a randomly chosen follower
	// (non-leader) with a randomized time duration (thus isolated). It
	// waits for "delay-ms" until recovery.
	// The expected behavior is that once packet delay operation is undone,
	// each member must be able to process client requests.
	Case_RANDOM_DELAY_PEER_PORT_TX_RX_ONE_FOLLOWER Case = 201
	// DELAY_PEER_PORT_TX_RX_ONE_FOLLOWER_UNTIL_TRIGGER_SNAPSHOT delays
	// outgoing/incoming packets from/to the peer port on a randomly chosen
	// follower (non-leader), and waits for most up-to-date node (leader)
	// applies the snapshot count of entries since the delay operation.
	// The expected behavior is that the delayed follower gets isolated
	// and behind the current active leader, and once delay operation is undone,
	// the slow follower comes back and catches up possibly receiving snapshot
	// from the active leader. As always, after recovery, each member must be
	// able to process client requests.
	Case_DELAY_PEER_PORT_TX_RX_ONE_FOLLOWER_UNTIL_TRIGGER_SNAPSHOT Case = 202
	// RANDOM_DELAY_PEER_PORT_TX_RX_ONE_FOLLOWER_UNTIL_TRIGGER_SNAPSHOT delays
	// outgoing/incoming packets from/to the peer port on a randomly chosen
	// follower (non-leader) with a randomized time duration, and waits for
	// most up-to-date node (leader) applies the snapshot count of entries
	// since the delay operation.
	// The expected behavior is that the delayed follower gets isolated
	// and behind the current active leader, and once delay operation is undone,
	// the slow follower comes back and catches up, possibly receiving a
	// snapshot from the active leader. As always, after recovery, each member
	// must be able to process client requests.
	Case_RANDOM_DELAY_PEER_PORT_TX_RX_ONE_FOLLOWER_UNTIL_TRIGGER_SNAPSHOT Case = 203
	// DELAY_PEER_PORT_TX_RX_LEADER delays outgoing/incoming packets from/to
	// the peer port on the active leader. And waits for "delay-ms" until
	// recovery.
	// The expected behavior is that cluster may elect a new leader, and
	// once packet delay operation is undone, the (old) leader comes back
	// and tries to catch up with latest changes from cluster. As always,
	// after recovery, each member must be able to process client requests.
	Case_DELAY_PEER_PORT_TX_RX_LEADER Case = 204
	// RANDOM_DELAY_PEER_PORT_TX_RX_LEADER delays outgoing/incoming packets
	// from/to the peer port on the active leader with a randomized time
	// duration. And waits for "delay-ms" until recovery.
	// The expected behavior is that cluster may elect a new leader, and
	// once packet delay operation is undone, the (old) leader comes back
	// and tries to catch up with latest changes from cluster. As always,
	// after recovery, each member must be able to process client requests.
	Case_RANDOM_DELAY_PEER_PORT_TX_RX_LEADER Case = 205
	// DELAY_PEER_PORT_TX_RX_LEADER_UNTIL_TRIGGER_SNAPSHOT delays
	// outgoing/incoming packets from/to the peer port on the active leader,
	// and waits for most up-to-date node (current or new leader) applies the
	// snapshot count of entries since the delay operation.
	// The expected behavior is that cluster may elect a new leader, and
	// the old leader gets isolated and behind the current active leader,
	// and once delay operation is undone, the slow follower comes back
	// and catches up, likely receiving a snapshot from the active leader.
	// As always, after recovery, each member must be able to process client
	// requests.
	Case_DELAY_PEER_PORT_TX_RX_LEADER_UNTIL_TRIGGER_SNAPSHOT Case = 206
	// RANDOM_DELAY_PEER_PORT_TX_RX_LEADER_UNTIL_TRIGGER_SNAPSHOT delays
	// outgoing/incoming packets from/to the peer port on the active leader,
	// with a randomized time duration. And it waits for most up-to-date node
	// (current or new leader) applies the snapshot count of entries since the
	// delay operation.
	// The expected behavior is that cluster may elect a new leader, and
	// the old leader gets isolated and behind the current active leader,
	// and once delay operation is undone, the slow follower comes back
	// and catches up, likely receiving a snapshot from the active leader.
	// As always, after recovery, each member must be able to process client
	// requests.
	Case_RANDOM_DELAY_PEER_PORT_TX_RX_LEADER_UNTIL_TRIGGER_SNAPSHOT Case = 207
	// DELAY_PEER_PORT_TX_RX_QUORUM delays outgoing/incoming packets from/to
	// the peer ports on majority nodes of cluster. And it waits for
	// "delay-ms" until recovery, likely to trigger election timeouts.
	// The expected behavior is that cluster may elect a new leader, while
	// quorum of nodes struggle with slow networks, and once delay operation
	// is undone, nodes come back and cluster comes back operative. As always,
	// after recovery, each member must be able to process client requests.
	Case_DELAY_PEER_PORT_TX_RX_QUORUM Case = 208
	// RANDOM_DELAY_PEER_PORT_TX_RX_QUORUM delays outgoing/incoming packets
	// from/to the peer ports on majority nodes of cluster, with randomized
	// time durations. And it waits for "delay-ms" until recovery, likely
	// to trigger election timeouts.
	// The expected behavior is that cluster may elect a new leader, while
	// quorum of nodes struggle with slow networks, and once delay operation
	// is undone, nodes come back and cluster comes back operative. As always,
	// after recovery, each member must be able to process client requests.
	Case_RANDOM_DELAY_PEER_PORT_TX_RX_QUORUM Case = 209
	// DELAY_PEER_PORT_TX_RX_ALL delays outgoing/incoming packets from/to the
	// peer ports on all nodes. And it waits for "delay-ms" until recovery,
	// likely to trigger election timeouts.
	// The expected behavior is that cluster may become totally inoperable,
	// struggling with slow networks across the whole cluster. Once delay
	// operation is undone, nodes come back and cluster comes back operative.
	// As always, after recovery, each member must be able to process client
	// requests.
	Case_DELAY_PEER_PORT_TX_RX_ALL Case = 210
	// RANDOM_DELAY_PEER_PORT_TX_RX_ALL delays outgoing/incoming packets
	// from/to the peer ports on all nodes, with randomized time durations.
	// And it waits for "delay-ms" until recovery, likely to trigger
	// election timeouts.
	// The expected behavior is that cluster may become totally inoperable,
	// struggling with slow networks across the whole cluster. Once delay
	// operation is undone, nodes come back and cluster comes back operative.
	// As always, after recovery, each member must be able to process client
	// requests.
	Case_RANDOM_DELAY_PEER_PORT_TX_RX_ALL Case = 211
	// NO_FAIL_WITH_STRESS stops injecting failures while testing the
	// consistency and correctness under pressure loads, for the duration of
	// "delay-ms". Goal is to ensure cluster be still making progress
	// on recovery, and verify system does not deadlock following a sequence
	// of failure injections.
	// The expected behavior is that cluster remains fully operative in healthy
	// condition. As always, after recovery, each member must be able to process
	// client requests.
	Case_NO_FAIL_WITH_STRESS Case = 300
	// NO_FAIL_WITH_NO_STRESS_FOR_LIVENESS neither injects failures nor
	// sends stressig client requests to the cluster, for the duration of
	// "delay-ms". Goal is to ensure cluster be still making progress
	// on recovery, and verify system does not deadlock following a sequence
	// of failure injections.
	// The expected behavior is that cluster remains fully operative in healthy
	// condition, and clients requests during liveness period succeed without
	// errors.
	// Note: this is how Google Chubby does failure injection testing
	// https://static.googleusercontent.com/media/research.google.com/en//archive/paxos_made_live.pdf.
	Case_NO_FAIL_WITH_NO_STRESS_FOR_LIVENESS Case = 301
	// FAILPOINTS injects failpoints to etcd server runtime, triggering panics
	// in critical code paths.
	Case_FAILPOINTS Case = 400
	// EXTERNAL runs external failure injection scripts.
	Case_EXTERNAL Case = 500
)

const (
	Checker_KV_HASH      Checker = 0
	Checker_LEASE_EXPIRE Checker = 1
	Checker_RUNNER       Checker = 2
	Checker_NO_CHECK     Checker = 3
)

const (
	// NOT_STARTED is the agent status before etcd first start.
	Operation_NOT_STARTED Operation = 0
	// INITIAL_START_ETCD is only called to start etcd, the very first time.
	Operation_INITIAL_START_ETCD Operation = 10
	// RESTART_ETCD is sent to restart killed etcd.
	Operation_RESTART_ETCD Operation = 11
	// SIGTERM_ETCD pauses etcd process while keeping data directories
	// and previous etcd configurations.
	Operation_SIGTERM_ETCD Operation = 20
	// SIGQUIT_ETCD_AND_REMOVE_DATA kills etcd process and removes all data
	// directories to simulate destroying the whole machine.
	Operation_SIGQUIT_ETCD_AND_REMOVE_DATA Operation = 21
	// SAVE_SNAPSHOT is sent to trigger local member to download its snapshot
	// onto its local disk with the specified path from tester.
	Operation_SAVE_SNAPSHOT Operation = 30
	// RESTORE_RESTART_FROM_SNAPSHOT is sent to trigger local member to
	// restore a cluster from existing snapshot from disk, and restart
	// an etcd instance from recovered data.
	Operation_RESTORE_RESTART_FROM_SNAPSHOT Operation = 31
	// RESTART_FROM_SNAPSHOT is sent to trigger local member to restart
	// and join an existing cluster that has been recovered from a snapshot.
	// Local member joins this cluster with fresh data.
	Operation_RESTART_FROM_SNAPSHOT Operation = 32
	// SIGQUIT_ETCD_AND_ARCHIVE_DATA is sent when consistency check failed,
	// thus need to archive etcd data directories.
	Operation_SIGQUIT_ETCD_AND_ARCHIVE_DATA Operation = 40
	// SIGQUIT_ETCD_AND_REMOVE_DATA_AND_STOP_AGENT destroys etcd process,
	// etcd data, and agent server.
	Operation_SIGQUIT_ETCD_AND_REMOVE_DATA_AND_STOP_AGENT Operation = 41
	// BLACKHOLE_PEER_PORT_TX_RX drops all outgoing/incoming packets from/to
	// the peer port on target member's peer port.
	Operation_BLACKHOLE_PEER_PORT_TX_RX Operation = 100
	// UNBLACKHOLE_PEER_PORT_TX_RX removes outgoing/incoming packet dropping.
	Operation_UNBLACKHOLE_PEER_PORT_TX_RX Operation = 101
	// DELAY_PEER_PORT_TX_RX delays all outgoing/incoming packets from/to
	// the peer port on target member's peer port.
	Operation_DELAY_PEER_PORT_TX_RX Operation = 200
	// UNDELAY_PEER_PORT_TX_RX removes all outgoing/incoming delays.
	Operation_UNDELAY_PEER_PORT_TX_RX Operation = 201
)

const (
	Stresser_KV                Stresser = 0
	Stresser_LEASE             Stresser = 1
	Stresser_ELECTION_RUNNER   Stresser = 2
	Stresser_WATCH_RUNNER      Stresser = 3
	Stresser_LOCK_RACER_RUNNER Stresser = 4
	Stresser_LEASE_RUNNER      Stresser = 5
)