[HWORKS-2954] Replace the OpenSearch deployment log history with HopsFS archives

[jimdowling]

Docs for HWORKS-2954. Companion to hopsworks-ee#3165, hopsworks-front#2004, hopsworks-api#1052, hopsworks-helm#2106, docker-images#882 and model-serving-webhook#80.

https://hopsworks.atlassian.net/browse/HWORKS-2954

Why

Deployment logs no longer go through OpenSearch. Live logs are read from the running component through the Kubernetes pod-logs API, and history is archives that each instance writes to the project's Logs dataset from inside its own container.

Both troubleshooting guides still described the removed model: they told users to click a See logs button that opened OpenSearch Dashboards, and to filter records by container_name, serving_name, model_version and friends. None of that exists any more.

What changed

• user_guides/mlops/serving/troubleshooting.md and user_guides/projects/python-deployment/troubleshooting.md (near-duplicates, kept that way): rewrote the transient and historical log sections against what the product does now. Transient logs gain the UI log viewer, and a note that stdout and stderr arrive interleaved because Kubernetes merges them at the container runtime. Historical logs are now described as per-instance HopsFS archives, including the naming convention, the log_history_limit cap and why it exists, and the fact that an instance removed by scale-to-zero still leaves its logs behind.
• New Configuring disk logging section: the setting that governs whether history is written at all, with the on and off behaviours, the per-model-server defaults, and why there is no single-instance mode. A one-replica mode existed while this was being built and was dropped during review: all instances of a deployment share one pod template, so electing one writer leaves the others paying for a sidecar they never use.
• Code section: added tail_logs and download_logs, since a single snapshot is no longer the only thing the client can do.

Second review round (2026-08-08): disk logging was restricted to Python deployments (the privileged HopsFS sidecar is only Kyverno-exempt on model-server: python pods), so both pages now say TensorFlow Serving and vLLM do not support the setting and that the API rejects it.

setup_installation/admin/monitoring/services-logs.md is deliberately untouched. Platform-service logs still flow to OpenSearch; only the workload routes were removed, so that guide is still accurate.

Checks

markdownlint-cli2 clean on both pages. snakeoil at the CI rule set converges: after its run plus the trailing-blank cleanup the repo is diff-clean, which is the gate hopsworks-docs snakeoil enforces. The download_logs example uses a context manager so it passes SIM115.

Ships with the code PRs, which are all out of draft.

🤖 Generated with Claude Code

[jimdowling]

Review round 16.10 (d3f6fee): the tail_logs example called the generator without iterating it, so the snippet as written did nothing. Both troubleshooting pages now iterate and print the yielded chunks, and the prose says the method returns a generator. Fences re-normalized with the repo's snakeoil pass.