fix(chart): support HostTailer namespaces

[vyncint]

Summary

• allow each logging.hostTailers.instances entry to set metadata.namespace
• preserve the existing release-namespace behavior when namespace is omitted
• document the per-instance value in values.yaml

Closes #2215

Testing

• helm lint --strict charts/logging-operator
• rendered the HostTailer template with and without an explicit namespace
• make check

[Copilot]

Pull request overview

This PR updates the Helm chart to allow each logging.hostTailers.instances entry to optionally set metadata.namespace on generated HostTailer CRs, while preserving the existing Helm behavior (resources go to the release namespace) when namespace is omitted.

Changes:

• Add optional per-instance metadata.namespace rendering in the HostTailer template.
• Document the new per-instance namespace value in values.yaml.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
charts/logging-operator/values.yaml	Documents the new per-instance namespace value for HostTailers.
charts/logging-operator/templates/logging/hosttailers.yaml	Conditionally renders metadata.namespace for each enabled HostTailer instance.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[csatib02]

@vyncint,

Have you had the chance to test this change out manually?

[vyncint]

Not on a live cluster yet — so far only template rendering (an instance with namespace emits it in the HostTailer metadata; without it, the resource falls back to the release namespace). I'll deploy to a kind cluster, confirm the operator reconciles a HostTailer in a non-release namespace, and report back.

[vyncint]

Tested end-to-end on a clean kind cluster — installed the operator from this PR's chart and confirmed the HostTailers actually reconcile, not just render.

Environment and setup commands

$ kind create cluster --name lo-test
$ kubectl get nodes
NAME                    STATUS   ROLES           AGE   VERSION
lo-test-control-plane   Ready    control-plane   23s   v1.33.1

$ git fetch origin pull/2275/head && git checkout FETCH_HEAD -- charts/logging-operator
$ kubectl create ns logging && kubectl create ns custom-ns
$ helm install lo . --namespace logging --set telemetry-controller.install=false --wait
$ helm upgrade lo . --namespace logging -f values-e2e.yaml --wait

values-e2e.yaml:

logging:
  enabled: true
  hostTailers:
    enabled: true
    instances:
      - name: with-ns
        enabled: true
        namespace: custom-ns
        fileTailers:
          - name: sample-with-ns
            path: /var/log/sample-with-ns.log
            disabled: false
      - name: without-ns
        enabled: true
        fileTailers:
          - name: sample-without-ns
            path: /var/log/sample-without-ns.log
            disabled: false

1. The CRs land in the intended namespaces

$ kubectl get hosttailers -A
NAMESPACE   NAME         AGE
custom-ns   with-ns      6s
logging     without-ns   6s

2. The operator reconciles the one outside the release namespace

This was my main concern — a HostTailer in another namespace is only useful if the operator watches it. It does; WATCH_NAMESPACE is empty on the operator Deployment, so the watch is cluster-scoped. Verbatim from the operator log:

$ kubectl logs -n logging deploy/lo-logging-operator | grep custom-ns
{"level":"info","ts":"2026-07-24T21:09:02Z","logger":"host-tailer","msg":"resource created","hosttailer":{"name":"with-ns","namespace":"custom-ns"},"name":"with-ns-host-tailer","namespace":"custom-ns","apiVersion":"apps/v1","kind":"DaemonSet"}

$ kubectl get daemonset -A
NAMESPACE     NAME                     DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
custom-ns     with-ns-host-tailer      1         1         0       1            0           <none>                   12s
kube-system   kindnet                  1         1         1       1            1           kubernetes.io/os=linux   2m57s
kube-system   kube-proxy               1         1         1       1            1           kubernetes.io/os=linux   2m59s
logging       without-ns-host-tailer   1         1         0       1            0           <none>                   12s

3. Both DaemonSets roll out and their pods reach Running

$ kubectl get pods -n custom-ns -o wide
NAME                        READY   STATUS    RESTARTS   AGE     IP           NODE                    NOMINATED NODE   READINESS GATES
with-ns-host-tailer-b5cx6   1/1     Running   0          3m24s   10.244.0.6   lo-test-control-plane   <none>           <none>

$ kubectl get pods -n logging | grep host-tailer
without-ns-host-tailer-qj4xh           1/1     Running     0          3m24s

The custom-ns tailer container carries the configured path:

$ kubectl get ds with-ns-host-tailer -n custom-ns -o jsonpath='{.spec.template.spec.containers[*].command}'
["/fluent-bit/bin/fluent-bit","-i","tail","-p","path=/var/log/sample-with-ns.log","-p","db=/var/pos/with-ns-host-tailer-sample-with-ns.db",...]

No RBAC/forbidden errors in the operator log.

4. Backward compatibility

Rendering the same namespace-less values against pre-PR main and against this branch produces identical output, so existing users are unaffected:

$ helm template lo . -n logging -f compat.yaml --show-only templates/logging/hosttailers.yaml
kind: HostTailer
metadata:
  name: legacy
spec:
  fileTailers:

One thing worth noting: the target namespace must already exist — the chart doesn't create it. Happy to document that in values.yaml if you'd prefer. Let me know if you'd like any other scenario covered (e.g. systemdTailers).

[vyncint]

@csatib02 to confirm — yes, tested manually on a live cluster now; results are in the comment above.

Short version: the HostTailer with namespace: custom-ns is created in that namespace and the operator does reconcile it there (cluster-scoped watch), with the DaemonSet rolling out and its pod reaching Running. Instances without namespace are unchanged — identical render against pre-PR main.

Ready for another look whenever you have time.

[csatib02]

@vyncint Once again, thank you for your contribution! :)