From 8cdb02e32efdebfe7b4adaac6b4f43ab220066ec Mon Sep 17 00:00:00 2001 From: Travis Nielsen Date: Thu, 4 Jan 2018 14:57:27 -0800 Subject: [PATCH] docs: remove versionTag from the cluster crd --- Documentation/cluster-crd.md | 5 ----- Documentation/kubernetes.md | 1 - Documentation/upgrade.md | 11 ----------- design/resource-constraints.md | 1 - design/upgrade.md | 9 +++------ tests/framework/installer/install_data.go | 1 - 6 files changed, 3 insertions(+), 25 deletions(-) diff --git a/Documentation/cluster-crd.md b/Documentation/cluster-crd.md index 59299c6a0..8ce536840 100644 --- a/Documentation/cluster-crd.md +++ b/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: diff --git a/Documentation/kubernetes.md b/Documentation/kubernetes.md index 373be4765..528e5e359 100644 --- a/Documentation/kubernetes.md +++ b/Documentation/kubernetes.md @@ -192,7 +192,6 @@ metadata: name: rook namespace: rook spec: - versionTag: master dataDirHostPath: /var/lib/rook storage: useAllNodes: true diff --git a/Documentation/upgrade.md b/Documentation/upgrade.md index 4c433f2bc..8d2db5187 100644 --- a/Documentation/upgrade.md +++ b/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. diff --git a/design/resource-constraints.md b/design/resource-constraints.md index 4bf3cb174..81e374dcf 100644 --- a/design/resource-constraints.md +++ b/design/resource-constraints.md @@ -80,7 +80,6 @@ metadata: name: rook namespace: rook spec: - versionTag: master dataDirHostPath: /var/lib/rook hostNetwork: false monCount: 3 diff --git a/design/upgrade.md b/design/upgrade.md index 0d7ca273d..5dcbdf2ab 100644 --- a/design/upgrade.md +++ b/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: diff --git a/tests/framework/installer/install_data.go b/tests/framework/installer/install_data.go index 2ee70be6f..af7af6246 100644 --- a/tests/framework/installer/install_data.go +++ b/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) + `