[gaurav]

None of the webserver.SETTINGS in the config files has ever reached Tornado: get_app() passed them positionally, into Application's default_host parameter. This PR makes them take effect, with debug mode off in the deployment, and cleans up the configuration around them. docker/configuration/config.json was a full copy of config.default.json because the --conf file was merged with dict.update(), which replaces any section it touches; it is now merged section by section, so the deployment file holds only what the deployment changes.

No issue tracks this; it came out of reading the config while reviewing #42. Nothing was leaking before: the deployments ran with Tornado's defaults, and a 500 never carried a traceback. The debug-off setting matters from this PR on, because the old deployment config asked for debug mode, which puts the traceback and exception message in every 500 body.

Calls worth overruling

• Tornado's static_path is no longer set. load_configuration() added it with static_url_prefix: "/", and once settings apply, Tornado turns that into a catch-all route ahead of every handler, so every API path answers 404. build_handlers() already serves / and /webapp/, and a comment at the old spot says why not to add it back.
• The development default keeps debug mode and autoreload on, as it always asked for; they now actually apply when running without --conf, including in the integration tests that build the app from the default.
• The Helm env vars are removed, not wired in. The chart set ES_HOST, OPENTELEMETRY_ENABLED and PORT, which the app never read. PORT is 8000, where Caddy listens in front of the app (on 9001), and the real ES_HOST is in ITRB's values-ci.yaml, outside this repo, so I can't confirm it is a URL the client accepts. Driving these from the chart would be a follow-up for someone who can see values-ci.yaml.
• ES_INDEX and ES_ALIAS are repeated in the deployment file though they match the default, so a change to the default for local development can't silently repoint production; the price is that a rename touches both files. Everything else the deployment leaves out follows the default. The README's Configuration section records this.
• The image takes its config files from the builder's clone of NODENORM_BRANCH, like its code, instead of from the build context, so the two always come from the same commit, and docker-compose.yml (context: the repo root) builds again. A local config edit now needs pushing to a branch before an image picks it up, as code edits already do.

What's here

• merge_configuration() in namespace.py; lists are still replaced whole.
• docker/configuration/config.json names only the in-cluster Elasticsearch host, index and alias, telemetry on with the cluster's Jaeger collector, and debug and autoreload off.
• tests/test_configuration.py tests the merge, checks that the deployment file names no setting the default lacks (so a misspelt key fails), and builds the app through get_app() from the deployment config to check the settings arrive and the routes still answer.
• The Dockerfile no longer copies config.default.json to an unused configuration/default.json; docker-compose.yml's build args (written ARG NAME=value, so never applied) and port mapping (to container port 9000, where nothing listens) are fixed; the README has a Configuration section.

One commit, "Turn off Tornado debug mode in the deployed service", says the deployments served tracebacks; they didn't, and the later commit "Pass the webserver settings to Tornado as keywords" says so.

This conflicts with #42 in two easy places: #42 adds ^/openapi\.json$ to OPENTELEMETRY_EXCLUDED_URLS in config.json, which this PR removes the list from (keep the default's line, drop the config.json one), and both add a README section at the end (keep both).

Verification

On 78d7404, every test passes except the four set-ID and normalized-node integration tests that need the su10 host. The image, built from the pushed branch with docker/ as the context as Jenkins does, ran against a local Elasticsearch 8.19 container answering to the in-cluster hostname: /status, /, /version and /webapp/openapi.json answered 200, and a 500 showed no traceback; the same image with main's debug-on config.json mounted showed the full traceback. docker compose build succeeds from the repo root, where main's Dockerfile fails, and helm template renders the chart.

🤖 Generated with Claude Code