Date of Release: January 2023
Resolved Issues
JIRA ID | Issue |
|---|---|
IPD-20087 | The Clustering columns are missing in the Target BigQuery table. |
IPD-20022 | Despite disabling the dataset creation in the pipeline configuration, the pipeline still creates the schema. |
IPD-19943 | There is no provision to configure the disk space for the Dataproc clusters. |
IPD-19929 | In few scenarios, Upgrading from 5.3.0 to 5.3.0.5 crashes the Ingestion service. |
IPD-19945 | Infoworks does not fetch the correct datatypes for the CDATA sources. |
IPD-19821 | When service credential used in BigQuery target is different than service credentials used to create environment , sync to target fails with “Invalid JWT Signature” error. |
IPD-19766 | For BigQuery export files, Sync to Target is failing when the table schema contains array type. |
IPD-19853 | If number of characters in table name exceed 27 characters, then export to teradata is failing with "table_name_temp already exist" error. |
IPD-19751 | Infoworks does not disable query caching while fetching schema from BigQuery. |
IPD-19815 | There are incorrect log messages in Sync to Target for teradata job in 5.3. |
IPD-19474 | The API POST call to Pipeline Config-Migration fails with generic error. |
IPD-19545 | The list of data connections and GET data connections APIs are accessible only to Admin users. |
IPD-19542 | When running ingestion on BigQuery environment, error table is not getting created on BigQuery dataset if the source has only one error record. |
IPD-19339 | Despite cluster creation getting completed, the Creating Cluster timer duration keeps increasing. |
IPD-19663 | The Workflows were failing due to the request timeout. Hence, they go directly to failed state without executing any of the tasks. |
IPD-19701 | The API call to trigger Sync to Target for the table group configured with target data connection fails. |
IPD-19753 | For JSON and streaming sources, if CDC data has column with empty values, it is marked as an error record. |
Upgrade
For upgrading from 5.3.0 to 5.3.0.8, execute the following commands:
Step 1: Use the deployer to upgrade from 5.3.0 to 5.3.0.8
Step 2: Goto iw_home/scripts folder of the test machine.
Step 3: Execute the following command:
rm update.sh
Step 4: Download the update.sh
wget https://iw-saas-setup.s3.us-west-2.amazonaws.com/5.3/update.sh
Step 5: Give update.sh executable permission
chmod +x update.sh
Step 6: Update the package to the hotfix sourceiw_home/bin/env.sh
./update.sh -v 5.3.0.8-ubuntu2004
Rollback
To go back to previous checkpoint version:
Step 1: In a web browser, go to your Infoworks system, scroll-down to the bottom, and click the Infoworks icon.
Step 2: The Infoworks Manifest Information page opens in a new tab. Scroll down and check the Last Checkpoint Version.
Step 3: ssh to Infoworks VM and switch to {{IW_USER}}.
Step 4: Initialize the variables in the bash shell.
full_version= 5.3.0.8
unpatched_version=$(echo $full_version | cut -d "." -f 1-3)
major_version=$(echo $full_version | cut -d "." -f 1-2)
previous_version=<Previous Version> # Last Checkpoint Version from step 1
os_suffix=<OS Suffix> # One of [ ubuntu2004 amazonlinux2 rhel8 ]
Step 5: Download the required deployer for the current applied patch.
https://iw-saas-setup.s3-us-west-2.amazonaws.com/${major_version}/deploy_${unpatched_version}.tar.gz
Step 6: Execute the SCP command for the above mentioned files to the following path.
${IW_HOME}/scripts/.
Step 7: Extract the deployed tar file in case it does not exist.
cd ${IW_HOME}/scripts
[[ -d iw-installer ]] && rm -rf iw-installer
tar xzf deploy_${unpatched_version}.tar.gz
cd iw-installer
Step 8: Initialize the environment variables.
source ${IW_HOME}/bin/env.sh
export IW_PLATFORM=saas
Step 9: Run the Rollback command.
./rollback.sh -v ${previous_version}-${os_suffix}