From 345cffc689b07ff093ac8efd4700f32b2eeb8aa5 Mon Sep 17 00:00:00 2001 From: KillianG Date: Fri, 30 Aug 2024 11:06:42 +0200 Subject: [PATCH] Remove all occurences of KubdeDB as it is not used nor supported anymore Issue: ZENKO-4848 --- .../installation/install/install_xdm.rst | 5 - docs/docsource/installation/upgrade/index.rst | 1 - .../xdm_migrate_from_kubedb_to_bitnami.rst | 348 ------------------ solution/deps.yaml | 5 - solution/zenkoversion.yaml | 1 - 5 files changed, 360 deletions(-) delete mode 100644 docs/docsource/installation/upgrade/xdm_migrate_from_kubedb_to_bitnami.rst diff --git a/docs/docsource/installation/install/install_xdm.rst b/docs/docsource/installation/install/install_xdm.rst index 686bef0603..982fce6028 100644 --- a/docs/docsource/installation/install/install_xdm.rst +++ b/docs/docsource/installation/install/install_xdm.rst @@ -66,9 +66,6 @@ Deploy |product| Operator .. parsed-literal:: /srv/scality/metalk8s-{{version-number}}/solutions.sh import --archive $ZENKO_BASE_ISO - sed "s/SOLUTION_ENV/zenko/g" /srv/scality/zenko-base-|version|/deploy/kubedb.yaml | kubectl apply -f - - kubectl -n zenko rollout status --timeout 10m deploy kubedb-operator - kubectl apply -f /srv/scality/zenko-base-|version|/deploy/kubedb-catalogs.yaml sed "s/SOLUTION_ENV/zenko/g" /srv/scality/zenko-base-|version|/deploy/kafka.yaml | kubectl apply -f - sed "s/SOLUTION_ENV/zenko/g" /srv/scality/zenko-base-|version|/deploy/zookeeper.yaml | kubectl apply -f - @@ -238,13 +235,11 @@ Deploy |product| version: |version| replicas: 1 mongodb: - provider: KubeDB persistence: volumeClaimTemplate: size: 300Gi storageClassName: sc-300-g redis: - provider: KubeDB persistence: volumeClaimTemplate: size: 10Gi diff --git a/docs/docsource/installation/upgrade/index.rst b/docs/docsource/installation/upgrade/index.rst index 85ece64989..3fedb16d5e 100644 --- a/docs/docsource/installation/upgrade/index.rst +++ b/docs/docsource/installation/upgrade/index.rst @@ -8,4 +8,3 @@ Upgrade :maxdepth: 2 upgrade_zenko - xdm_migrate_from_kubedb_to_bitnami diff --git a/docs/docsource/installation/upgrade/xdm_migrate_from_kubedb_to_bitnami.rst b/docs/docsource/installation/upgrade/xdm_migrate_from_kubedb_to_bitnami.rst deleted file mode 100644 index 8285d4c826..0000000000 --- a/docs/docsource/installation/upgrade/xdm_migrate_from_kubedb_to_bitnami.rst +++ /dev/null @@ -1,348 +0,0 @@ -Migrating MongoDB from KubeDB to Bitnami -======================================== - -Once a |product| instance is up and running, you can migrate the MongoDB -service from KubeDB to Bitnami by following these manual procedures. - -.. note:: - - In the following documentation, `artesca` is the name of the |product| - instance, and the migration is intended for |product| version 2.0.1 and - earlier to 2.x.x. - - The commands are written with the |product| - instance running Metalk8s, and the namespace is `zenko` and the - instance name is `artesca`. - -Before Upgrade -============== - -#. Make sure all the follwing resources are present, and that the `Zenko` - instance is in a running state. - - - mongodb/artesca-data-base-db - - secret/artesca-data-base-db-auth - - secret/artesca-data-base-db-cert - - secret/artesca-data-db-app-creds.v2 - - volume/data-mongodb - - persistentvolume/data-mongodb - - Verify `Zenko` is running and stable: - - .. code:: - - kubectl -n zenko describe zenko/artesca-data - - # example zenko conditions - ... - Conditions: - Last Transition Time: 2021-09-17T02:16:21Z - Message: All components ready to process requests - Status: True - Type: Available - Last Transition Time: 2021-09-19T22:29:31Z - Message: Deployment completed - Status: False - Type: DeploymentInProgress - Last Transition Time: 2021-09-19T22:22:55Z - Status: False - Type: DeploymentFailure - ... - Ready Replicas: 1 - -#. Download the ISOs: - - .. code:: - - curl -u -L -o /srv/scality/release/zenko-base-2.x.x.iso \ - https://... - curl -u -L -o /srv/scality/release/zenko-2.x.x.iso \ - https://... - -#. Import and activate ``zenko-base`` solution: - - .. code:: - - /srv/scality/metalk8s-2.9.2/solution.sh import -a /srv/scality/release/zenko-base-2.x.x.iso - /srv/scality/metalk8s-2.9.2/solution.sh activate -n zenko-base -V 2.x.x - -#. Import and activate ``zenko`` solution: - - .. code:: - - /srv/scality/metalk8s-2.9.2/solution.sh import -a /srv/scality/release/zenko-2.x.x.iso - /srv/scality/metalk8s-2.9.2/solution.sh activate -n zenko -V 2.x.x - -Upgrade -======= - -The upgrade procedure will consist of: - -- Deleting the KubeDB MongoDB deployment and freeing the PV resources used. -- Deploying MongoDB using the Bitnami charts. -- Updating the existing Zenko instance to use the Bitnami MongoDB. -- Updating the `MongoDB` replica set configuration. - -.. warning:: - - The upgrade procedure will result in |product| instance downtime, and the - following services will not be operational: - - - Cloudserver S3 APIs - - Backbeat APIs - - Orbit Management APIs - - Vault Management APIs - -Update the ``Zenko-Operator`` ------------------------------ - -#. Update the ``zenko-operator`` deployment: - - .. code:: - - /srv/scality/metalk8s-2.9.2/solution.sh add-solution -n zenko -s zenko -V 2.x.x - - After a few seconds you should see the new operator running. From there you can update each component. - -Deploy the ``Bitnami MongoDB`` ------------------------------- - -#. Create the `secret` resource manifest, ``mongodb-creds.yaml`` - - .. code:: - - MONGODB_ROOT_USERNAME=$(kubectl -n zenko get secret artesca-data-base-db-auth -o jsonpath='{.data.username}') - MONGODB_ROOT_PASSWORD=$(kubectl -n zenko get secret artesca-data-base-db-auth -o jsonpath='{.data.password}') - MONGODB_USERNAME=$(kubectl -n zenko get secret artesca-data-db-app-creds.v2 -o jsonpath='{.data.username}') - MONGODB_PASSWORD=$(kubectl -n zenko get secret artesca-data-db-app-creds.v2 -o jsonpath='{.data.password}') - MONGODB_REPLICA_SET_KEY=$(kubectl -n zenko get secret artesca-data-base-db-cert -o jsonpath='{.data.key\.txt}') - INSTANCE_ID=$(kubectl -n zenko get zenko/artesca-data -o jsonpath='{.status.instanceID}' | base64) - cat >> mongodb-creds.yaml <> zenko-patch.yaml <> zenko-patch.yaml < --type merge -p '{"spec":{"claimRef": null}}' - - The `Pending` Bitnami MongoDB deployment should now be able to claim the - existing `PVs` and start the creation of the `MongoDB` resources. - -Configuring the MongoDB Replica Set ------------------------------------ - -#. Wait for the `mongodb-primary` and `mongodb-secondary` statefulsets to be - successfully deployed. - - .. code:: - - kubectl rollout status statefulset mongodb-primary - # if deploying a multi-node configuration, run: - kubectl rollout status statefulset mongodb-secondary - -#. Access the `mongo` shell to start configuration procedure: - - .. code:: - - MONGODB_ROOT_USERNAME=$(kubectl -n zenko get secret mongodb-db-creds -o jsonpath='{.data.mongodb-root-username}' | base64 -d) - MONGODB_ROOT_PASSWORD=$(kubectl -n zenko get secret mongodb-db-creds -o jsonpath='{.data.mongodb-root-password}' | base64 -d) - kubectl -n zenko exec -ti mongodb-primary-0 -c mongodb-primary -- mongo -u $MONGODB_ROOT_USERNAME -p $MONGODB_ROOT_PASSWORD - -#. In `mongo` shell, run the following commands: - - - Create `rsconf` variable in: - - .. code:: - - rs0:OTHER> rsconf = rs.conf() - - - Add replica set members: - - .. code:: - - rs0:OTHER> rsconf.members = [ - ... {_id: 0, host: "mongodb-primary-0.mongodb-headless.zenko.svc.cluster.local:27017"} - ... ] - - If running 3-nodes, the following should be added: - - .. code:: - - rs0:OTHER> rsconf.members = [ - ... {_id: 0, host: "mongodb-primary-0.mongodb-headless.zenko.svc.cluster.local:27017"}, - ... {_id: 1, host: "mongodb-secondary-0.mongodb-headless.zenko.svc.cluster.local:27017"}, - ... {_id: 2, host: "mongodb-secondary-1.mongodb-headless.zenko.svc.cluster.local:27017"} - ... ] - - - Run `rs.reconfig` to elect new `PRIMARY`: - - .. code:: - - rs0:OTHER> rs.reconfig(rsconf, { force: true}) - - - Verify the replica set is configured correctly: - - .. code:: - - rs0:PRIMARY> rs.status()["members"] - -Verifying Zenko Deployment Status ---------------------------------- - -#. Wait for the `Zenko` instance to be upgraded: - - .. code:: - - # wait for any existing errors from the upgrade to be resolved - kubectl -n zenko wait --for condition=DeploymentFailure=false --timeout 10m zenko/artesca-data - - # wait for any for upgrade completion - kubectl -n zenko wait --for condition=DeploymentInProgress=false --timeout 10m zenko/artesca-data - - If an error occurs during the upgrade process or a upgrade times out, the - following can be run to debug the issue: - - .. code:: - - kubectl -n zenko describe zenko/artesca-data - - The ``DeploymentFailure`` condition will contain details about the error - preventing the upgrade from completing. diff --git a/solution/deps.yaml b/solution/deps.yaml index 93fe514364..cf5ca8983b 100644 --- a/solution/deps.yaml +++ b/solution/deps.yaml @@ -91,11 +91,6 @@ redis: image: redis tag: 7.0.15 envsubst: REDIS_TAG -redis-kubedb: - sourceRegistry: kubedb - image: redis - tag: 5.0.3-v1 - envsubst: REDIS_KUBEDB_TAG redis_exporter: sourceRegistry: oliver006 image: redis_exporter diff --git a/solution/zenkoversion.yaml b/solution/zenkoversion.yaml index ff3953fb04..9f80ba124e 100644 --- a/solution/zenkoversion.yaml +++ b/solution/zenkoversion.yaml @@ -132,7 +132,6 @@ spec: exporter: image: redis_exporter tag: '${REDIS_EXPORTER_TAG}' - kubedb: '${REDIS_KUBEDB_TAG}' featureFlags: multipleColdLocations: true backbeatGCVaultAuthorized: true