Use logging library with json support in cmctl (part 3)

[inteon]

Pull Request Motivation

Continuation of what we started in #5828.
Changes cmctl to use the logging library used in all our other components.

NOTE: I had to split this PR into 3 parts: part 1, part 2 and part 3 because cmctl uses a pinned cert-manager version. This PR contains all the changes to cert-manager/cert-manager/cmd/ctl.

Kind

/kind cleanup

Release Note

The cmctl logging has been improved and support for json logging has been added.

[jetstack-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: inteon

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [inteon]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[maelvls]

It doesn't look OK to me to handle the error but still return it afterwards. There is no point in displaying the error at the end if we already displayed it.

Also, why do we print a message to show the progress? The --wait parameter already shows the maximum wait time, so I don't understand the purpose of showing intermediate log lines. kubectl wait doesn't either:

$ kubectl wait deploy -n cert-manager cert-manager-webhook --for=condition=Ready --timeout=30s
error: timed out waiting for the condition on deployments/cert-manager-webhook

suggestion: don't show intermediate log lines. If people really want to have some intermediate output (e.g., to prevent CI's streaming from getting stale), they can use -v=6.

[inteon]

I updated the PR, now we only log intermediate steps on level 2 (= when the -v flag is set)

[inteon]

/retest

[maelvls]

This new feature is very welcome! I'd like this new behavior to be advertised in the --help output (either as part of this PR or in a follow-up PR). I particularly like the fact that we won't be breaking anyone since -v (without an argument) still works (almost) the same.

The reason I think this feature is valuable is because it is now possible to use -v=6, -v=7, and -v=8 to see the HTTP calls made. This use-case makes sense in the context of cmctl check api and cmctl upgrade migrate-api-version which both have complex logic happening. For example, in #6212, reading the error message wasn't informative enough and the user wouldn't have any way of knowing that the problem occurs when cmctl tries to create a certificate.

I think it is OK that "human strings" are printed alongside klog-formatted (or JSON-formatted) log lines. It won't really break any log parser, and kubectl does that anyways. And it won't surprise users.

A minor note is that the behavior of -v changed. Before, it used to add a timestamp to every log line. It doesn't do that anymore. I don't think it matters to anyone as these timestamp weren't super useful anyways; -v=6, -v=7, and -v=8 are much more helpful.

# Before:
$ cmctl check api -v
2023/07/31 18:24:19 The cert-manager API is ready

# After:
$ cmctl check api -v
The cert-manager API is ready

The new -v=6 is super useful to understand where the cmctl command gets stuck or what it does. For example:

$ cmctl check api -v=6 --logging-format=json
{"ts":1690876954501.681,"caller":"clientcmd/loader.go:373","msg":"Config loaded from file:  /Users/mvalais/.kube/config\n","v":6}
{"ts":1690876954510.209,"caller":"transport/round_trippers.go:553","msg":"GET https://127.0.0.1:59109/api 200 OK in 7 milliseconds\n","v":0}
{"ts":1690876954512.226,"caller":"transport/round_trippers.go:553","msg":"GET https://127.0.0.1:59109/apis 200 OK in 1 milliseconds\n","v":0}
{"ts":1690876954513.974,"caller":"transport/round_trippers.go:553","msg":"GET https://127.0.0.1:59109/apis/cert-manager.io/v1 200 OK in 1 milliseconds\n","v":0}
{"ts":1690876954523.876,"caller":"transport/round_trippers.go:553","msg":"POST https://127.0.0.1:59109/apis/cert-manager.io/v1/namespaces/default/certificates?dryRun=All 201 Created in 9 milliseconds\n","v":0}
The cert-manager API is ready

/lgtm