From 89cdbe3f3bb057fde25d2c43bcde81609dfbb072 Mon Sep 17 00:00:00 2001 From: Michael Troutman Date: Fri, 15 Dec 2023 09:29:09 -0500 Subject: [PATCH 1/2] add step 4 migration instructs Op v1 -> Op v2 Adds instructions for installing Operator v2 as part of the migration from Operator v1 to v2. --- migration/4-install-operator-v2.html | 69 ++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+) create mode 100644 migration/4-install-operator-v2.html diff --git a/migration/4-install-operator-v2.html b/migration/4-install-operator-v2.html new file mode 100644 index 0000000..00c7ae4 --- /dev/null +++ b/migration/4-install-operator-v2.html @@ -0,0 +1,69 @@ +

Installing LINSTOR Operator v2

+

After removing the LINSTOR Operator v1 deployment, you can install LINSTOR Operator v2.

+

You can deploy the LINSTOR Operator v2 by using either the Kustomize tool, integrated with kubectl, or else by using Helm and a LINBIT Helm chart.

+

This is the last step when migrating the LINSTOR Operator from version 1 (v1) to version 2 (v2).

+

Prerequisites

+

To install the LINSTOR Operator v2 into your current deployment, you will need to install the following tools:

+ +

Deploying LINSTOR Operator v2 by Using Kustomize

+

You can use kubectl and the built-in kustomize feature to deploy LINSTOR Operator v2.

+

For instructions on how to do this, refer to the documentation in the +LINSTOR User’s +Guide. Follow the user’s guide instructions for deploying the Operator v2, After deploying the Operator, return to this page (Step 4) and continue to the “Deploying the LINBIT SDS Cluster” instructions below.

+

Deploying LINSTOR Operator v2 by Using Helm

+

You can also use Helm to deploy LINSTOR Operator v2.

+

Instructions on how to do this are also in the LINSTOR User’s +Guide. Follow the user’s guide instructions for deploying the Operator v2, After deploying the Operator, return to this page (Step 4) and continue to the “Deploying the LINBIT SDS Cluster” instructions below.

+

Deploying the LINBIT SDS Cluster

+

LINBIT SDS is the term that describes a LINSTOR and DRBD deployment. The LINSTOR +Operator is a part of a LINBIT SDS deployment in Kubernetes. After deploying the +LINSTOR Operator v2, you can fully deploy LINBIT SDS in your Kubernetes cluster by using the resources that you generated in Step 2.

+

Creating a Secret

+

When installing the LINSTOR Operator v1 by using Helm, Helm automatically generates a passphrase for LINSTOR. After Helm initializes LINSTOR with the passphrase, the LINSTOR controller will not be able to fully start without supplying the passphrase. In Step 2 of the migration instructions, you collected the passphrase from your existing Operator v1 deployment. You will use that passphrase to create a secret that you can use to migrate your resources into the Operator v2 deployment.

+

To create the secret, enter the following commands:

+
# PASSPHRASE=<passphrase-collected-from-kubectl-get-secrets-command-in-step-2>
+# cat << EOF | kubectl apply -f - --server-side
+apiVersion: v1
+kind: Secret
+metadata:
+  name: linstor-op-passphrase
+  namespace: linbit-sds # Change the namespace here
+data:
+  MASTER_PASSPHRASE: $PASSPHRASE
+EOF
+# unset PASSPHRASE
+

Output from a successful kubectl apply command will show that the secret was +applied.

+
secret/linstor-op-passphrase serverside-applied
+

Applying Resources

+

Next, apply the resources that you collected in a v2-resources.yaml file by +running the collection script in the Step +2 instructions.

+
# kubectl apply -f v2-resources.yaml --server-side
+
+

💡 TIP: In Step +2, you ran +the information collection script from the piraeus-operator directory that +you cloned locally from the upstream GitHub project. Unless you moved it, this +is the directory where you can find the script-generated v2-resources.yaml +file.

+
+

Output from a successful command will show that your resources were created.

+
linstorcluster.piraeus.io/linstorcluster serverside-applied
+linstorsatelliteconfiguration.piraeus.io/host-networking serverside-applied
+linstorsatelliteconfiguration.piraeus.io/linstor-op-ns serverside-applied
+

