This is an overdue change. These are not terms we should be using as a company or community. To quote our Code of Conduct (https://community.chef.io/code-of-conduct/). "Be careful in the words that you choose. Be kind to others. Practice empathy." This change aims to do exactly that, while maintaining a level of backwards compatibility so we can transition existing users off the legacy configs.

Signed-off-by: Tim Smith <tsmith@chef.io>

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

FileUtils.mkdir_p expects the mode to be in octal form. We accept Integers, but Ruby doesn't have a way to tell if what the user passed was octal or not. The safest thing to do here is to only accept mode as a String and then convert it to octal form with .to_i(8). This adds a new deprecation and correctly sets the file mode value as octal. Right now this feature works like this:

String mode: applies wrong permission
Base 10 mode: applies wrong permissions
Octal mode: Works

New behavior:

String mode: Works
Base 10 mode: Works but throws a deprecation warning
Octal mode: applies the wrong permissions and throws a deprecation warning

Signed-off-by: Tim Smith <tsmith@chef.io>

Autocorrected with chefstyle after enabling that cop. It was very hard to read some complex autocorrected blocks w/o this.

Signed-off-by: Tim Smith <tsmith@chef.io>

We have issue that are caused by old code before merging of hash values
were done correctly.

The `config` hash correctly merges all options and should always be
used.

Knife plugins should never touch Chef::Config[:knife] values (either
reading or writing from them).

The `knife_config` should be converted to the `config` hash since it
directly accesses Chef::Config[:knife] values.

The `config_value()` helper should no longer be used.  Very clearly most
people started to use that when they should just use the config hash
directly.  That was intended to be used only when a knife cli option
was being renamed and the former configuration value needed to be
used as well.  It has been cargo culted around as the way to access
config values, and that should really stop.

The DataBagSecretOption mixin has been cleaned up so that the cli
options read+write only to the config[:cl_secret] and
config[:cl_secret_file] values.  The config file values go into
config[:secret] and config[:secret_file].  The fact that those are
the merged values in the `config` hash doesn't matter since only
the cli should be writing to the first two and only the config
file should be writing to the latter two.  I don't know why it was
made so complicated to begin with, but if there's some hidden
chef-11.early backcompat there, then chef-16 deliberately breaks that.

The use of `locate_config_value` helpers in all knife plugins is also
discouraged (but they all implement those themselves), just use the
config hash, which has the correct hash merge ordering.  All of those
need to be deleted.

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

Legally incredibly dubious, particularly since we don't follow it
strictly as policy, and we have git history instead, which does it right.
This is just a waste of time and a cargo cult.

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

Thanks for pointing this out Ian

Signed-off-by: Tim Smith <tsmith@chef.io>

When we migrated to hugo the URLs changed a bit. Nothing ends in .html and we moved all the resources into their own dir.

Signed-off-by: Tim Smith <tsmith@chef.io>

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

i like this one, gives visual priority to returns or raises that are
buried in the middle of things.

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>