Log label consistency.

[andrew-pickin-epi]

Label used in calls to logger are inconsistent.
This leads to at best extra overhead when configuring log parsing tool, at worst missed errors.

Examples:
loop.go:
logger.Log("err", err)

images.go:

logger.Log("error", errors.Wrap(err, "fetching image updates"))
logger.Log("msg", "polling for new images for automated workloads")

sync.go

d.Logger.Log("info", "trying to sync git changes to the cluster", "old", changeSet.oldTagRev, "new", changeSet.newTagRev)
d.Logger.Log("warning", "failed to load last-synced resources. sync event may be inaccurate", "err", err)

I could list other examples regarding state/success or the reporting of steps in the process.
See also fields attempted, successful, updated etc.

The point being that something like kibana is likely to be used by many uses of flux, these fields will likely be tabulated.
Currently (without doing work to coalesce columns/fields) this results in more columns the desired, and potential issues.
Eg one displays the error field but neglects the err.

Desired behaviour;
Consistent use of message (or some other field) for output, use of standard log levels (debug, info, warn, error).
So maybe

logger.Error ("some error text")
logger.Info ("some info text")

etc

[kingdonb]

Generally the disposition towards this type of change while in maintenance mode, is that behavior changes are breaking changes, and automation providers who adopted Flux v1 and have stuck with it through the migration to Flux v2, should not be expected to cope with changes to logging or metric behavior, (even if they are cosmetically wrong, changing them now will cause more work for people who have placed their faith in Flux's semver promise to not break compatibility within a major version.)

Since Flux v1 is in maintenance (#3320) and Flux v2 is where all new development efforts should be focused to go, this may not be possible to fix.

I can't categorically reject a change that isn't in PR form yet, but I wanted to be sure before you spend too much time on this issue to alert you to the maintenance status, in case this is something you're not already aware of. (I'm sure you noticed the messaging, but just wanted to reiterate this.)

If it changes the behavior of logging or metrics, the blanket guidance that I have received from the maintainers is to treat it as a breaking change and do not merge the change.

I'm not completely sure I understood the issue you're reporting, I wouldn't mind hearing it explained again, or if it is possible to illustrate the problem with a test, that would be helpful too.

If it is a genuine bug and causing you problems, then we can still consider fixing it. We hope you will consider upgrading to Flux v2, as the resources committed to maintenance of Flux v1 are limited by comparison, issues like this one are more likely to be addressed in Flux v2, and it may be (most likely is) already be resolved there.

Thanks for using Flux!

[kingdonb]

Closing for now. Can reopen if there is a concrete change suggested, so we can evaluate it and decide, but I've explained the position of the project.

I'm not completely against re-ifying these types of issues, but I haven't built any automation that depends on the structure of the logs myself. I know there are some folks out there that have. I don't want to do anything that will upset their empires.