Now the cluster will come up, using the existing data to restore the cluster state.

+

Verifying Cluster State

+

Before verifying your cluster state, you can change your kubectl command +context to the linbit-sds namespace, by entering the following command:

+
# kubectl config set-context --current --namespace=linbit-sds
+

Next, you can check the cluster state by using various linstor command line client commands:

+
# kubectl exec deploy/linstor-controller -- linstor node list
+# kubectl exec deploy/linstor-controller -- linstor storage-pool list
+# kubectl exec deploy/linstor-controller -- linstor resource list-volumes
+# kubectl exec deploy/linstor-controller -- linstor error-reports list
+

You can also provision new +volumes, to verify that the cluster is operational.

From bcb6f3bd94f44f4cd53e32b86bfed54913623249 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Moritz=20Wanzenb=C3=B6ck?= Date: Fri, 15 Dec 2023 15:57:06 +0100 Subject: [PATCH 2/2] migration step 4 styling --- migration/1-migrate-db.html | 1 + migration/2-collect-information.html | 5 +- migration/3-remove-operator-v1.html | 1 + migration/4-install-operator-v2.html | 198 +++++++++++++++++++-------- 4 files changed, 144 insertions(+), 61 deletions(-) diff --git a/migration/1-migrate-db.html b/migration/1-migrate-db.html index 53a8ecf..6d32123 100644 --- a/migration/1-migrate-db.html +++ b/migration/1-migrate-db.html @@ -18,6 +18,7 @@
  • 1. Migrate Database
  • 2. Collect Information
  • 3. Remove Operator v1
    • +
  • 4. Install Operator v2
  • Operator v1
    • diff --git a/migration/2-collect-information.html b/migration/2-collect-information.html index d619e60..6a8f583 100644 --- a/migration/2-collect-information.html +++ b/migration/2-collect-information.html @@ -18,6 +18,7 @@
  • 1. Migrate Database
  • 2. Collect Information
  • 3. Remove Operator v1
    • +
  • 4. Install Operator v2
  • Operator v1
    • @@ -49,7 +50,7 @@

    Prerequisites

  • jq - a command-line JSON processor
    • -

    Running the Data Collection Script

    +

    Running the Data Collection Script

    To collect the necessary information to migrate resources in your Operator v1 deployment to an upgraded Operator v2 deployment, you can run a script provided by LINBIT. @@ -101,7 +102,7 @@

    Running the Data Collection Script

    A copy of the identified resources in your current deployment is saved in a file named v2-resources.yaml.

    -

    Collecting Helm-Generated Secrets

    +

    Collecting Helm-Generated Secrets

    Helm automatically generates a passphrase for LINSTOR. Once LINSTOR is initialized with the passphrase, the LINSTOR Controller will not be able fully start without supplying the passphrase. diff --git a/migration/3-remove-operator-v1.html b/migration/3-remove-operator-v1.html index 1c6296e..2647aa6 100644 --- a/migration/3-remove-operator-v1.html +++ b/migration/3-remove-operator-v1.html @@ -18,6 +18,7 @@

  • 1. Migrate Database
  • 2. Collect Information
  • 3. Remove Operator v1
    • +
  • 4. Install Operator v2
  • Operator v1
    • diff --git a/migration/4-install-operator-v2.html b/migration/4-install-operator-v2.html index 00c7ae4..7634ba0 100644 --- a/migration/4-install-operator-v2.html +++ b/migration/4-install-operator-v2.html @@ -1,31 +1,99 @@ -

    Installing LINSTOR Operator v2

    -

    After removing the LINSTOR Operator v1 deployment, you can install LINSTOR Operator v2.

    -

    You can deploy the LINSTOR Operator v2 by using either the Kustomize tool, integrated with kubectl, or else by using Helm and a LINBIT Helm chart.

    -

    This is the last step when migrating the LINSTOR Operator from version 1 (v1) to version 2 (v2).

    -

    Prerequisites

    -

    To install the LINSTOR Operator v2 into your current deployment, you will need to install the following tools:

    - -

    Deploying LINSTOR Operator v2 by Using Kustomize

    -

    You can use kubectl and the built-in kustomize feature to deploy LINSTOR Operator v2.

    -

    For instructions on how to do this, refer to the documentation in the -LINSTOR User’s -Guide. Follow the user’s guide instructions for deploying the Operator v2, After deploying the Operator, return to this page (Step 4) and continue to the “Deploying the LINBIT SDS Cluster” instructions below.

    -

    Deploying LINSTOR Operator v2 by Using Helm

    -

    You can also use Helm to deploy LINSTOR Operator v2.

    -

    Instructions on how to do this are also in the LINSTOR User’s -Guide. Follow the user’s guide instructions for deploying the Operator v2, After deploying the Operator, return to this page (Step 4) and continue to the “Deploying the LINBIT SDS Cluster” instructions below.

    -

    Deploying the LINBIT SDS Cluster

    -

    LINBIT SDS is the term that describes a LINSTOR and DRBD deployment. The LINSTOR -Operator is a part of a LINBIT SDS deployment in Kubernetes. After deploying the -LINSTOR Operator v2, you can fully deploy LINBIT SDS in your Kubernetes cluster by using the resources that you generated in Step 2.

    -

    Creating a Secret

    -

    When installing the LINSTOR Operator v1 by using Helm, Helm automatically generates a passphrase for LINSTOR. After Helm initializes LINSTOR with the passphrase, the LINSTOR controller will not be able to fully start without supplying the passphrase. In Step 2 of the migration instructions, you collected the passphrase from your existing Operator v1 deployment. You will use that passphrase to create a secret that you can use to migrate your resources into the Operator v2 deployment.

    -

    To create the secret, enter the following commands:

    -
    # PASSPHRASE=<passphrase-collected-from-kubectl-get-secrets-command-in-step-2>
