I am encountering a challenge with the dataone-indexer Helm chart when trying to restore a system from backups during failover situations. Specifically, I want to start with fresh PersistentVolumeClaims (PVCs) while preserving the existing PVCs, simply by naming new ones. This is currently difficult due to the way PVC names are tied to StatefulSets.
Context:
-
In the dataone-indexer.solr StatefulSet:
- Each Pod derives its hostname from the StatefulSet name and the Pod ordinal index.
- This naming convention extends to PVC names, making it cumbersome to start with fresh PVCs without impacting the StatefulSet.
-
Kubernetes provides two potential options to alter naming:
- Option 1: Change the ordinal index (see StatefulSet Ordinal Index).
- Option 2: Use
fullnameOverride or nameOverride for the Solr chart.
While Option 2 is supported in the Bitnami Solr chart, implementing it introduces additional complexity:
- The Solr hostname in the
dataone-indexer chart must be overridden accordingly using idxworker.solrHostName and solr.nameOverride.
- Upon restoration, I currently use PVCs with a timestamp in their name (e.g.,
solr-20250409). This means the Solr pod names also change to <release>-solr-20250409-<N>. While this works, it is not ideal.
Proposal:
To streamline this process and address the issue:
- Improve the Helm chart to allow flexible PVC naming when starting from fresh PVCs.
- Enhance the
idxworker.solr.hostname helper function to dynamically adapt to the overridden Solr chart name, ensuring compatibility with nameOverride or fullnameOverride.
This improvement would simplify failover restorations, eliminate tedious manual configuration, and provide a more seamless experience.
Additional Notes:
- A similar issue exists with RabbitMQ, where PVC and pod naming conventions make failover restoration challenging. Addressing this across the board would be highly beneficial.
- The following is the current way to override the names and thus change the PVC names. Ideally, it would nice to just provide
solr.nameOverride and have the idxworker.solr.hostname helper function to the right thing with it.
# dataone-indexer - Dataone Indexer chart values
dataone-indexer:
# @param metacat.dataone-indexer.image - Dataone Indexer image
solr:
## @param nameOverride String to partially override common.names.fullname template (will maintain the release name)
##
nameOverride: "solr-20250409"
idxworker:
## @param idxworker.solrHostname hostname of the solr service to use
## Leave unset (solrHostname: "") to automatically populate when using solr bitnami subchart
##
solrHostname: "ess-dive-solr-20250409-headless"
- There may be other ideas to start from a fresh PVC. This is just the one I have tried.
I am encountering a challenge with the
dataone-indexerHelm chart when trying to restore a system from backups during failover situations. Specifically, I want to start with fresh PersistentVolumeClaims (PVCs) while preserving the existing PVCs, simply by naming new ones. This is currently difficult due to the way PVC names are tied to StatefulSets.Context:
In the
dataone-indexer.solrStatefulSet:Kubernetes provides two potential options to alter naming:
fullnameOverrideornameOverridefor the Solr chart.While Option 2 is supported in the Bitnami Solr chart, implementing it introduces additional complexity:
dataone-indexerchart must be overridden accordingly usingidxworker.solrHostNameandsolr.nameOverride.solr-20250409). This means the Solr pod names also change to<release>-solr-20250409-<N>. While this works, it is not ideal.Proposal:
To streamline this process and address the issue:
idxworker.solr.hostnamehelper function to dynamically adapt to the overridden Solr chart name, ensuring compatibility withnameOverrideorfullnameOverride.This improvement would simplify failover restorations, eliminate tedious manual configuration, and provide a more seamless experience.
Additional Notes:
solr.nameOverrideand have theidxworker.solr.hostnamehelper function to the right thing with it.