Allow bypassing the downgrade check with the IgnoreUpgradabilityChecks flag. (#2278)

* Allow bypassing the downgrade check with the IgnoreUpgradabilityChecks flag.

* Add documentation on the new behavior of this flag.

Author: brownleej

api/v1beta2/foundationdbcluster_types.go

@@ -180,8 +180,8 @@ type FoundationDBClusterSpec struct {
 	// Routing defines the configuration for routing to our pods.
 	Routing RoutingConfig `json:"routing,omitempty"`
 
-	// IgnoreUpgradabilityChecks determines whether we should skip the check for
-	// client compatibility when performing an upgrade.
+	// IgnoreUpgradabilityChecks determines whether we should skip the checks for
+	// version compatibility when performing an upgrade.
 	IgnoreUpgradabilityChecks bool `json:"ignoreUpgradabilityChecks,omitempty"`
 
 	// Buggify defines settings for injecting faults into a cluster for testing.

controllers/check_client_compatibility.go

@@ -43,6 +43,10 @@ func (c checkClientCompatibility) reconcile(_ context.Context, r *FoundationDBCl
 		return nil
 	}
 
+	if cluster.Spec.IgnoreUpgradabilityChecks {
+		return nil
+	}
+
 	runningVersion, err := fdbv1beta2.ParseFdbVersion(cluster.Status.RunningVersion)
 	if err != nil {
 		return &requeue{curError: err}
@@ -61,10 +65,6 @@ func (c checkClientCompatibility) reconcile(_ context.Context, r *FoundationDBCl
 		return nil
 	}
 
-	if cluster.Spec.IgnoreUpgradabilityChecks {
-		return nil
-	}
-
 	adminClient, err := r.getAdminClient(logger, cluster)
 	if err != nil {
 		return &requeue{curError: err}

docs/cluster_spec.md

@@ -260,7 +260,7 @@ FoundationDBClusterSpec defines the desired state of a cluster.
 | processGroupIDPrefix | ProcessGroupIDPrefix defines a prefix to append to the process group IDs in the locality fields.  This must be a valid Kubernetes label value. See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set for more details on that. | string | false |
 | lockOptions | LockOptions allows customizing how we manage locks for global operations. | [LockOptions](#lockoptions) | false |
 | routing | Routing defines the configuration for routing to our pods. | [RoutingConfig](#routingconfig) | false |
-| ignoreUpgradabilityChecks | IgnoreUpgradabilityChecks determines whether we should skip the check for client compatibility when performing an upgrade. | bool | false |
+| ignoreUpgradabilityChecks | IgnoreUpgradabilityChecks determines whether we should skip the checks for version compatibility when performing an upgrade. | bool | false |
 | buggify | Buggify defines settings for injecting faults into a cluster for testing. | [BuggifyConfig](#buggifyconfig) | false |
 | storageServersPerPod | StorageServersPerPod defines how many Storage Servers should run in a single process group (Pod). This number defines the number of processes running in one Pod whereas the ProcessCounts defines the number of Pods created. This means that you end up with ProcessCounts[\"storage\"] * StorageServersPerPod storage processes. | int | false |
 | logServersPerPod | LogServersPerPod defines how many Log Servers should run in a single process group (Pod). This number defines the number of processes running in one Pod whereas the ProcessCounts defines the number of Pods created. This means that you end up with ProcessCounts[\"Log\"] * LogServersPerPod log processes. This also affects processes with the transaction class. | int | false |

docs/manual/technical_design.md

@@ -146,7 +146,9 @@ The `UpdateConfigMap` subreconciler creates a `ConfigMap` object for the cluster
 
 The `CheckClientCompatibility` subreconciler is used during upgrades to ensure that every client is compatible with the new version of FoundationDB. When it detects that the `version` in the cluster spec is protocol-compatible with the `runningVersion` in the cluster status, this will do nothing. When these are different, it means there is a pending upgrade. This subreconciler will check the `connected_clients` field in the database status, and if it finds any clients whose max supported protocol version is not the same as the `version` from the cluster spec, it will fail reconciliation. This prevents upgrading a database until all clients have been updated with a compatible client library.
 
-You can skip this check by setting the `ignoreUpgradabilityChecks` flag in the cluster spec.
+This subreconciler will also ensure that if the versions are protocol-incompatible, the new version is more recent than the cluster's current version. The level of support for protocol-incompatible downgrades is more nuanced than the path for upgrades, and the [FoundationDB docs](https://apple.github.io/foundationdb/administration.html#version-specific-notes-on-downgrading) have more details on this path.
+
+You can skip these checks by setting the `ignoreUpgradabilityChecks` flag in the cluster spec.
 
 ### DeletePodsForBuggification