/
Upgrading Kyvos

Upgrading Kyvos

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

Kyvos Azure Marketplace   Kyvos GCP Marketplace Kyvos Single Node Installation (Kyvos SNI)

To upgrade Kyvos to a new version, perform the following steps.

Note

Before proceeding with the Kyvos upgrade, Upgrade the Kyvos Manager to a compatible version.

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

Redeploying Zookeeper

Important

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

  • After redeploying Managed Zookeeper, you must restart Kyvos services.

  • 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.

  • If you're currently using the default Zookeeper on the Kyvos Manager node, you'll need to redeploy the ZooKeeper. This applies to any cluster deployed before the managed Zookeeper implementation and still uses the default Zookeeper on the Kyvos Manager node.

When upgrading to a release across which the Managed Zookeeper supported version is changing, post-upgrade, the activity of Managed Zookeeper undeploy/deploy will be required.

From Kyvos Release

To any Kyvos Release up to

Supported Managed Zookeeper version

2021.2

2023.1.x

3.6.1

2023.2

2024.1.2

3.7.1

2024.1.3

Till Date (i.e. 2024.2)

3.8.4

This is a one-time activity that is required only when upgrading from a prior release using older Managed ZooKeeper version to a Kyvos release which is using the newer version of Managed Zookeeper. For example, if you upgrade from release prior to Kyvos 2023.2 to a release up to Kyvos 2024.1.2 (i.e., when Zookeeper version 3.6.1 was in use and now 3.7.1 is supported).

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.

Upgrading Zookeeper version

  1. Log onto the Kyvos Manager and navigate to Kyvos and Ecosystem > Zookeeper.

  2. Here, select the External option and click the Save It will undeploy Zookeeper.

  3. Once Zookeeper undeployment is complete, select the Managed by Kyvos option and click the Save This will trigger the deploy Zookeeper operation.  

  4. Once Zookeeper deployment is complete, restart all Kyvos services from the Dashboard.

Switching to the previous version of Zookeeper

To access the previous version of the Zookeeper, perform the following steps. 

  1. Add the previous Zookeeper version bundle to the Kyvos Manager repository at kyvosmanagerdata/server/repo/ .

  2. Take a backup of the new version 3.7.1 bundle of Zookeeper at a different location outside the Kyvos Manager repo. This bundle will be necessary for switching to the new version 3.7.1 of Zookeeper.

  3. Update the previous version bundle name in the supportedBundles present in the kyvosmanagerdata/server/repo/metadata.Kyvos/zookeeper.json file by deleting the new zookeeper version bundle name and then redeploy the Zookeeper to restore managed Zookeeper to version 3.6.1.
    For example, to switch to Zookeeper version 3.6.1, before uninstalling the Zookeeper, a key having a value like supportedBundles : [zookeeper-3.7.1.tar.gz] must be updated with supportedBundles : [zookeeper-3.6.1.tar.gz]

Switching to the default non-managed version of Zookeeper

To restore the default non-managed version of Zookeeper on the Kyvos Manager node, which was removed during the uninstallation of Managed Zookeeper, you will need to manually install Zookeeper on the Kyvos Manager node.

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:

    { "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.

    "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.

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

Case 2

In case of upgrade from Kyvos 2023.2, 2023.3, 2023.4 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:

    { "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.

    { "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.

    { "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.

    { "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.

    { "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. 

Important

  • From Kyvos 2023.2 onwards, for AWS, the restoration process for the external repository RDS has been automated, eliminating the need for manual intervention.

  • From Kyvos 2023.2 onwards, for AWS, if Kyvos is using an external repository RDS as its repository, before initiating a Kyvos rollback, ensure that the 'UsedBy' tag with a value of 'Kyvos' is added to the RDS subnet/security group used for creating the database instance, if it has not already been added.

  • In case of a Rollback, the previous state of Kyvos is restored. In case you made any entity-specific modifications like changes to the semantic model design, registered files, users, etc., Kyvos recommends the designers/Admins create a cab as a backup before rollback and import the cab file to the rolled-back version.

  • Process operations cannot be persisted.

  • From Kyvos 2023.1 release onwards, if you roll back to a Kyvos Manager process that supports Derby as its repository, any operations, such as audits, events, or other activities (like users add, import, delete, and update) performed using Kyvos Manager build 2023.1 and onwards will NOT be available when you rollback to a Kyvos Manager release previous to 2023.1.

  • The rollback operation will take some time to initiate.

  • If you roll back the 2023.2 Kyvos Manager build to a version prior to 2023.2, a warning message will display, indicating that the spark distribution update has failed. The spark distribution bundle is only available in the Kyvos 2023.2 release and cannot be accessed in any previous versions.

  • Kyvos rollback to earlier releases not supporting Flexible server:

    • Post Kyvos rollback, configure the single server in Kyvos through the switch repository of Kyvos Manager. The application automatically handles the single server being configured. It must have the same compatible state of the database with the Kyvos release to which rollback is performed.

    • A change in the user name will be required while configuring a single server in the system as it requires appending the server name to the username.

To roll back the cluster deployment to a previous version, perform the following steps.

  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.

Copyright Kyvos, Inc. 2025. All rights reserved.