----
Chef Client 12.4.0 Released
// Chef Blog
Ohai Chefs, We've just released Chef Client 12.4.0. This release has a lot of new things: Better logging options, Windows experience improvements, Resource DSL enhancements, and much more. You can read about some of the changes below. A full list of changes can be found in the changelog.
What's New
Knife Key Management Commands for Users and Clients in Chef Server 12.1
knife user and knife client now have a suite of subcommands that live under the key subcommand. These subcommands allow you to list, show, create, delete and edit keys for a given user or client. They can be used to implement key rotation with multiple expiring keys for a single actor or just for basic key management. See knife user key and knife client key for a full list of subcommands and their usage.
System Loggers
You can now have all Chef logs sent to a logging system of your choice.
Syslog Logger
Syslog can be used by adding the following line to your chef config file:
log_location Chef::Log::Syslog.new("chef-client", ::Syslog::LOG_DAEMON) This will write to the daemon facility with the originator set as chef-client.
Windows Event Logger
The logger can be used by adding the following line to your chef config file:
log_location Chef::Log::WinEvt.new
This will write to the Application log with the source set as Chef.
RemoteFile resource supports UNC paths on Windows
You can now use UNC paths with remote_file on Windows machines. For example, you can get Foo.tar.gz off of fooshare on foohost using the following resource:
remote_file 'C:\Foo.tar.gz' do source "\\\\foohost\\fooshare\\Foo.tar.gz" end
WindowsPackage resource supports URLs
The windows_package resource now allows specifying URLs for the source attribute. For example, you could install 7zip with the following resource:
windows_package '7zip' do source "http://www.7-zip.org/a/7z938-x64.msi" end
Internally, this is done by using a remote_file resource to download the contents at the specified url. If needed, you can modify the attributes of the remote_file resource using the remote_file_attributes attribute. The remote_file_attributes accepts a hash of attributes that will be set on the underlying remote_file. For example, the checksum of the contents can be verified using
windows_package '7zip' do source "http://www.7-zip.org/a/7z938-x64.msi" remote_file_attributes { :path => "C:\\7zip.msi", :checksum => '7c8e873991c82ad9cfcdbdf45254ea6101e9a645e12977dcd518979e50fdedf3' } end
To make the transition easier from the Windows cookbook, windows_package also accepts the checksum attribute, and the previous resource could be rewritten as:
windows_package '7zip' do source "http://www.7-zip.org/a/7z938-x64.msi" checksum '7c8e873991c82ad9cfcdbdf45254ea6101e9a645e12977dcd518979e50fdedf3' end
Powershell wrappers for command line tools
There is now an optional feature in the msi that you can enable during the installation of Chef client that deploys a powershell module alongside the rest of your installation (usually at C:\opscode\chef\modules\). This location will also be appended to your PSModulePath environment variable. Since this feature is experimental, it is not automatically enabled. You may activate it by running the following from any powershell session
Import-Module chef
You can also add the above to your powershell profile at ~\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
The module exports a number of cmdlets that have the same name as the Chef command line utilities that you already use – such as chef-client, knife and chef-apply. What they provide is the ability to cleanly pass quoted argument strings from your powershell command line without the need for excessive double-quoting. See https://github.com/chef/chef/issues/3026 or https://github.com/chef/chef/issues/1687 for an examples.
Previously you would have needed
knife exec -E 'puts ARGV' """&s0meth1ng""" knife node run_list set test-node '''role[ssssssomething]'''
Now you only need
knife exec -E 'puts ARGV' '&s0meth1ng' knife node run_list set test-node 'role[ssssssomething]'
If you wish to no longer use the wrappers, run
Remove-Module chef
Resource Authoring Changes for LWRP/HWRP Developers
Resources may now specify resource_name to get DSL
When you declare a resource class, you may call resource_name to get recipe DSL for it.
module MyModule class MyResource < Chef::Resource resource_name :my_resource # Names the resource "my_resource" end end
When this happens, the resource can be used in a recipe:
my_resource 'blah' do end
If you have an abstract class that should not have DSL, you may set resource_name to nil (this is only really important for classes in Chef::Resource which get DSL automatically):
class Chef class Resource # This will not have DSL class MyBaseResource < Chef::Resource resource_name nil end # This will have DSL `my_resource` class MyResource < MyBaseResource end end end
When you do this, my_base_resource will not work in a recipe (but my_resource will).
You can still use provides to provide other DSL names:
module MyModule class MyResource < Chef::Resource provides :super_resource end end
Which enables this recipe:
super_resource 'wowzers' do end
(Note that when you use provides in this manner, resourcename will be my_resource and declaredtype will be super_resource. This won't affect most people, but it is worth noting as a matter of explanation.)
Users are encouraged to declare resources in their own namespaces instead of putting them in the Chef::Resource namespace.
Resources may now use allowed_actions and default_action
Instead of overriding Chef::Resource.initialize and setting @allowed_actions and @action in the constructor, you may now use the allowed_actions and default_action DSL to declare them:
class MyResource < Chef::Resource allowed_actions :create, :delete default_action :create end
Resource provides now has intuitive automatic rules
provides is how a Resource or Provider associates itself with the Chef recipe DSL on different OS's. Now when multiple resources or providers say they provide the same DSL, "specificity rules" are applied to decide the priority of these rules. For example:
class GenericFile < Chef::Resource provides :file end class LinuxFile < Chef::Resource provides :file, os: 'linux' end class DebianFile < Chef::Resource provides :file, platform_family: 'debian' end
This means that if I run this recipe on Ubuntu, it will pick DebianFile:
file 'x' do end
Now, no matter what order those resources are declared in, the resource lookup system will choose DebianFile on Debian-based platforms since that is the most specific rule. If a platform is Linux but not Debian, like Red Hat, it will pick LinuxFile, since that is less specific.
The specificity order (from highest to lowest) is:
- provides :x, platform_version: '12.4.0'
- provides :x, platform: 'ubuntu'
- provides :x, platform_family: 'debian'
- provides :x, os: 'linux'
- provides :x
This means that a class that specifies a platform_version will *always* be picked over any other provides line.
Warnings when multiple classes try to provide the same resource DSL
We now warn you when you are replacing DSL provided by another resource or provider class:
class X < Chef::Resource provides :file end class Y < Chef::Resource provides :file end
This will emit a warning that Y is overriding X. To disable the warning, use override: true:
class X < Chef::Resource provides :file end class Y < Chef::Resource provides :file, override: true end
LWRPs are no longer automatically placed in the Chef::Resource namespace
Starting with Chef 12.4.0, accessing an LWRP class by name from the Chef::Resource namespace will trigger a deprecation warning message. This means that if your cookbook includes the LWRP mycookbook/resources/myresource.rb, you will no longer be able to extend or reference Chef::Resource::MycookbookMyresource in Ruby code. LWRP recipe DSL does not change: the LWRP will still be available to recipes as mycookbook_myresource.
You can still get the LWRP class by calling Chef::ResourceResolver.resolve(:mycookbook_myresource).
The primary aim here is clearing out the Chef::Resource namespace.
References to these classes is deprecated (and will emit a warning) in Chef 12, and will be removed in Chef 13.
How do I get it?
You can visit our download page.
Additionally you can use this command to download the latest version of the Chef Client on platforms other than windows:
curl -L https://www.chef.io/chef/install.sh | sudo bash -s -- -v 12.4.0
For Windows, you can download this version using this link: Chef Client 12.4.0
Get Help
If you run into any issues with this release, please file an issue on Github or drop an email on our chef and chef-dev mailing lists.
----
Shared via my feedly reader
Sent from my iPhone
No comments:
Post a Comment