-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
21 additions
and
43 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,57 +1,35 @@ | ||
*This file holds "in progress" release notes for the current release under development and is intended for consumption by the Chef Documentation team. | ||
Please see `https://docs.chef.io/release/<major>-<minor>/release_notes.html` for the official Chef release notes.* | ||
|
||
# Chef Client Release Notes 12.11: | ||
# Chef Client Release Notes 12.12: | ||
|
||
## Support for RFC 062-based exit codes | ||
## Attribute read/write/unlink/exist? APIs | ||
|
||
[Chef RFC 062](https://github.com/chef/chef-rfc/blob/master/rfc062-exit-status.md) identifies standard exit codes for Chef Client. As of this release, When Chef exits with a non-standard exit code, a deprecation warning will be printed. | ||
On the node object: | ||
|
||
Also introduced is a new configuration setting - `exit_status`. | ||
- `node.read("foo", "bar", "baz")` equals `node["foo"]["bar"]["baz"] `but with safety (nil instead of exception) | ||
- `node.read!("foo", "bar", "baz")` equals `node["foo"]["bar"]["baz"]` and does raises NoMethodError | ||
|
||
By default in this release, `exit_status` is `nil` and the default behavior will be to warn on the use of deprecated and non-standard exit codes. `exit_status` can be set to `:enabled`, which will force chef-client to exit with the RFC defined exit codes and any non-standard exit statuses will be converted to `1` or GENERIC_FAILURE. `exit_status` can also be set to `:disabled` which preserves the old behavior of non-standardized exit status and skips the deprecation warnings. | ||
- `node.write(:default, "foo", "bar", "baz")` equals `node.default["foo"]["bar"] = "baz"` and autovivifies and replaces intermediate non-hash objects (very safe) | ||
- `node.write!(:default, "foo", "bar", "baz")` equals `node.default["foo"]["bar"] = "baz"` and while it autovivifies it can raise if you hit a non-hash on an intermediate key (NoMethodError) | ||
- there is still no non-autovivifying writer, and i don't think anyone really wants one. | ||
- `node.exist?("foo", "bar")` can be used to see if `node["foo"]["bar"]` exists | ||
|
||
## New Data Collector functionality for run statistics | ||
On node levels: | ||
|
||
The Data Collector feature is new to Chef 12.11 and is detailed in [Chef RFC 077](https://github.com/chef/chef-rfc/blob/master/rfc077-mode-agnostic-data-collection.md). It provides a unified method for sharing statistics about your Chef runs in a webhook-like manner. The Data Collector supports Chef in all its modes: Chef Client, Chef Solo (commonly referred to as "Chef Client Local Mode"), and Chef Solo legacy mode. | ||
- `node.default.read/read!("foo")` operates similarly to `node.read("foo")` but only on default level | ||
- `node.default.write/write!("foo", "bar")` is `node.write/write!(:default, "foo", "bar")` | ||
- `node.default.unlink/unlink!("foo")` is `node.unlink/unlink!(:default, "foo")` | ||
- `node.default.exist?("foo", "bar")` can be used to see if `node.default["foo"]["bar"]` exists | ||
|
||
To enable the Data Collector, specify the following settings in your client configuration file: | ||
Deprecations: | ||
|
||
* `data_collector.server_url`: Required. The URL to which the Chef Client will POST the Data Collector messages | ||
* `data_collector.token`: Optional. An token which will be sent in a `x-data-collector-token` HTTP header which can be used to authenticate the message. | ||
* `data_collector.mode`: The Chef mode in which the Data Collector should run. For example, this allows you to only enable Data Collector in Chef Solo but not Chef Client. Available options are `:solo`, `:client`, or `:both`. Default is `:both`. | ||
* `data_collector.raise_on_failure`: If enabled, Chef will raise an exception and fail to run if the Data Collector cannot be reached at the start of the Chef run. Defaults to `false`. | ||
* `data_collector.organization`: Optional. In Solo mode, the `organization` field in the messages will be set to this value. Default is `chef_solo`. This field does not apply to Chef Client mode. | ||
- node.set is deprecated | ||
- node.set_unless is deprecated | ||
|
||
## Replace chef-solo with chef-client local mode | ||
## `data_collector` enhancements | ||
|
||
The default operation of `chef-solo` is now the equivalent to `chef-client -z`, but allows for the old style `chef-solo` by uttering `chef-solo --legacy-mode`. As part of this effort, environment and role files written in ruby are now fully supported by `knife upload`. | ||
- Adds `node` to the `data_collector` message | ||
- `data_collector` reports on all resources and not just those that have been processed | ||
|
||
## Added a `systemd_unit` resource | ||
|
||
A new `systemd_unit` resource is now available. This resource supports the following properties: | ||
|
||
* `enabled` - boolean | ||
* `active` - boolean | ||
* `masked` - boolean | ||
* `static` - boolean | ||
* `user` - String | ||
* `content` - String or Hash | ||
* `triggers_reload` - boolean | ||
|
||
It has these possible actions: | ||
|
||
* `:nothing` - default | ||
* `:create` | ||
* `:delete` | ||
* `:enable` | ||
* `:disable` | ||
* `:mask` | ||
* `:unmask` | ||
* `:start` | ||
* `:stop` | ||
* `:restart` | ||
* `:reload` | ||
* `:try_restart` | ||
* `:reload_or_restart` | ||
* `:reload_or_try_restart` | ||
## `knife cookbook create` is deprecated. Use the chef-dk's `chef generate cookbook` instead. |