Docker.D Reload Option

[turnbullerin]

Hi!

I'm working on a few features for ERDDAP and one of them I'd love to support is a method to push a new dataset live without restarting the docker container. ERDDAP supports this via reloading the datasets.xml file with a flag that is set. I was wondering if you would accept a patch that would add a script that can be run via docker exec to trigger a reload of the configuration from docker.d

This script would

1. Rebuild the datasets.xml file from datasets.d (including making a backup)
2. Validate that the datasets.xml is valid XML (at a minimum, ideally we might integrate the linting tool here?)
3. Place the reload flag file in the correct location to trigger a reload of the datasets

Essentially then you can trigger a refresh without rebooting the server with a command like docker exec datasetsd-rebuild. I might also propose a later extension to activate or deactivate a dataset which would be something like docker exec datasetsd-activate DATASET_UUID that would find the <dataset> tag in the datasets.d, update the active flag appropriately and rebuild the datasets for you.

Of note, my use case is that I am hoping to automate generation of dataset tags from our metadata database (efforts are going well so far) and to then automate the push to a staging environment (for testing) and a production environment. Having this staging step mitigates some of the danger of an invalid tag (especially if we integrate the linting tool, but doing a manual deployment of many datasets would be annoying. This command would allow us to deploy these files and load them seamlessly.

[srstsavage]

Hello! Overarching comment: PRs are always welcome!

If you haven't already reviewed recent changes to datasets.d.sh, there are a few PRs that were merged just a few days before this issue that implement bits of what I think you're after:

#66
#67

Specifically:

• datasets.d fragments are now run through xmlstarlet to remove xml declarations and hopefully detect xml problems/lint (code)
• datasets.d.sh is now more flexible in its execution via getopts flags (code), so you can do things like docker exec erddap /datasets.d.sh -r -w after adding new datasets to datasets.d to regenerate datasets.xml and automatically set refresh flags for any dataset ids in the new datasets.xml that aren't present in the running ERDDAP config

The code which makes a backup of datasets.xml before generating a new one currently lives in the docker entrypoint.sh and is only executed once on container startup, but I have no problems with that logic moving into datasets.d.sh if you'd like to PR it, definitely makes more sense there!