We are glad that you are reading this page because that means you’re already convinced of the power of Syndeia 3.3 with all the cool, new features and you’ve either already installed Syndeia Cloud 3.3, or are in the process of doing so, and you are wondering what happens to the data that you’ve painstakingly created with Syndeia Cloud 3.2? Well, since Syndeia 3.3 was such a big release, a lot has changed behind the scenes, and that means, unavoidably, you’ll have to migrate your data so that it complies with the data format expected by Syndeia 3.3. This page explains what the entire migration process entails and the steps to successfully transition to Syndeia 3.3.

...

1. Syndeia 3.2 installed and running on a server. Syndeia 3.2 requires the Cassandra database and a syndeia keyspace to hold 3. 2 data. This is our source server (database).

2. Syndeia 3.3 installed and running on a server. Syndeia 3.3 also requires the Cassandra database and syndeia_cloud_store & syndeia_cloud_auth keyspaces to hold 3.3 data. Additionally, Syndeia 3.3 uses JanusGraph behind the scenes, which requires additional syndeia_cloud_graph & syndeia_cloud_graph_config keyspaces to hold graph data. This is our target server (database).The superuser and the setup steps should’ve already been run on the Syndeia 3.3 server.

3. The migration process requires an additional syndeia_cloud_devops keyspace on the target 3.3 server. The schema/gen-schema.cql file contained in this utility has the required CQL statements to create the schema and tables. Please run this utility from a CQL shell or using a tool similar to DataStax Devcenter. This keyspace has three sets of tables - a pre_stage_* set, a migrate_stage_* set, and a duplicate_* set of tables.

4. Download the Syndeia-Migration-3.3 utility -Utility from the Syndeia Cloud download page that you were provided with your Syndeia 3.3 licenses.

5. Download the Syndeia, 3.3 Standalone client from the Syndeia client download page that you were provided with your Syndeia 3.3 licenses.

6. The user who is doing the migration should be an admin user on Syndeia Cloud 3.2 and 3.3. Additionally, he the user should have the credentials of each external repository (server) because one of the steps requires that you run the Syndeia dashboard and connect to each of the repositories using your credentials. Also, this user should have permission to view all the data in any of the external repositories (servers)with permission to read all the data in that repository that was connected using Syndeia. For example, if Syndeia Cloud 3.2 has Syndeia relations to Jira issues, then the admin running the migration utility should have permissions to access the given Jira project and the issues. This is required during the enhancement phase of the migration.

...

Overview of Syndeia Cloud 3.2 → 3.3 Migration Process

...

1. Replicating (copying) data from the source (3.2) database to the migration (pre_stage) _* tables

2. Enhancing data in pre_stage_* tables by connecting to Slim (so that it is in a form which can be loaded in 3.3external repositories (e.g. Jira and Jama)

3. Staging data from pre_stage_* tables to migrate_stage_* tables

4. Loading data in from migrate_stage_* tables to target (3.3) database tables by calling the server using Syndeia Cloud API for data from migrate_stage tables.3.3 API

The details of the various stages are as follows:

• Replicate - first copy all data from the source (3.2) database to pre_stage_* tables (note that the 3.2 database has only 4 tables for repositories, containers, artifacts, and relations). Once the data has been copied from the 3.2 server to the pre_stage_* tables, we can safely disconnect from the 3.2 server and its role ends there. When the data is copied into the corresponding pre_stage_* tables, the value of the status column is set to -2.

• Enhance - In 3.3, we also have type related tables, which were not there in 3.2. Hence, in this step, we also have to connect to a running instance of Slim. Using this running instance, we can get external repository types and internal relation types (which is like hard-coded data, made up by us) which we first insert in pre_stage tables. Then for containers and artifacts, we need to connect to the actual repositories, get the type information for each of the container and artifact, and populate the corresponding pre_stage tablesvarious external repositories (e.g. Jama, JIRA, etc.) to get the “type” data for containers and artifacts in the external repositories. Once, all data has been enhanced, we modify the value of the status column to -1.

• Stage - Once all the data has been enhanced, we just insert all data from pre_stage_* tables to migrate_stage_* tables. During the insertion, we first update After the enhanced data has been copied from the pre_stage_* tables to the migrate_stage_* tables, the value of the status column to 0 in the pre_stage_* tables and then set this same value 0 in migrate_stage tables (because the final part of the migration process only picks up those records whose status is 0)_* tables is set to 0.

• Load - Load all the data from various migrate_stage_* tables (whose status is 0) , create the corresponding *CreateForm(s), or *UpdateForm(s) for each piece of data and call the relevant POST / PUT Cloud APIs on the Syndeia 3.3 serverto Syndeia Cloud 3.3 using its REST API.

...

Syndeia Cloud Migration Utility

...

The conf/application.conf file contained in this utility has to be supplied with the correct values for the source/target databases and whether the source server is LDAP enabled or not. It should also specify the Syndeia 3.3 server IP address and the port and the sign-in username and password for signing in to Syndeia Cloud 3.3. The username/password for Syndeia Cloud 3.3 should be for an admin account (preferably , this user should have admin rights so that he may create/update any data he likes) super.user) that has ALL the permissions, including user management. The relevant sections are -:

