Bug in the docker container image ignition:8.* preventing new volume mounts seeding properly

Observed issues deploying on Kubernetes with persistent volumes. Documents indicate mounting volumes to /usr/local/bin/ignition/data however in doing so, this effectively hides existing clean templates which are presented in the same folder. The result is a failure to launch as certain clean template files cannot be found (being masked out by the mounted volume). We see errors like this:

cannot stat '/usr/local/bin/ignition/data/gateway.xml_clean': No such file or directory

In reviewing the docker-entrypoint.sh script in the container I can confirm that this is designed well to deal with a fresh mounted volume and seeding it with a clean template folder. It functions as it should but providing the mounted volume is under /usr/local/bin/ignition/data and the default clean template data folder is under /usr/local/bin/ignition/data_clean. This should really only require a few lines to change in the Dockerfile.

Note, if an ephemeral instance is required (no volume mounts), then this works fine. The entrypoint script will initialise a new running instance with the default clean template files correctly.

A hack workaround I needed to implement is to mount to /data and then override the default entrypoint script run to be replaced with the following:

  # Move the default clean template data folder to where its supposed to be
  mv ${IGNITION_INSTALL_LOCATION}/data ${IGNITION_INSTALL_LOCATION}/data_clean;

  # Create a symlink /usr/local/bin/ignition/data pointing to our persistent
  # volume
  ln -s /data ${IGNITION_INSTALL_LOCATION}/data;

  # Resume original entrypoint to do the rest
  docker-entrypoint.sh;

Creating this topic to share the workaround and to hopefully chase up a simple fix.

Hey @sean.liew, good analysis of the issue! While I don't have all the past context for why this is the way it is, it seems to be the same root cause as the Docker bind-mount scenario discussed here - the volume mount masks the clean template files.

The official Ignition Helm Chart handles this exact scenario in Kubernetes using an init container to seed the persistent volume before the main container starts. This is the Kubernetes-native pattern we recommend. You can see the specific implementation here in the StatefulSet template.

If you're building custom manifests and your symlink workaround is working well, that's a valid solution. Otherwise, the Helm chart handles this for you automatically.