Separate log-level and structured/unstructured cmd options

[kasey]

What problem are you facing?

Setting the --debug flag currently also changes the output formatting of our logs to semi-structured. It can sometimes be helpful to switch to a debug log level in production, or use structured logs in development.

How could Crossplane help solve your problem?

Remove the --debug flag and add 2 new flags --log-level=(info|debug) and --output=(json|text)\-o. My thinking in naming the output flag is to mirror kubectl but I'm not convinced that's the right move since this only pertains to logs (although we don't have any other output?), maybe --log-format would be more clear.

[negz]

Remove the --debug flag and add 2 new flags

I like the idea of decoupling output format from verbosity but I'd prefer to avoid removing the debug flag as that could be considered a breaking/potentially disruptive change. What do you think about instead adding a new flag ala --output or --log-format? The idea being that if the --log-format flag was omitted Crossplane would behave exactly as it does today, but if the flag were supplied it would be possible to override today's behaviour (i.e. to use fully structured debug logging, or to use human readable info logging, etc).

[kasey]

I should have mentioned defaults. To match current behavior I had been thinking the default value of --log-format would be json and the default format of --log-level would be info. We could keep --debug and just define it as a shortcut/legacy (maybe set it for deprecation and warn?) for setting --log-format=text and --log-level=debug.

[negz]

We could keep --debug and just define it as a shortcut/legacy (maybe set it for deprecation and warn?) for setting --log-format=text and --log-level=debug.

I'm not seeing why we'd need to deprecate or replace it - it doesn't feel broken to me. That said, I don't feel particularly strongly about this except that I don't want folks who expect to be able to run crossplane --debug to experience issues due to that flag being removed.

[psinghal20]

Hi @negz, I would love to work on this issue if no one is working on it. According to the initial look I took at the cmd/main.go, we would have to implement a zap.Opts function to set the Level and Encoder config based on the new flags. Please let me know if my understanding is correct. We can give the --debug flag priority over these options.

Also, should I wait for this PR: #2117 to land first?

[negz]

Hey @psinghal20! Please do feel free to work on this now that you've moved us over to kong. :)

[nvzard]

Hey, want to contribute, and can pick this up?

[github-actions]

Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as stale because it has had no activity in the last 90 days. It will be closed in 7 days if no further activity occurs. Leaving a comment starting with /fresh will mark this issue as not stale.

[siddharthdeshmukh]

Hi,
Is there a plan to implement this feature?
Regards
Siddharth

[jbw976]

There hasn't been any activity or interest (folks in the community needing this functionality) on this issue for over a year, so I'm not seeing it as a priority to pursue. crossplane/crossplane-runtime#373 was a bigger concern for me personally, and I believe that should be addressed now.

[Hronom]

Any progress on this? Logs management is basic thing

[jbw976]

@Hronom would it be possible for you to describe more deeply what you are wanting to do with the crossplane logs that you cannot currently accomplish?

[Hronom]

@jbw976 simplify scrapping of logs (by using JSON) as same as control level (error, warn, info, debug, trace)

Solution described in first message How could Crossplane help solve your problem? solves this needs.