Goal

Today, the forklift inventory pod emit a mix of JSON and plain-text log lines. The application code (via zap) produces structured JSON logs, but the Gin HTTP framework middleware emits unstructured text lines (e.g., "[GIN] 2026/02/10 - 10:23:57 | 200 | 1.582505ms | 169.254.0.5 | GET /providers/...").

This makes it difficult to parse, filter, and aggregate logs using standard JSON tooling (e.g., jq, Elasticsearch, CloudWatch). Log collectors that expect uniform JSON lines may mishandle or drop the plain-text Gin entries.

After this epic, all log lines emitted by the controller and inventory pods will be structured JSON. Gin request logs and panic recovery logs will follow the same JSON convention as the rest of the application, enabling consistent log parsing, filtering (e.g., jq 'select(.logger == "gin")'), and integration with log aggregation platforms.

User Stories

As a cluster administrator,
I want all log lines from the forklift controller pod to be valid JSON,
so that I can reliably ingest and query them using log aggregation tools without special handling for mixed formats.

As a cluster administrator,
I want to filter HTTP request logs separately from application logs,
so that I can monitor API latency, status codes, and error rates independently.

As a developer,
I want Gin's panic recovery output to be structured JSON with a stacktrace field,
so that I can quickly diagnose crashes without manually parsing unstructured text.

Non-Requirements

• Changing the existing zap logger configuration or log field conventions.
• Adding new log aggregation or monitoring infrastructure.
• Modifying log output for the virt-v2v or other non-controller pods.
• Changing log behavior in development mode (LOG_DEVELOPMENT=true still uses Gin's default text formatters).

  Notes

• <references to existing docs or mailinglists etc>