Jira (PUP-9470) Add note to logs about which value we're getting the server from

[Melissa Stone (JIRA)]

Title: Message Title

Melissa Stone commented on PUP-9470   Re: Add note to logs about which value we're getting the server from Try to retrieve the ca cert without any of the previously determined server information that we had collected before.   Josh Cooper I added a bunch of debug statements to just figure out what's happening. I noticed we have this section of code that gets repeated, which is odd. Debug: from lib/puppet/indirector/rest.rb, line 69 Debug: Dynamically-bound server lookup failed, falling back to ca_server setting: puppet Debug: from lib/puppet/indirector/rest.rb, line 108 Debug: Dynamically-bound port lookup failed; falling back to ca_port setting Debug: from lib/puppet/indirector/request.rb, line 206 Debug: Dynamically-bound server lookup failed, falling back to server setting: puppet Debug: from lib/puppet/indirector/request.rb, line 218 Debug: Dynamically-bound server lookup failed, falling back to the masterport setting: 8140 Debug: from lib/puppet/indirector/request.rb, line 226 Debug: from lib/puppet/indirector/rest.rb, line 69 Debug: Dynamically-bound server lookup failed, falling back to ca_server setting: puppet Debug: from lib/puppet/indirector/rest.rb, line 108 Debug: Dynamically-bound port lookup failed; falling back to ca_port setting Debug: from lib/puppet/indirector/request.rb, line 206 Debug: Dynamically-bound server lookup failed, falling back to server setting: puppet Debug: from lib/puppet/indirector/request.rb, line 218 Debug: Dynamically-bound server lookup failed, falling back to the masterport setting: 8140 Debug: from lib/puppet/indirector/request.rb, line 226   Notice specifically we seem to come back and repeat the series that starts in `lib/puppet/indirector/rest.rb, line 69` and ends in `lib/puppet/indirector/request.rb, line 226`. Digging into why we repeat that code, Jacob Helwig helped me isolate it.   https://github.com/puppetlabs/puppet/blob/1d584b738fb2e95a0d31a27c205883d49789aa2e/lib/puppet/network/http_pool.rb#L36 here, we set up the default validator `Puppet::SSL::Validator.default_validator()`, which calls ` Puppet::SSL::Validator::DefaultValidator.new()`.   The new default validator calls https://github.com/puppetlabs/puppet/blob/5.5.x/lib/puppet/ssl/validator/default_validator.rb#L28 (`Puppet.lookup(:ssl_host)`).    The ssl_host lookup calls a proc which calls `Puppet::SSL::Host.localhost`. `localhost` calls `@localhost.certificate`, which then looks for the ca with `Certificate.indirection.find("ca", :fail_on_404 => true) unless ca?`. That call to find gets us back into the original `do_request` we first came from, but we no longer have any of the server context saves that we had already found, so we have to go and find it again.   Note, this is all on the 5.5.x branch. It looks like things have changed in the master branch. I also know that this doesn't have a ton to do with adding logging, but it did expose this odd behavior. I'm wondering if this is something that's persistent across branches and something we should look into fixing. Is there a context where we want to maintain this behavior?   Jacob Helwig did I miss anything?   Also, thank you to Jacob who taught me how to use the VSCode native debugger as a part of this exercise. Add Comment   This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.