Rationalise logging fields.

[andrew-pickin-epi]

Describe the bug

Geneally the logging of Flux v1 is good, and there is sufficient detail to understand what is happening.
However I find the inconsistent use of field names annoying.
For example the various components log free test messages under field called info, msg, output, error and err.
When using a generic log tool such as kibana, this tend to mean that these fields each require their own column or bespoke processing.

Steps to reproduce

Standard json log output.
Now try to filter on a text field. There are lots to pick from.

Expected behavior

Standardise on a set of field names.

Screenshots and recordings

No response

OS / Distro

AWS EKS

Flux version

1.20.0

Flux check

n/a

Git provider

No response

Container Registry provider

No response

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[kingdonb]

Thanks for the report.

Flux v1 is in maintenance mode (#3320) and one thing this means is that we cannot include any breaking changes.

While it is known that the output and logging may still be inconsistent in some places, many production deployments have been created which required as you've noticed, building bespoke automation that was not already available in the standard Flux distribution. Those deployments will necessarily depend on the specific format and structure of the output in logs.

For this reason, we cannot make any changes to the logging output in Flux v1. I'm sorry that's probably not the response that you were hoping for. Making fixes to Flux v1 in a way that breaks those existing bespoke automations is something we've discussed with the maintainer team and agreed those type of changes will need to go into Flux v2, to comport with our commitment to honor Semantic Versioning.

[andrew-pickin-epi]

Yes. Understood.
I log this more to have the issue addressed in v2.

[kingdonb]

The Flux v2 logs are already quite different. I think this might be addressed there already. Have you had occasion to try it out yet? It would be good to document how this has changed, the manual page for flux logs though it explains how to use, is quite sparse in other ways:

https://fluxcd.io/docs/cmd/flux_logs/

There are filtering constructs that allow to select only logs which you are interested in, the information is (usually? always?) in parallel to events, so you can consume most of the same information found in the logs from within Kubernetes by subscribing to events. There is no JSON format option in flux logs, although you can probably receive the events from Kubernetes in JSON format.

As it turns out, my information about maintenance mode is actually a bit behind the curve... according to the docs, Flux v1 is officially considered as Superseded now, since June 30, when the Flux v2 APIs were declared stable: https://fluxcd.io/docs/migration/timetable/

Please do check out Flux v2 and consider migrating your workloads as soon as possible.

[kingdonb]

I will be closing this issue, but if you have any more bugs to report please feel welcome to submit issues until the end of maintenance, when Flux v1 will finally be archived.

If you think there is still an issue to report, you're welcome to file it against fluxcd/flux2 or open a discussion, if you have a question or proposal for how to change Flux.

Thanks for using Flux!