Configset templates

Fusion uses Solr configset templates to create collections with predefined schemas and configurations optimized for different purposes. When you create a new collection in Fusion, the system clones one of these templates and customizes it for your specific collection. This ensures each collection has its own independent configuration that you can modify without affecting other collections.

​

Template naming convention

All Fusion configset templates follow a naming convention that begins with _fusion_:

• _fusion_default - Primary application collections
• _fusion_signals - Signals collections
• _fusion_query_rewrite - Query rewrite collections
• Additional templates for specific Fusion features

​

Template ownership and versioning

Different Fusion deployment types may use different implementations of the same template. For example, the _fusion_default template in Lucidworks Search (managed Fusion) differs from the template in self-hosted Fusion deployments. Each configset template includes a special _fusion_owner.txt file that identifies which Fusion component manages that template. This file contains a single line identifying the owner, such as fusion-solr or fusion-solr-managed.

​

Purpose of _fusion_owner.txt

The ownership file serves two critical functions:

1. Tracks template source: Identifies which docker image provided the configset template.
2. Protects customizations: Prevents Fusion upgrades from overwriting customized configsets.

​

How templates work during installation and upgrades

When you install or upgrade Fusion, a bootstrap process copies configset templates from docker images into ZooKeeper, where Solr can access them. The bootstrap script (/opt/lucidworks/sync-configsets-with-zk.sh) follows these rules:

1. Connects to ZooKeeper and creates a lock to prevent concurrent modifications.
2. Loops through all configset templates in the docker image.
3. For each template:
   • If no configset exists in ZooKeeper with this name, the template is copied.
   • If a configset already exists in ZooKeeper:
     • Matching ownership: If the _fusion_owner.txt file matches, the template replaces the existing configset.
     • Mismatched ownership: If the _fusion_owner.txt file doesn’t match or is missing, the template is skipped and a warning is logged.

​

Customizing configset templates

If you need to customize a Fusion configset template for your self-hosted deployment:

1. Make your modifications to the configset in ZooKeeper.
2. Either:
   • Option A: Remove the _fusion_owner.txt file to prevent any future upgrades from replacing your customizations.
   • Option B: Modify the _fusion_owner.txt file to contain a different value (not matching the Fusion docker image owner).

​

Viewing template ownership

To check which component owns a configset template in your deployment:

1. Connect to ZooKeeper.
2. Navigate to /configs/<configset-name>/.
3. Read the contents of the _fusion_owner.txt file.

The file contains a single line identifying the owner, which corresponds to the Fusion docker image that manages this template.

​

Troubleshooting

​

Warning: Configset skipped during upgrade

If you see warnings in the Fusion logs about skipped configsets during an upgrade, this indicates:

• A configset exists in ZooKeeper with a template name (starting with _fusion_).
• The _fusion_owner.txt file is either missing or contains a value that doesn’t match the docker image.

This is normal behavior when you’ve customized templates. Fusion preserves your customizations rather than overwriting them.

​

Dry run mode

To preview what the bootstrap script would do without making changes, you can run it in dry run mode by setting the DRY_RUN environment variable to true. The script will log all actions it would take without modifying ZooKeeper.