Troubleshooting

Using custom SSL certs to connect to CDSW/CML workspaces

The migration script internally uses cdswctl which relies on systemwide configured certificates to establish connection with source/target workspaces. It must be ensured that SSL certs belonging to both source and target workspaces(if applicable) should be set up properly.

Set up for Linux(Ubuntu/Debian)

1. Copy your CA to dir /usr/local/share/ca-certificates/. Please ensure that the CA file is in .crt format.
2. Use the command: sudo cp foo.crt /usr/local/share/ca-certificates/foo.crt
3. Update the CA store: sudo update-ca-certificates .

Set up for MacOS

1. Navigate to Finder > Applications > Utilities > Keychain Access.
2. Select System in the left-hand column.
3. Open File > Import Items and import the certificate files into the System keychain.
4. The certificate should now show with a red X. That means it is entrusted. To provide trust, double-click the certificate. Under Trust, change the setting at the top (When using this certificate) to Always Trust. Note: For the utility to run with custom certs on MacOS, the user would need to add the cert in keychain as well as pass the cert (ca_path) inside export-config.ini & import-config.ini file. The reason being python is not able to pick up system-wide certificates in MacOS.

Retrying a successful/failed migration

The utility has been meticulously designed to resume the export/import operation from the exact point where it left off in the event of failures.

Project files The utility employs rsync to facilitate the migration of project files. When the export/import command is rerun, it will synchronize the project files from the source to the destination.

Project settings/artifacts During a rerun, the project settings/artifacts (model/job/application) that have already been migrated will not be updated. Instead, only the missing artifacts in the target workspace will be migrated. This behavior aligns with the resume operation support in case of failures. The utility is not designed to support a sync operation between the source and target projects. If you wish to update the project that has already been migrated, it is advisable to delete the project in the target workspace and then rerun the migration.

Running the tool as a background process

There might be cases where the tool might be required to run as a separate process detached from the terminal. In that case please use this command on your linux/mac machine: nohup <complete CLI command> > <stdout-file> 2> <stderr-file> &

This will print out the Process ID(PID) as well as append the logs to the mentioned stdout and stderr file locations.

The process could be interrupted by sending a SIGINT to the PID returned. Please use kill -INT <PID> in that case.

SSH Timeout Issues

There might be a possibility that SSH timeout can happen during Project Migration (it can be during migration,creation of model/session/job ). In that case, please increase the ServerAliveInterval in ~/.ssh/config of bastion-host . Below is the sample command to increase the ssh timeout in ~/.ssh/config

  ServerAliveInterval 60 
   ServerAliveCountMax 30

RSync Connection Closed Issues at Bastion Host

There might be a possibility that Bastion's Rsync might halt with connection broken error. In that case, make sure rsync version is upgraded to 3.X as rsync versions >= 3.X has got retry functionality inherently implemented when halted.