Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(maint) Make loglevel default more efficient #8958

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

MartyEwings
Copy link

This line is not sane for the setting of the log_level default

loglevel = %x{ #{puppet_path} config --section agent --log_level notice print log_level }.chomp

this sets log_level to notice, and then return the output of the log_level setting

  loglevel = "notice"

is the same thing with fewer steps

@MartyEwings MartyEwings requested a review from a team as a code owner December 2, 2022 11:01
@MartyEwings MartyEwings changed the title Make loglevel default more efficient (maint) Make loglevel default more efficient Dec 2, 2022
This line is not sane for the setting of the log_levl default

   loglevel = %x{ #{puppet_path} config --section agent --log_level notice print log_level }.chomp

this sets log_level to notice, and then return the output of the log_level setting

      loglevel = "notice"

is the same thing with fewer steps
@@ -176,7 +176,7 @@ def parse_runinterval(puppet_path)

def parse_log_level(puppet_path,cmdline_debug)
begin
loglevel = %x{ #{puppet_path} config --section agent --log_level notice print log_level }.chomp
loglevel = "notice"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current code is written that way because log_level is a puppet setting and may be stored in puppet.conf. So in eb63fd6 we added logic to run puppet agent --configprint log_level to lookup the current level. Later the command was changed to puppet config print --section agent log_level, but if you set log_level=debug in puppet.conf, it generates a bunch of unneeded output. So in 1e58925 we explicitly specify --log_level notice for just this one command invocation. Kind of convoluted, but necessary since we don't have a simple way of looking up puppet config values without running puppet config

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @joshcooper yeah I understand you need it to be notice level, but this one parameter command can never output anything other than the string "notice" no matter what in puppet.conf, I'm not understanding the need to do a one time puppet config set to notice, and print the fact notice was set to a parameter within that command?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@MartyEwings I think the desired outcome was if you have log_level=debug set in puppet.conf, then the call to puppet config print log_level --log_level notice should display the value that was stored in puppet.conf and not the overridden value on the CLI. Otherwise, like you say, what's the point.

So I think we either need to go with your PR and update the reference docs for log_level to say it doesn't affect the windows service (which is what we were trying to solve in PUP-3376).

Or we need to special case puppet config print log_level to ignore the value specified on the CLI and return the value specified in puppet.conf. It's possible to do that doing something like:

        value = Puppet.settings.setting(:log_level).default

        sources = Puppet.settings.configsearchpath(Puppet.settings[:environment], options[:section])
        sources.each do |src|
          next unless src
          next if src.name == :cli

          values = Puppet.settings.searchpath_values(src)
          next unless values

          v = values.lookup(:log_level)
          next unless v

          value = v
          break
        end

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the PR is fine, it preserves the current behavior in fewer steps like you said. I'll file a separate issue that we've lost the ability for the windows service to observe the log_level setting.

@CLAassistant
Copy link

CLAassistant commented Apr 19, 2023

CLA assistant check
All committers have signed the CLA.

@joshcooper joshcooper added the bug Something isn't working label Nov 15, 2023
@joshcooper
Copy link
Contributor

@MartyEwings could you rebase and resolve conflicts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants