Merge pull request #3044 from chef/jdm/12.1.112.1.1

12.1.1 Release

6 files changed, 24 insertions, 234 deletions

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 33fde26d4a..dfbe8580d0 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,5 +1,21 @@
 ## Unreleased
 
+* make deploy resource attributes nillable (`symlink_before_migrate nil`) works now
+* mixin the LWRP attribute DSL method into Chef::Resource directly
+* make all LWRP attributes nillable
+* `knife ssh` now has an --exit-on-error option that allows users to
+  fail-fast rather than moving on to the next machine.
+* migrate macosx, windows, openbsd, and netbsd resources to dynamic resolution
+* migrate cron and mdadm resources to dynamic resolution
+
+## 12.1.1
+* [**Phil Dibowitz**](https://github.com/jaymzh):
+  [Issue 3008](https://github.com/chef/chef/issues/3008) Allow people to pass in `source` to package
+* [Issue 3011](https://github.com/chef/chef/issues/3011) `package` provider base should include 
+  `Chef::Mixin::Command` as there are still providers that use it.
+* [**Ranjib Dey**](https://github.com/ranjib):
+  [Issue 3019](https://github.com/chef/chef/issues/3019) Fix data fetching when explicit attributes are passed
+
 ## 12.1.0
 
 * [**Andre Elizondo**](https://github.com/andrewelizondo)
diff --git a/DOC_CHANGES.md b/DOC_CHANGES.md
index f824d2da30..6b58871418 100644
--- a/DOC_CHANGES.md
+++ b/DOC_CHANGES.md
@@ -5,81 +5,3 @@ Example Doc Change:
 ### Headline for the required change
 Description of the required change.
 -->
-
-
-### File-like resources now accept a `verify` attribute
-
-The file, template, cookbook_file, and remote_file resources now all
-accept a `verify` attribute.  This file accepts a string or a block,
-similar to `only_if`.  A full specification can be found in RFC 027:
-
-https://github.com/opscode/chef-rfc/blob/master/rfc027-file-content-verification.md
-
-### Chef now handles URI Schemes in a case insensitive manner
-
-Previously, when a URI scheme contained all uppercase letters, Chef would reject the URI as invalid. In compliance with RFC3986, Chef now treats URI schemes in a case insensitive manner. This applies to all resources which accept URIs such as remote_file etc.
-
-### Experimental Audit Mode Feature
-
-There is a new command_line flag provided for `chef-client`: `--audit-mode`.  This accepts 1 of 3 arguments:
-
-* `disabled` (default) - Audits are disabled and the phase is skipped.  This is the default while Audit mode is an
-experimental feature.
-* `enabled` - Audits are enabled and will be performed after the converge phase.
-* `audit-only` - Audits are enabled and convergence is disabled.  Only audits will be performed.
-
-This can also be configured in your node's client.rb with the key `audit_mode` and a value of `:disabled`, `:enabled` or `:audit_only`.
-
-### Chef Why Run Mode Ignores Audit Phase
-
-Because most users enable `why_run` mode to determine what resources convergence will update on their system, the audit
-phase is not executed.  There is no way to get both `why_run` output and audit output in 1 single command.  To get
-audit output without performing convergence use the `--audit-mode` flag.
-
-#### Editors note 1
-
-The `--audit-mode` flag should be a link to the documentation for that flag
-
-#### Editors node 2
-
-This probably only needs to be a bullet point added to http://docs.getchef.com/nodes.html#about-why-run-mode under the
-`certain assumptions` section
-
-## Drop SSL Warnings
-Now that the default for SSL checking is on, no more warning is emitted when SSL
-checking is off.
-
-## Multi-package Support
-The `package` provider has been extended to support multiple packages. This
-support is new and and not all subproviders yet support it. Full support for
-`apt` and `yum` has been implemented.
-
-## Add compile_time option to chef_gem
-
-This option defaults to true, which is deprecated, and setting this to false
-will stop chef_gem from automatically installing at compile_time.  False is
-the recommended setting as long as the gem is only used in provider code (a
-best practice) and not used directly in recipe code.
-
-## Yum Package provider now supports version requirements
-
-A documented feature of the yum_package provider was the ability to specify a version requirement such as ` = 1.0.1.el5` in the resource name.
-However, this did not actually work. It has now been fixed, and additionally version requirements are now supported in the `version` attribute
-of yum_package as well.
-
-## Validatorless bootstraps
-
-Validation keys are now optional.   If the validation key is simply deleted and does not exist, then knife bootstrap will use the
-user's key to create a client for the node and create the node object and bootstrap the host.  Validation keys can continue to be
-used, particularly for autoscaling, but even for that use case a dedicated user for autoscaling would be preferable to the shared
-validation key.
-
-## Bootstrap will create chef-vault items
-
-The --bootstrap-vault-item, --bootstrap-vault-json, and --bootstrap-vault-file arguments have been added to knife bootstrap providing
-three alternative ways to set chef vault items when bootstrapping a host.
-
-## Windows service now has a configurable timeout
-
-You can now set the amount of time a chef-client run is allowed when running the provided windows service. This can be configured by
-setting `windows_service.watchdog_timeout` in your `client.rb` to the number of seconds desired. The default value is 2 hours.
diff --git a/RELEASE_NOTES.md b/RELEASE_NOTES.md
index 4d0a6cc7ef..5076ec0f4a 100644
--- a/RELEASE_NOTES.md
+++ b/RELEASE_NOTES.md
@@ -1,153 +1,2 @@
-# Chef Client Release Notes 12.1.0:
+# Chef Client Release Notes 12.1.1:
 
-# Internal API Changes in this Release
-
-## Experimental Audit Mode Feature
-
-This is a new feature intended to provide _infrastructure audits_.  Chef already allows you to configure your infrastructure
-with code, but there are some use cases that are not covered by resource convergence.  What if you want to check that
-the application Chef just installed is functioning correctly?  If it provides a status page an audit can check this
-and validate that the application has database connectivity.
-
-Audits are performed by leveraging [Serverspec](http://serverspec.org/) and [RSpec](https://relishapp.com/rspec) on the
-node.  As such the syntax is very similar to a normal RSpec spec.
-
-### Syntax
-
-```ruby
-control_group "Database Audit" do
-
-  control "postgres package" do
-    it "should not be installed" do
-      expect(package("postgresql")).to_not be_installed
-    end
-  end
-
-  let(:p) { port(111) }
-  control p do
-    it "has nothing listening" do
-      expect(p).to_not be_listening
-    end
-  end
-
-end
-```
-
-Using the example above I will break down the components of an Audit:
-
-* `control_group` - This named block contains all the audits to be performed during the audit phase.  During Chef convergence
- the audits will be collected and ran in a separate phase at the end of the Chef run.  Any `control_group` block defined in
- a recipe that is ran on the node will be performed.
-* `control` - This keyword describes a section of audits to perform.  The name here should either be a string describing
-the system under test, or a [Serverspec resource](http://serverspec.org/resource_types.html).
-* `it` - Inside this block you can use [RSpec expectations](https://relishapp.com/rspec/rspec-expectations/docs) to
-write the audits.  You can use the Serverspec resources here or regular ruby code.  Any raised errors will fail the
-audit.
-
-### Output and error handling
-
-Output from the audit run will appear in your `Chef::Config[:log_location]`.  If an audit fails then Chef will raise
-an error and exit with a non-zero status.
-
-### Further reading
-
-More information about the audit mode can be found in its
-[RFC](https://github.com/opscode/chef-rfc/blob/master/rfc035-audit-mode.md)
-
-# End-User Changes
-
-## OpenBSD Package provider was added
-
-The package resource on OpenBSD is wired up to use the new OpenBSD package provider to install via pkg_add on OpenBSD systems.
-
-## Case Insensitive URI Handling
-
-Previously, when a URI scheme contained all uppercase letters, Chef
-would reject the URI as invalid. In compliance with RFC3986, Chef now
-treats URI schemes in a case insensitive manner.
-
-## File Content Verification (RFC 027)
-
-Per RFC 027, the file and file-like resources now accept a `verify`
-attribute.  This attribute accepts a string(shell command) or a ruby
-block (similar to `only_if`) which can be used to verify the contents
-of a rendered template before deploying it to disk.
-
-## Drop SSL Warnings
-Now that the default for SSL checking is on, no more warning is emitted when SSL
-checking is off.
-
-## Multi-package Support
-The `package` provider has been extended to support multiple packages. This
-support is new and and not all subproviders yet support it. Full support for
-`apt` and `yum` has been implemented.
-
-## chef_gem deprecation of installation at compile time
-
-A `compile_time` flag has been added to the chef_gem resource to control if it is installed at compile_time or not.  The prior behavior has been that this
-resource forces itself to install at compile_time which is problematic since if the gem is native it forces build_essentials and other dependent libraries
-to have to be installed at compile_time in an escalating war of forcing compile time execution.  This default was engineered before it was understood that a better
-approach was to lazily require gems inside of provider code which only ran at converge time and that requiring gems in recipe code was bad practice.
-
-The default behavior has not changed, but every chef_gem resource will now emit out a warning:
-
-```
-[2015-02-06T13:13:48-08:00] WARN: chef_gem[aws-sdk] chef_gem compile_time installation is deprecated
-[2015-02-06T13:13:48-08:00] WARN: chef_gem[aws-sdk] Please set `compile_time false` on the resource to use the new behavior.
-[2015-02-06T13:13:48-08:00] WARN: chef_gem[aws-sdk] or set `compile_time true` on the resource if compile_time behavior is required.
-```
-
-The preferred way to fix this is to make every chef_gem resource explicit about compile_time installation (keeping in mind the best-practice to default to false
-unless there is a reason):
-
-```ruby
-chef_gem 'aws-sdk' do
-  compile_time false
-end
-```
-
-There is also a Chef::Config[:chef_gem_compile_time] flag which has been added.  If this is set to true (not recommended) then chef will only emit a single
-warning at the top of the chef-client run:
-
-```
-[2015-02-06T13:27:35-08:00] WARN: setting chef_gem_compile_time to true is deprecated
-```
-
-It will behave like Chef 10 and Chef 11 and will default chef_gem to compile_time installations and will suppress
-subsequent warnings in the chef-client run.
-
-If this setting is changed to 'false' then it will adopt Chef-13 style behavior and will default all chef_gem installs to not run at compile_time by default.  This
-may break existing cookbooks.
-
-* All existing cookbooks which require compile_time true MUST be updated to be explicit about this setting.
-* To be considered high quality, cookbooks which require compile_time true MUST be rewritten to avoid this setting.
-* All existing cookbooks which do not require compile_time true SHOULD be updated to be explicit about this setting.
-
-For cookbooks that need to maintain backwards compatibility a `respond_to?` check should be used:
-
-```
-chef_gem 'aws-sdk' do
-  compile_time false if respond_to?(:compile_time)
-end
-```
-
-## Knife Bootstrap Validatorless Bootstraps and Chef Vault integration
-
-The knife bootstrap command now supports validatorless bootstraps.  This can be enabled via deleting the validation key.
-When the validation key is not present, knife bootstrap will use the user key in order to create a client for the node
-being bootstrapped.  It will also then create a node object and set the environment, run_list, initial attributes, etc (avoiding
-the problem of the first chef-client failing and not saving the node's run_list correctly).
-
-Also knife vault integration has been added so that knife bootstrap can use the client key to add chef vault items to
-the node, reducing the number of steps necessary to bootstrap a node with chef vault.
-
-There is no support for validatorless bootstraps when the node object has been precreated by the user beforehand, as part
-of the process any old node or client will be deleted when doing validatorless bootstraps.  The old process with the validation
-key still works for this use case.  The setting of the run_list, environment and json attributes first via knife bootstrap
-should mitigate some of the need to precreate the node object by hand first.
-
-
-## Windows service now has a configurable timeout
-
-You can now set the amount of time a chef-client run is allowed when running the provided windows service. This can be configured by
-setting `windows_service.watchdog_timeout` in your `client.rb` to the number of seconds desired. The default value is 2 hours.
diff --git a/lib/chef/knife/search.rb b/lib/chef/knife/search.rb
index a6cec761ce..9319d30e7d 100644
--- a/lib/chef/knife/search.rb
+++ b/lib/chef/knife/search.rb
@@ -106,8 +106,7 @@ class Chef
             formatted_item = Hash.new
             if item.is_a?(Hash)
               # doing a little magic here to set the correct name
-              formatted_item[item["data"]["__display_name"]] = item["data"]
-              formatted_item[item["data"]["__display_name"]].delete("__display_name")
+              formatted_item[item["__display_name"]] = item.reject{|k| k == "__display_name"}
             else
               formatted_item = format_for_display(item)
             end
diff --git a/lib/chef/provider/package.rb b/lib/chef/provider/package.rb
index de6d399ee3..2e8e29981b 100644
--- a/lib/chef/provider/package.rb
+++ b/lib/chef/provider/package.rb
@@ -25,6 +25,7 @@ require 'chef/platform'
 class Chef
   class Provider
     class Package < Chef::Provider
+      include Chef::Mixin::Command
       include Chef::Mixin::ShellOut
 
       #
@@ -54,8 +55,11 @@ class Chef
           a.whyrun("Assuming a repository that offers #{forced_packages_missing_candidates.join(", ")} would have been configured")
         end
 
+        # XXX: Does it make sense to pass in a source with :upgrade? Probably
+        # not, but as with the above comment, we don't yet enforce such a thing,
+        # so we'll just leave things as-is for now.
         requirements.assert(:upgrade, :install) do |a|
-          a.assertion  { candidates_exist_for_all_uninstalled? }
+          a.assertion  { candidates_exist_for_all_uninstalled? || new_resource.source }
           a.failure_message(Chef::Exceptions::Package, "No candidate version available for #{packages_missing_candidates.join(", ")}")
           a.whyrun("Assuming a repository that offers #{packages_missing_candidates.join(", ")} would have been configured")
         end
diff --git a/lib/chef/version.rb b/lib/chef/version.rb
index 486a3b516d..3189356996 100644
--- a/lib/chef/version.rb
+++ b/lib/chef/version.rb
@@ -17,7 +17,7 @@
 
 class Chef
   CHEF_ROOT = File.dirname(File.expand_path(File.dirname(__FILE__)))
-  VERSION = '12.1.0'
+  VERSION = '12.1.1'
 end
 
 #