target {
  db {
    host = "localhost",
    username = "cassandra-username",
    password = "cassandra-pwd",
    port = 9042
    keyspace = "syndeia_cloud_devops"
  }
}

source {
  db {
    host = "localhost",
    username = "cassandra-username",
    password = "cassandra-pwd",
    port = 9042
    keyspace = "syndeia"
  }

  server {
    isLdapEnabled = false
  }
}

sign-in {
  username = "super.user"
  password = "super.user.pwd"
}

server {
  ip-address = "localhost"
  port = 9000
}

api {
  default-wait-duration = 2
}

Similarly, we need to update a few lines in the bin/syndeia-migration.bat file (for Windows, or the bin/syndeia-migration file , for Linux / Mac). The following is an example of changes made to the bin/syndeia-migration.batfile ; please do the for Windows. Make similar changes in bin/syndeia-migration file for Linux / Mac.

set CFG_OPTS=-Xms1G -Xmx8G
set _JAVA_PARAMS=-Djava.library.path=lib -Dconfig.file=conf/application.conf
set "APP_CLASSPATH=%APP_LIB_DIR%\*;%APP_LIB_DIR%\com.intercax.syndeia-migration-3.3.jar"

...

bin\syndeia-migration.bat -e Repositories -s Repositories -l Repositories

Step 6 - Launch the Syndeia 3.3 Standalone client and connect to

...

Syndeia Cloud 3.3 (using admin credentials) and each of the external repositories

...

.

When you launch Syndeia 3.3 Standalone , you’ll see an empty screen because no Syndeia Projects exist yet. So create a Syndeia Project client, you may need to provide credentials for your Syndeia Cloud 3.3 server. Click on the Settings button and specify the hostname, port, admin username, and password for your Syndeia Cloud 3.3 server. Click Apply.

...

Now, you will see a window for selecting or creating a Syndeia Cloud container (project). No containers are listed at this point because no data has been created in Syndeia Cloud 3.3 after installation. Create a new Syndeia container (project) for migration with the following values:. This is a sample project which can be deleted later once this migration activity is complete.

• Key: MIGCONT

• Name: Migration container

• Description: Container for migrating data from Syndeia 3.2 to 3.3, and press Create New button (as shown below).

...

NOTE: This is a sample project which can be deleted later once this migration activity is complete.Once you click “Create New” Create New this Syndeia project should be created.

...

Double-click the newly created Syndeia project and the Syndeia dashboard will launch. It will show all the repositories which were migrated from Syndeia 3.2 in the Repository Manager tab. Click on each of the repositories and you might be prompted to enter the password. If the prompt does not appear, then right-click each of the repositories and press “Update…” and enter your credentials there. Once you’ve entered the credentials for all the repositories, you should expand each of the repositories by clicking the “right-pointing triangle” icon. The repositories should look like the following:

...

...

Close Syndeia Standalone utility after connecting to all the repositories.

Step 7 - Enhance containers and stage container types & containers

...