Applies to: Kyvos Enterprise  Kyvos Cloud (SaaS on AWS) Kyvos AWS Marketplace

...

To upgrade your Kyvos version from the current version to a newer version using the Kyvos Manager portal, perform the following steps.

Post-upgrade steps

Post upgrade steps for upgrading to 2023.2 from 2023.1.x

Deploying Zookeeper

If you have upgraded to Kyvos 2023.2, you must redeploy the Zookeeper using the Zookeeper configuration page in Kyvos Manager to switch to the latest version of Zookeeper.  This is necessary for cloud deployments (AWS, GCP, and Azure) and on-prem deployments to remove the previous version of Zookeeper.

To upgrade to the latest version, switching to managed Zookeeper is mandatory.

If you are upgrading both Kyvos Manager and Kyvos using either the single click upgrade or the All components upgrade, you must redeploy Zookeeper after upgrading Kyvos Manager.

Upgrade Graviton JRE for AWS cluster 

To upgrade Kyvos, perform the following post-upgrade steps. 

1. Navigate to the following Kyvos path: 
   /data/kyvos/installs/kyvosmanager_war/kyvosmanagerdata/server/repo

2. Execute the following command to download JRE 8.372.07.1 
   curl -o manual_node_creation_graviton_prereq.tar.gz https://s3.amazonaws.com/us-east-1.kyvos/2023.2/latest/prereq/manual_node_creation_graviton_prereq.tar.gz

3. Untar the  Kyvos2023.2_Build000x_ux64.tar.gz  tar file at the above location. The  kyvos  folder is extracted. 

4. Navigate to the  kyvos  folder and delete the existing  jre  folder, and copy the downloaded JRE (refer to step 2). 

5. Rename the  Kyvos2023.2_Build000x_ux64.tar.gz  tar file to  Kyvos2023.2_Build000x_ux64_old.tar.gz

6. Create a new tar in the  kyvos  folder by executing the following command: 
   tar -cvzf Kyvos2023.2_Build000x_ux64.tar.gz kyvos/

7. Go to Kyvos Manager, navigate to the Upgrade page, and then upgrade Kyvos.

Post upgrade IAM policies to use resource scaling

Case 1
To upgrade from Kyvos 2023.1.1 to Kyvos 2023.5, perform the following steps.

...

1. To increase or decrease BI Server or Query Engine nodes, following permissions need to be added in IAM roles:

   Code Block
   { "Sid": "LaunchTemplateAndTerminateInstances", "Effect": "Allow", "Action": [ "ec2:GetLaunchTemplateData", "ec2:TerminateInstances" ], "Resource": "*", "Condition": { "StringEqualsIgnoreCase": { "ec2:ResourceTag/UsedBy": "Kyvos" } } }, { "Sid": "CreateLaunchTemplate", "Effect": "Allow", "Action": [ "ec2:RunInstances", "ec2:CreateLaunchTemplate", "ec2:DeleteLaunchTemplate" ], "Resource": "*" }

2. The ‘CreateTags’ permission needs to be removed. Hence, to create a separate policy for creating tags. Replace the following existing policy.

   Code Block
   { "Condition": { "StringEqualsIgnoreCase": { "ec2:ResourceTag/UsedBy": "Kyvos" } }, "Action": [ "ec2:DeleteTags", "ec2:CreateTags", "ec2:DescribeInstanceStatus" ], "Resource": "*", "Effect": "Allow", "Sid": "Ec2tagsPermissionKM" },

3. After replacing the policy mentioned in Step-2, update the following policy.

   Code Block
   { "Sid": "Ec2tagsPermissionKM", "Effect": "Allow", "Action": [ "ec2:DeleteTags", "ec2:DescribeInstanceStatus" ], "Resource": "*", "Condition": { "StringEqualsIgnoreCase": { "ec2:ResourceTag/UsedBy": "Kyvos" } } }, { "Sid": "Ec2tagsPermissionKM2", "Effect": "Allow", "Action": [ "ec2:CreateTags" ], "Resource": "*" }

4. Add a tag on all Query Engine and BI Server as cloudformation:stack-name and its value must be the stack name you provide.