-# cat << EOF | kubectl apply -f - --server-side
+
+
+
+    Removing the LINSTOR Operator v1 Deployment
+    
+    
+    
+    
+
+
+
    
+    
+
+    
    Installing LINSTOR Operator v2
    
+
    
+
    
+    
    
+        
    
+            After removing the LINSTOR Operator v1 deployment, you can install
+            LINSTOR Operator v2.
+        
    
+
+        
    
+            You can deploy the LINSTOR Operator v2 by using either the
+            Kustomize tool,
+            integrated with kubectl, or else by using Helm and a LINBIT Helm chart.
+        
    
+
+        
    This is the last step when migrating the LINSTOR Operator from version 1 (v1) to version 2 (v2).
    
+
+        
    Prerequisites
    
+        
    
+            To install the LINSTOR Operator v2 into your current deployment, you will need to install the following
+            tools:
+        
    
+
+        
+
+        
    Deploying LINSTOR Operator v2 by Using Kustomize
    
+        
    
+            You can use kubectl and the built-in kustomize feature to deploy LINSTOR Operator
+            v2.
    
+
+        
    
+            For instructions on how to do this, refer to the documentation in the
+            LINSTOR User’s Guide.
+            Follow the user’s guide instructions for deploying the Operator v2, After deploying the Operator, return to
+            this page (Step 4) and continue to the “Deploying the LINBIT SDS Cluster” instructions below.
+        
    
+
+        
    Deploying LINSTOR Operator v2 by Using Helm
    
+        
    You can also use Helm to deploy LINSTOR Operator v2.
    
+
+        
    
+            Instructions on how to do this are also in the
+            LINSTOR User’s Guide.
+            Follow the user’s guide instructions for deploying the Operator v2, After deploying the Operator, return to
+            this page (Step 4) and continue to the “Deploying the LINBIT SDS Cluster” instructions below.
+        
    
+
+        
    Deploying the LINBIT SDS Cluster
    
+        
    
+            LINBIT SDS is the term that describes a LINSTOR and DRBD deployment. The LINSTOR
+            Operator is a part of a LINBIT SDS deployment in Kubernetes. After deploying the
+            LINSTOR Operator v2, you can fully deploy LINBIT SDS in your Kubernetes cluster by using the resources that
+            you generated in Step 2.
+        
    
