diff options
-rw-r--r-- | CHANGELOG.md | 16 | ||||
-rw-r--r-- | DOC_CHANGES.md | 78 | ||||
-rw-r--r-- | RELEASE_NOTES.md | 153 | ||||
-rw-r--r-- | lib/chef/knife/search.rb | 3 | ||||
-rw-r--r-- | lib/chef/provider/package.rb | 6 | ||||
-rw-r--r-- | lib/chef/version.rb | 2 |
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 # |