docs: remove versionTag from the cluster crd

Documentation/cluster-crd.md

@@ -122,7 +122,6 @@ metadata:
   name: rook
   namespace: rook
 spec:
-  versionTag: master
   dataDirHostPath: /var/lib/rook
   # cluster level storage configuration and selection
   storage:
@@ -154,7 +153,6 @@ metadata:
   name: rook
   namespace: rook
 spec:
-  versionTag: master
   dataDirHostPath: /var/lib/rook
   # cluster level storage configuration and selection
   storage:
@@ -198,7 +196,6 @@ metadata:
   name: rook
   namespace: rook
 spec:
-  versionTag: master
   dataDirHostPath: /var/lib/rook
   # cluster level storage configuration and selection
   storage:
@@ -236,7 +233,6 @@ metadata:
   name: rook
   namespace: rook
 spec:
-  versionTag: master
   dataDirHostPath: /var/lib/rook
   placement:
     all:
@@ -284,7 +280,6 @@ metadata:
   name: rook
   namespace: rook
 spec:
-  versionTag: master
   dataDirHostPath: /var/lib/rook
   # cluster level resource requests/limits configuration
   resources:

Documentation/kubernetes.md

@@ -192,7 +192,6 @@ metadata:
   name: rook
   namespace: rook
 spec:
-  versionTag: master
   dataDirHostPath: /var/lib/rook
   storage:
     useAllNodes: true

Documentation/upgrade.md

@@ -43,7 +43,6 @@ metadata:
   name: rook
   namespace: rook
 spec:
-  versionTag: v0.5.0
   dataDirHostPath: /var/lib/rook
   storage:
     useAllNodes: true
@@ -132,16 +131,6 @@ The general flow of the upgrade process will be to upgrade the version of a Rook
 In this guide, we will be upgrading a live Rook cluster running `v0.5.0` to the next available version of `v0.5.1`.
 Let's get started!
 
-### Cluster Version Tag
-The first step in the upgrade process is to update the Cluster spec's `versionTag` field.
-This value is used as the version for any other Rook components that the operator may bring up later on in the cluster's lifecycle.
-We can begin editing it with the following `kubectl` command:
-```bash
-kubectl -n rook edit cluster.rook.io rook
-```
-This will bring up your default text editor with the cluster spec loaded and ready for editing.
-In your editor, simply update `versionTag: v0.5.0` to now be `versionTag: v0.5.1`, then save and quit your editor.
-
 ### Operator
 The Rook operator is the management brains of the cluster, so it should be upgraded first before other components.
 In the event that the new version requires a migration of metadata or config, the operator is the one that would understand how to perform that migration.

design/resource-constraints.md

@@ -80,7 +80,6 @@ metadata:
   name: rook
   namespace: rook
 spec:
-  versionTag: master
   dataDirHostPath: /var/lib/rook
   hostNetwork: false
   monCount: 3

design/upgrade.md

@@ -55,16 +55,13 @@ After this update, it will then terminate each agent pod in a rolling fashion so
 Once the operator and all agent pods are running and healthy on the new version, the administrator is free to begin the upgrade process for each of their Rook clusters.
 
 #### **Rook Cluster(s)**
-**Each** individual Rook cluster in the environment can be upgraded independently with the following flow:
-1. The cluster administrator updates their Rook Cluster CRD to update the `versionTag` field using a command similar to `kubectl -n rook edit cluster.rook.io rook`
-1. The Rook operator receives the `update` event for the Cluster CRD instance and sees that the `versionTag` field has changed from its previous value.
-    1. If the Rook system namespace upgrade described above has not yet occurred, then the operator should reject the cluster version `update` event.  The operator should never allow a cluster's version to be newer than its own version.
-1. The upgrade controller begins a reconciliation to bring the clusters actual version value in agreement with the desired version from the cluster CRD.
+1. The Rook operator, at startup after being upgraded, iterates over each Cluster CRD instance and proceeds to verify desired state.
+    1. If the Rook system namespace upgrade described above has not yet occurred, then the operator will delay upgrading a cluster until the system upgrade is completed.  The operator should never allow a cluster's version to be newer than its own version.
+1. The upgrade controller begins a reconciliation to bring the cluster's actual version value in agreement with the desired version, which is the container version of the operator pod.
 As each step in this sequence begins/ends, the status field of the cluster CRD will be updated to indicate the progress (current step) of the upgrade process.
 This will help the upgrade controller resume the upgrade if it were to be interrupted.
 Also, each step should be idempotent so that if the step has already been carried out, there will be no unintended side effects if the step is resumed or run again.
 1. **API:** The API pod will be upgraded first by updating the `image` field of the pod template spec.
-The `ROOK_VERSION_TAG` env var will also be updated within the template spec.
 The deployment managing the API pod will then terminate the old pod and then start a pod on the new version to replace it.
     1. The controller will verify that the new API pod is in the `Running` state with the new version and that basic routes are accessible such as `/status`.
 1. **Mons:** The monitor pods will be upgraded in a rolling fashion next.  **For each** monitor, the following actions will be performed by the upgrade controller:

tests/framework/installer/install_data.go

@@ -191,7 +191,6 @@ metadata:
   name: ` + namespace + `
   namespace: ` + namespace + `
 spec:
-  versionTag: master
   dataDirHostPath: ` + dataDirHostPath + `
   hostNetwork: false
   monCount: ` + strconv.Itoa(mons) + `