When a new Azure Container App revision is created, OpenSearch does not recognize the existing data stored in the mounted Azure File Share, even though:
The Azure File Share contains the existing OpenSearch data.
The volume mount configuration remains unchanged.
The mount path remains unchanged.
No environment variable or OpenSearch configuration changes are made.
As a result, OpenSearch appears to initialize a new cluster and generates a different cluster UUID.
However, after restarting the Container App revision, OpenSearch successfully recognizes the existing data and loads the original cluster state.
@arul This sounds like a race condition between Azure’s file share mount and OpenSearch’s startup sequence, rather than an OpenSearch bug.
When Azure Container Apps creates a new revision, the container starts and OpenSearch initializes before the Azure File Share mount is fully ready. OpenSearch sees an empty data directory and correctly bootstraps a fresh cluster with a new UUID. By the time you manually restart the revision, the file share is stable and OpenSearch finds the existing cluster state.
I would recommend to use a script as the container entrypoint in your Azure Container App revision configuration. This ensures OpenSearch only starts once the mounted volume is confirmed accessible.
@Anthony Thanks for the explanation. After further investigation, it does appear to be related to a race condition.
The root cause in my case was that the Azure File Share was being accessed by more than one Container App revision/instance. To ensure OpenSearch correctly recognizes the existing cluster state, all revisions or instances using the same mounted data volume must be stopped before creating or starting a new revision. Once I ensured that only a single revision/instance was accessing the mounted Azure File Share, OpenSearch consistently recognized the existing data and retained the original cluster UUID.