Add --log-http option

[sixolet]

It prints all the HTTP requests and responses to stderr.

Quick and dirty, I just found it useful when debugging what requests kn was sending, maybe other people will too.

Prints the http requests before they get their tokens added, so it's not that much of a security risk.

[cppforlife]

@sixolet is that similar to how kubectl implements -v=8 option?

[sixolet]

Looks like yes-ish, but they use the github.com/golang/glog module to read the global log level in the factory for deciding whether to generate the verbose transport or not, and can generate the transport at creation time, which didn't make its way into client-go. However, reading more code made me realize a slightly better way to do it that nixes the downcast, I think.

[sixolet]

Doesn't, actually, experientially, since the logger is outside the layer that adds them. I can add that to the test.

…

On Aug 2, 2019, at 11:57 AM, Dmitriy Kalinin ***@***.***> wrote: @cppforlife commented on this pull request. In pkg/util/logging_http_transport.go: > +func NewLoggingTransport(transport http.RoundTripper) http.RoundTripper { + return &LoggingHttpTransport{transport, nil} +} + +func NewLoggingTransportWithStream(transport http.RoundTripper, s io.Writer) http.RoundTripper { + return &LoggingHttpTransport{transport, s} +} + +func (t *LoggingHttpTransport) RoundTrip(r *http.Request) (*http.Response, error) { + stream := t.stream + if stream == nil { + stream = os.Stderr + } + reqBytes, _ := httputil.DumpRequestOut(r, true) + fmt.Fprintln(stream, "===== REQUEST =====") + fmt.Fprintln(stream, string(reqBytes)) a little concerning that this will include auth headers etc. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[sixolet]

... actually never mind, I was looking at the response. I'll fix.

[rhuss]

Thanks a lot, I think this is a very useful feature.

My only concern is about the UX integration via --log-http. We have already PRs open which introduce --verbose and/or --debug. We should consolidate on that to offer a minimal UI surface for managing log and debug output (especially as it's a global option)

My suggestion would be that we could settle on a convention like:

• Adding --debug for very low level information. Only useful for developer of kn itself
• Adding a --verbose option for increasing the detail level of the information presented. Examples are
  • kn service describe --verbose to add more details to a service (like the image digests, or all env vars/annotations/labels)
  • kn plugin list --verbose to also print the plugin directories where plugins are looked up
  • kn service create --debug to print also the HTTP headers

In order to tune debug and verbose output, I'd suggest to introduce categories:

• --debug --> all debug info
• --debug=all --> all debug info
• --debug=http --> only http related debugging
• --verbose --> all verbose output
• --verbose=config --> config related information, too
• --verbose=config,details --> config information and details (made up here to show how to combine categories)

This suggestion would introduce exactly two option, --debug and --verbose (with the possible values shown in the help page). The alternative would be to have an extra option for every category like in this PR, but this would blow up the help pages and UX surface considerably over time.

Happy to use --log instead of --verbose it's not so much about naming but about being concise.

[knative-metrics-robot]

The following is the coverage report on pkg/.
Say /test pull-knative-client-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/kn/commands/types.go	53.6%	60.0%	6.4
pkg/kn/core/root.go	55.2%	55.7%	0.5
pkg/util/logging_http_transport.go	Do not exist	92.6%

[sixolet]

Let's merge this into --verbose as part of or shortly after that change?

[rhuss]

Let's merge this into --verbose as part of or shortly after that change?

Let's do it after this PR is merged. I opened #333 for this.

/approve
/lgtm

[knative-prow-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rhuss, sixolet

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 [rhuss,sixolet]

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