Closed marcparadise closed 4 years ago
I have added a critical priority flag, because we're introducing new configuration options to chef-analyze via this change; and if we don't disable strict config, chef-run
will fails to work because of missing config.
This will be a bit more complex than it should. Setting strict config to false results in the following error when running chef-run
with a non-empty configuration file:
NoMethodError: undefined method `apply_nested_hash' for nil:NilClass
/home/marc/.rubies/ruby-2.6.3/lib/ruby/gems/2.6.0/gems/mixlib-config-3.0.1/lib/mixlib/config.rb:570:in `block in apply_nested_hash'
In this case the 'nil:NilClass' in the class ChefApply::Config itself. It should never be nill - it's a class method pulled into ChefApply::Config
via extend
@marcparadise note that the correct name of the configuration file is config.toml
and not default.toml
.
Strict config checking for chef-run was enabled both to help us give clear messages to the person running
chef-run
when there was an error in configuration, and as a forcing function to ensure we only supported known, documented configuration options.However, .chef-workstation/default.toml is now used by multiple components, and it does not make sense for
chef-apply
to be a source of truth for all configuration options that various Workstation components support.With strict config checking enabled, unknown config options are presented to the operator for correction. This is a problem when other component config options aren't recognized.
While there's some discussion to be had around making a consistent, validate-able configuration across Workstation, let's disable strict checking in
chef-run
itself. This will prevent us from having to go back and modifychef-run
every time we need to add a new config option to chef, chef-apply, chef tray app, etc.