+
+        
    Creating a Secret
    
+        
    
+            When installing the LINSTOR Operator v1 by using Helm, Helm automatically generates a passphrase for LINSTOR.
+            After Helm initializes LINSTOR with the passphrase, the LINSTOR controller will not be able to fully start
+            without supplying the passphrase. In Step 2 of the migration
+            instructions, you collected the passphrase from your existing Operator v1 deployment. You will use that
+            passphrase to create a secret that you can use to migrate your resources into the Operator v2 deployment.
+        
    
+        
    To create the secret, enter the following commands:
    
+        
    PASSPHRASE=<passphrase-collected-from-kubectl-get-secrets-command-in-step-2>
+cat << EOF | kubectl apply -f - --server-side
 apiVersion: v1
 kind: Secret
 metadata:
@@ -34,36 +102,48 @@ 
    Creating a Secret
    
 data:
   MASTER_PASSPHRASE: $PASSPHRASE
 EOF
-# unset PASSPHRASE
    
-
    Output from a successful kubectl apply command will show that the secret was
-applied.
    
-
    secret/linstor-op-passphrase serverside-applied
    
-
    Applying Resources
    
-
    Next, apply the resources that you collected in a v2-resources.yaml file by
-running the collection script in the Step
-2 instructions.
    
-
    # kubectl apply -f v2-resources.yaml --server-side
    
-
    
-
    💡 TIP: In Step
-2, you ran
-the information collection script from the piraeus-operator directory that
-you cloned locally from the upstream GitHub project. Unless you moved it, this
-is the directory where you can find the script-generated v2-resources.yaml
-file.
    
-
    
-
    Output from a successful command will show that your resources were created.
    
-
    linstorcluster.piraeus.io/linstorcluster serverside-applied
+unset PASSPHRASE
    
+
+        
    Output from a successful kubectl apply command will show that the secret was applied.
    
+        
    secret/linstor-op-passphrase serverside-applied
    
+
+        
    Applying Resources
    
+        
    
+            Next, apply the resources that you collected in a v2-resources.yaml file by running the
+            collection script in the Step 2
+            instructions.
+        
    
+
+        
    kubectl apply -f v2-resources.yaml --server-side
    
+
+        
    Output from a successful command will show that your resources were created.
    
+
+        
    linstorcluster.piraeus.io/linstorcluster serverside-applied
 linstorsatelliteconfiguration.piraeus.io/host-networking serverside-applied
 linstorsatelliteconfiguration.piraeus.io/linstor-op-ns serverside-applied
    
-
    Now the cluster will come up, using the existing data to restore the cluster state.
    
-
    Verifying Cluster State
    
-
    Before verifying your cluster state, you can change your kubectl command
-context to the linbit-sds namespace, by entering the following command:
    
-
    # kubectl config set-context --current --namespace=linbit-sds
    
-
    Next, you can check the cluster state by using various linstor command line client commands:
    
-
    # kubectl exec deploy/linstor-controller -- linstor node list
-# kubectl exec deploy/linstor-controller -- linstor storage-pool list
-# kubectl exec deploy/linstor-controller -- linstor resource list-volumes
-# kubectl exec deploy/linstor-controller -- linstor error-reports list
    
-
    You can also provision new
-volumes, to verify that the cluster is operational.
    
+
+        
    Now the cluster will come up, using the existing data to restore the cluster state.
    
+
+        
    Verifying Cluster State
    
+        
    
+            Before verifying your cluster state, you can change your kubectl command context to the
+            linbit-sds namespace, by entering the following command:
+        
    
+
+        
    kubectl config set-context --current --namespace=linbit-sds
    
+
+        
    Next, you can check the cluster state by using various linstor command line client commands:
    
+        
    kubectl exec deploy/linstor-controller -- linstor node list
+kubectl exec deploy/linstor-controller -- linstor storage-pool list
+kubectl exec deploy/linstor-controller -- linstor resource list-volumes
+kubectl exec deploy/linstor-controller -- linstor error-reports list
    
+
+        
    
+            You can also
+            provision new volumes,
+            to verify that the cluster is operational.
+        
    
+    
    
+
    
+
+