[cvas22]

What this PR does / why we need it:

Fixes two problems with Fluentd globalInputs that leave port unset, which the API documents as allowed ("default is 24224" / "default is 9880"):

1. Wrong default forward port. DefaultForwardPort was 24424, but Fluentd's in_forward listens on 24224 when no port is rendered (the field doc says 24224 too). A forward input without a port got a container port and a Service port of 24424, while Fluentd listened on 24224, so the Service sent traffic to a port nothing listened on. The constant is now 24224.
2. Nil pointer dereference in MakeFluentdService. It dereferenced *input.Forward.Port and *input.Http.Port without a nil check, so a forward or http input without a port panicked while the Service was built. The StatefulSet/DaemonSet side (makeFluentdPorts) already handled nil. The Service now uses the same logic.

For example, this panicked the reconcile before, and now produces a forward container port and a Service port of 24224:

spec:
  globalInputs:
    - forward:
        bind: 0.0.0.0

Which issue(s) this PR fixes:

None filed. I found this while looking at the port handling for #1610.

Does this PR introduced a user-facing change?

Fluentd forward inputs without a port now expose Fluentd's default port 24224 instead of 24424, and forward or http inputs without a port no longer crash the operator while it builds the Fluentd Service.

Notes

Anyone who relied on 24424 must have set the port explicitly, because Fluentd itself never listened there. Explicit ports are unchanged.

I added pkg/operator/fluentd_service_test.go, which checks the container port and the Service port for forward and http inputs, with and without a port. Against master it fails: it gets 24424 for forward, then panics on the http case with invalid memory address or nil pointer dereference. With this change go test ./pkg/operator/ passes, and go vet and gofmt are clean (golang:1.26 container). I haven't run it against a live cluster.

[joshuabaird]

Thanks for the fix and for adding a test that covers both bugs.

A couple of small nits, none blocking:

• The repo uses Go 1.26's new(int32(...)) elsewhere (e.g. controllers/collector_config_test.go), so the int32Ptr helper could be dropped in favor of that.
• The "http without a port" test case is on one line while the others are multi-line.

Separately, monitorAgent inputs also have an optional port that isn't exposed on the container or Service. Out of scope here, but might be worth a follow-up issue.

[cvas22]

Thanks! Both nits are done in d158fb3: the tests use new(int32(...)) and the helper is gone, and the http case now uses the same multi-line layout as the others.

Good point about monitorAgent. I'll open a follow-up for its port once this one is in.

[joshuabaird]

Thanks for the quick turnaround, LGTM.