5. Remove the following existing policy for a condition.

   Code Block
   { "Sid": "Ec2StartStopKyvos", "Effect": "Allow", "Action": [ "ec2:StopInstances", "ec2:StartInstances", "ec2:DescribeInstanceStatus" ], "Resource": "*", "Condition": { "StringEqualsIgnoreCase": { "ec2:ResourceTag/aws:cloudformation:stack-name": { "Fn::Sub": "${AWS::StackName}" } } } },

6. After removing the policy mentioned in step-5 (as mentioned above) for a condition, update the following policy.

   Code Block
   { "Sid": "Ec2StartStopKyvos", "Effect": "Allow", "Action": [ "ec2:StopInstances", "ec2:StartInstances", "ec2:DescribeInstanceStatus" ], "Resource": "*", "Condition": { "StringEqualsIgnoreCase": { "ec2:ResourceTag/cloudformation:stack-name": { "Fn::Sub": "${AWS::StackName}" } } } },

Kyvos rollback

You can roll back patches or upgrade deployments to previously installed versions through the Kyvos Manager portal. 

...

1. Create a manual backup of your existing cluster using the steps explained in the Upgrading Kyvos Manager and Kyvos section.

2. On the navigation pane, click Application Update > Rollback.
   The Rollback page is displayed. 

   

3. Click the Select rollback state link. From the displayed dialog box, choose the state to which you want to roll back. You can use the search box to Search for a specific version, or view Operation Details using the corresponding link.

4. The Backup Path path shows the path used for creating/restoring a backup of Kyvos states in case of Deploy Upgrade and Deploy Patch/Rollback operations. The backup path should be consistent across all the available systems. You can edit this path using the Modify Backup Path option from the three-dots menu. A ny backup created prior to changing the path remains unaffected and will continue to be available at the same location.
   Click the Rollback Now button from the top-right of the page.
   

   

5. On the displayed confirmation message box, select the Start Kyvos Service checkbox to start the service automatically after rollback.

6. Enter your Kyvos Manager Password to confirm the rollback. Kyvos takes you to the  Operations page  followed by the  Rollback Logs  details page.
   

...

Deleting Kyvos upgrade and patch bundles 

From Kyvos 2023.3 onwards, during Kyvos upgrade and patch processes, the oldest backup bundle will be deleted automatically to retain the newest bundles within the specified limit. Suppose you choose to preserve 6 bundles out of 10 available. In this case, only the 6 most recent bundles will be saved, and the remaining 4 bundles will be deleted. The oldest of these 4 bundles, based on the date they were created, will be deleted first.

To delete a previous state of rollback, use the Manage Backup Bundles option from the three-dots menu.

...

In the Preserve Backup Bundles list, set the count to retain the bundles. 

Points to know

• If the number of bundles present exceeds the preserved count, the remaining bundle will be automatically selected, indicating that it will be deleted.

• If the number of bundles equals the retention count, no bundles will be deleted.

• Bundles can only be deleted by changing the preserve count. Selecting them for deletion is disabled and unsupported. 

• If the latest backup bundle is a Patch, then the most recent Kyvos bundle will also be preserved.

• The backup bundles which are created for failed Kyvos upgrade or failed Patch operations will also be there in the list to delete.

Restoring to Derby State of Kyvos Manager or Kyvos

You can restore the Derby-compatible version of Kyvos, or the Kyvos Manager process that is prior to Kyvos 2023.1. 

You must perform the following manual steps to perform a Kyvos, or Kyvos Manager process rollback: 

1. Change the JDBC URL in the jdbc.properties to a Derby-specific URL. To do this, you must rename the existing jdbc.properties (using Postgres as a repository) to the jdbc.properties.postgres and then rename the existing jdbc.properties.derby to jdbc. properties.
   NOTE: The files are located at:  kyvosmanagerdata/server/db/

2. In addition, if the bundled Postgres is used as the Kyvos Manager repository, it is necessary to move the Postgres folder inside Kyvos on each node of the cluster from its current location parallel to Kyvos.

3. To switch back to the old Derby-compatible version of Kyvos Manager, first stop the current Postgres, which is supported as the Kyvos Manager process repository.

4. If a Kyvos rollback is also required, then perform it using the Derby-compatible Kyvos Manager only. Also, ensure that you perform Step 3.

Deploy Patch

To deploy a patch on an existing Kyvos version, perform the following steps.

...