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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CA%2B%3DBEqXdanZYL0gvi4ebc%2BAvNGH_OaH3rpvFJD%3DU70_Cu0FNpg%40mail.gmail.com.
