Resolving Duplicate Namespaces After Migration and Best Practices to Avoid Them

Overview
After a configuration-only migration between environments using the migration tool, duplicate namespaces may appear in the RadiantOne Directory Namespace UI. These typically look like alternate versions of existing namespaces, with underscores or slightly different naming formats.

Environment
Product: RadiantOne FID 7.4.x
Platform: Linux
Area: Directory Namespace / Views / ZooKeeper configuration

Symptoms
Duplicate namespaces appear in the Directory Namespace tab after migration, in both their expected form and an alternate “combined” or underscore-based form.

Root Cause
During setup, the target environment creates a default system-reserved naming context. The import process also brings over older naming contexts representing the same logical areas. When both exist, duplicate namespaces appear in the UI.

Identifying Duplicate Namespaces

  1. Open the FID Configuration Console → ZooKeeper tab.
  2. Go to RadiantOne v2 → [cluster_name] → config → namings.
  3. Look for duplicate naming contexts with:
    • Combined names or underscores.
    • Formats different from the expected naming style.

Removing Duplicate or Incorrect Naming Contexts

  1. In the ZooKeeper tab, navigate to config/namings and enable Edit Mode.
  2. Identify the incorrect or legacy context by comparing it to the system-reserved one.
  3. Delete the duplicate entry.
  4. Restart the FID server(s) and, if applicable, the ZooKeeper ensemble.

If Views Reappear After Deletion

  1. In the ZooKeeper tab, rename the naming file linked to the problematic view.
  2. In the Directory Namespace tab:
    • Disable the problematic view.
    • Delete the unwanted namespace entry.
      After this cleanup, duplicates should no longer return.

Why Older Environments Cause Duplicates
Older RadiantOne versions used different naming conventions. When imported into newer environments with system-reserved contexts, both are treated as separate entries, resulting in duplicates.

Recommended Migration Approach
To prevent duplication when migrating:

  • Use resource-export and resource-import instead of individual .dvx exports.
  • Migrate at the view or root naming context level to include all dependencies.

Best Practices

  1. Run resource-traverse to review dependencies (data sources, .dvx, .orx, root contexts, JARs).
  2. Use resource-export to package the view and dependencies into one ZIP.
  3. Import it with resource-import --cross-environment to adapt configuration properly.

For Large Migrations
Avoid exporting each .dvx manually:

  • Identify top-level views or root contexts to group related views.
  • Use resource-traverse to confirm dependencies.
  • Run resource-export once per group, then import the resulting ZIPs on the target environment.

Exporting a Specific Child Namespace
When using the -name parameter for a child namespace, the export includes:

  • The selected child namespace.
  • All shared dependencies (joins, shared data sources, schemas, topologies).
    This behavior ensures needed components are included automatically.

Using Skip Options
Use resource-traverse first to verify dependencies.
Apply -skip only for resources that are known to be unnecessary (e.g., obsolete namespaces).
Do not skip:

  • Active data sources
  • Required schema files
  • .orx or .dvx files in use
  • Parent namespaces

Skipping required components can result in incomplete or broken views.

Important Limitations
Migration commands do not include all wizard artifacts. Some configurations, such as persistent caches, may need manual reconfiguration after import.

Operational Checklist

  • Check config/namings in ZooKeeper for duplicates and delete legacy entries.
  • Restart FID and ZooKeeper after cleanup.
  • For views that reappear, rename the ZooKeeper file, disable the view, and delete the unwanted entry.
  • For future migrations, use resource-traverse, resource-export, and resource-import --cross-environment.
  • Avoid per-.dvx migrations for large sets.
  • When exporting child namespaces, expect shared dependencies.
  • Use -skip cautiously.
Was this article helpful?
0 out of 0 found this helpful

Comments

0 comments

Please sign in to leave a comment.

Articles in this section

See more