knife bootstrap windows: log_level should be updated as in client.rb

[msys-sgarg]

Signed-off-by: smriti sgarg@msystechnologies.com

log_level while being set in client.rb was referring to wrong hash variable

Description

knife bootstrap -o winrm IPaddress -U 'USERNAME' -P 'PASSWORD' -c /.chef/config.rb -N NODENAME -V
" -V " verbose option plays a role in value of final log_level setting in client.rb
To set log_level it searches in config[:config_log_level] which is wrong hash variable, hence file being created with default log_level = auto always it should look for log_level in chef_config[:config_log_level]

Related Issue

#11367

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Chore (non-breaking change that does not add functionality or fix an issue)

Checklist:

• I have read the CONTRIBUTING document.
• I have run the pre-merge tests locally and they pass.
• [] I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.
• All commits have been signed-off for the Developer Certificate of Origin.

[lamont-granquist]

This should probably be changed to be the same as the linux/unix code in boostrap_context.rb:

          unless chef_config[:config_log_level].nil? || chef_config[:config_log_level].empty?
            client_rb << %Q{log_level   :#{chef_config[:config_log_level]}\n}
          end

Or else both should be made consistent one way or another.

And it looks like chef_config[:config_log_level] should be used instead of chef_config[:log_level] unless that was deliberate (in which case the boostrap_context.rb should also be changed.

[msys-sgarg]

@lamont-granquist We have made the changes as per the comment. looks like chef_config[:config_log_level] is working fine in both cases. Thanks