puppet --trace content

[Justin Stoller]

Hello!

I noticed that the way we were computing the "Puppet" stack (ie the files and line numbers from function calls within Puppet code like `fqdn_rand()`) had become slow and was likely to become slower. In my attempt to improve the situation I focused on ensuring backwards compatibility with callers of the PuppetStack api (like the stdlib function `deprecation`).

However there was a change in the output of `puppet --trace` (when using puppet apply or puppet agent, or in the server logs). The output of the Ruby stack traces used to have the Puppet code stack interleaved. I tried putting example stack traces in this email and it became a bit unwieldy, so I'll refer you to the ticket[1] where there are examples.

My questions, also posed in the ticket, are:

Is interleaving the Puppet stack trace into the Ruby stack trace valuable to most users (and should go back to being the default)?

Are there workflows where you'd like to see just one (the Puppet stack), the other (Ruby), or both (ie, do we need more trace options, and if so how important are they relative to each other)?

I don't know if I'll get *something* around this for the next release, but I will probably start work on it relatively soon. I'd love your feedback, either in-line or in the linked ticket, to help figure out *what* that something is (go back to interleaving vs provide different flags for different traces).

Thanks,

Justin

1. https://tickets.puppetlabs.com/browse/PUP-10150

[Justin Stoller]

This will be my last note about this. I'll probably start work on it later _next_ week.

fwiw, I'm leaning towards something like `--trace` returns just the ruby stacktrace, `--puppet_trace` returns just the puppet code stack, and passing both interleave them similar to previous behavior (but if more folks are concerned about this having been a breaking change I can put the solitary `--trace` output back to having them interleaved).