Troubleshooting VIP Authentication Hub Dataseed Job Failures During Version Fallback or Multi-Cluster Deployment

Products

• Symantec Identity Security Platform - IDSP (formerly VIP Authentication Hub)

Issue/Introduction

During a version fallback (e.g., from 3.4.6 to 3.3.5) or when deploying an existing version of Symantec Identity Security Platform (IDSP) to a new EKS cluster while using the same infrastructure database, the Dataseed Job may fail with a NonUniqueResultException or missing Kubernetes secrets (e.g., isk keys).

Environment

Any supported IDSP releases 

Cause

Duplicate Data: The Dataseed job may encounter existing records in the database if it is run against a DB that was already initialized, leading to errors like Query did not return a unique result: 2 results were returned.
Missing Secrets: If ssp.featureFlags.dataseed.enabled is set to false, the job does not create the necessary Kubernetes secrets (e.g., hazelcast-ssp-keys-isk, sspdev-ssp-db-pxc), which are required for the flow to work.

Resolution

Depending on the scenario, use one of the following approaches:

1. Version Fallback/Rollback

• Preferred Method: Use helm rollback. This keeps the database at the current version and avoids re-running the Dataseed job.
• Uninstall/Reinstall Method: If performing a clean install of the older version:
  • Set --set ssp.featureFlags.dataseed.enabled=false.
  • Manual Step: You must manually retrieve the isk/SSL secrets from the primary/original cluster and apply them to the new cluster before deployment.

2. Multi-Cluster/DR Deployment (Same Version)

If deploying the same version to a new cluster (e.g., for an EKS upgrade from 1.32 to 1.34) using the existing database:

• Option A (Read-Only DB): Use --set ssp.global.drSite=true along with --set ssp.featureFlags.dataseed.enabled=true. In drSite mode, the database operates in read-only mode (preventing schema updates), but the Dataseed job will still create the necessary isk secrets.
• Option B (Manual Secrets): Set --set ssp.featureFlags.dataseed.enabled=false and manually copy the secrets from the original cluster to the new one.

 

Additional Information

For detailed steps on DR deployment and secret management, refer to the TechDocs: DR Deployment Steps.