Add verbose and/or debug logging to kustomize command

[erinaceous]

Eschewed features

• [X] This issue is not requesting templating, unstuctured edits, build-time side-effects from args or env vars, or any other eschewed feature.

What would you like to have added?

As per the advice given in the original issue, this is a feature request for incorporating verbose or debug log output when running kustomize CLI commands:

Perhaps some variation on:

• kustomize --verbose build ...
• kustomize --debug ...
• kustomize --log-output=bases,transformations
• kustomize --log-level=FATAL ...

Which would, given varying levels of implementation complexity:

• Enable debug output logging across kustomize (--verbose / --debug)
• Enable selective logging output (--log-output=bases,transformations,extension-1,extension-2,...)
• Making use of structured logging levels (--log-level=DEBUG/--log-level=FATAL etc), e.g. using slog and using slog.Info, slog.Warn, slog.Debug calls etc.

A good entry-point would be kustomize build specifically, logging what bases/resources are being read, and then logging the transformations being applied (in order they were applied), implicitly showing the order in which they're being applied to produce the final set of kubernetes resources.

Is this big enough to warrant a KEP? Honestly, I don't know enough to know if it does!

Why is this needed?

When kustomize is attempting to resolve bases it is helpful to find out what is going on.

I would also like to see this functionality, after spending an embarrassing amount of time using manual trial and error to figure out why Kustomize wasn't rendering the objects the way I expected. There's literally no feedback in this tool and it makes it pretty hostile to users.

Can we add some kind of tracing/debugging functionality (e.g. via a CLI option) that steps through the transformations in detail? For example, logs the before and after structs for each transformation and where in the code the transformation is occurring?

Like, --debug to turn on logging like DEBUG: Fetching URL https://blah.com/blah.yaml.

Given the complexity implied by importing bases and the absolute opacity in which this is done, a --verbose or --debug flag, as most developer tools have, seems like a natural feature.

Without that, it's hard to scale this to be used by developers who aren't familiar with kustomize, since there's at best a vague hint as to where they should look to find the origin of particular lines.

Can you accomplish the motivating task without this feature, and if so, how?

With difficulty:

an embarrassing amount of time using manual trial and error

What other solutions have you considered?

As an end-user, and somebody not familiar with Go, I would not really have any alternative, bar "trial and error until kustomize does what I expected it to do based on the documentation and examples I've read".

As someone who likes to tinker, if I had enough time I'd probably learn enough to step through running kustomize build in GDB...

Anything else we should know?

I appreciate that despite this appearing a simple request, it could potentially touch a lot of this codebase, as for it to be useful to end-users and extension developers, would require retroactively adding logging calls across a lot of stuff, having identified where it would be useful..!

I also appreciate whilst writing this out as a feature request that just adequately describing the feature is actually quite a big and time-consuming thing..! I will re-visit this when I can, and perhaps others who commented on the original issue could weigh in on:

• Where the most useful informational logging points are, and what pieces of information are most useful to log
• How the log output can be presented most usefully to end-users of the kustomize CLI command

I'm not interested in owning the feature per se, but definitely happy to contribute should someone else start the PR.

Feature ownership

• [ ] I am interested in contributing this feature myself! 🎉

[koba1t]

Hi @erinaceous I believe it's an interesting feature and helpful debug. I think this feature needs to be rewritten on many points, and the internal interface needs too.

If we implement this feature, we need to write KEP before starting implementation.

/triage under-consideration

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[LarsStegman]

/remove-lifecycle rotten