Chef Community Summit – London

This year’s Chef Community Summit in London will be held November 3 and 4 and we hope to see you there.  Registration is open now, read on for more details.

This marks our second Chef Community Summit in Europe.  This year’s Summit will include a single-track of presentations on November 3 and Open Spaces on November 4.  Talks will be from our own Chef engineers, leaders, and community members.  There will be presentations on topics such as Chef Roadmap, Compliance at Velocity, Chef Provisioning, Analytics, Test Kitchen and Community Participation.

The second day of the Summit is organized as a facilitated Open Space event. This type of event helps ensure that everyone has a chance to participate, the topics discussed are the right topics, and the outcomes are best for everyone.

Community Summits are a terrific place to talk about whatever keeps you up at night regarding Chef or devops. You’ll see a wide variety of topics at the Summit, from deep dives into technical specific problems to “ask me anything” sessions about Chef.  What you need to bring is your energy and questions.

Early bird tickets are available for £150.00 each. Registration for this event is limited, so please register today!

Summit Location**

etc.venues Monument
8 Eastcheap, Floor 2
London EC3M 1AE

Search for nearby hotel accommodations

Questions? Email us at summit@chef.io

 

**Is London a little too far for you to travel? We’ll be hosting our US-based summit in Seattle October 14-15.

Posted in announcements, community, events

Chef Client 12.4.0 Released

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:

  1. provides :x, platform_version: ‘12.4.0’
  2. provides :x, platform: ‘ubuntu’
  3. provides :x, platform_family: ‘debian’
  4. provides :x, os: ‘linux’
  5. 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.

Posted in release

Inclusion

It was early April, and I arrived in Santa Clara in the days preceding ChefConf 2015. Levi’s Stadium and the surrounding area was filled with 125,000 wrestling fans. There were seven matches on the main card. The Undertaker contested his first match in almost a year. The Levi’s Stadium attendance record was smashed by six thousand people.

Men, women, families, friends, afros, mullets, tank tops, leather pants, folding chairs, wheelchairs… it seemed as if every possible variant of humanity from all fifty states and forty countries were in Santa Clara, ready to rumble.

In the Hyatt Regency lobby following the main event, it was clear that we have something to learn from WrestleMania about inclusion.

What does it mean to be inclusive? What does it mean when we talk about race, sex, sexual orientation, differences in abilities, and the intersection of all these things?

Read more ›

Posted in community, culture Tagged with: , , , ,

Chef Workflow at CenturyLink Cloud

Matt Wrock is a Principal Software Engineer at CenturyLink Cloud, where he works on data center automation. Many of you are already familiar with Matt from his blog Hurry Up and Wait! Matt writes about many aspects of software engineering, including Chef. He spoke on Entering the Chef Ecosystem From a Windows Background at ChefConf 2015, where he also received the title of Awesome Community Chef. Matt is the project founder of Boxstarter, which automates Windows installations and is a contributor to Chocolatey, a package manager for Windows.

In this blog post, Matt takes us through the Chef-based workflow that he and his team have adopted to automatically update CenturyLink Cloud’s infrastructure in an existing data center.

Creating the local environment

The workflow begins with local development. The following diagram shows the local development environment for creating cookbooks. This environment lives inside of a Vagrant box that is used by anyone at CenturyLink Cloud who works with Chef.

centurylink-diagrams-01

Matt says “We have a repo that’s our application repo. That includes one cookbook, our workstation cookbook, called chef_workstation. That cookbook sets up such things as Chef DK, the links to our Berkshelf API server, links to our Nexus repository manager, the internal gems, Docker and a Rakefile for testing. The cookbook is consumed by a Vagrant file, which first builds an Ubuntu image and then runs the cookbook. When it’s done, you’re in a prompt where knife commands work, you have access to Test Kitchen, and our vSphere provisioning driver.”

Matt noted that, for consistency, the same cookbook that builds the workstations also creates the build agents. If tests pass locally, there’s a good chance that they’ll pass on the test agents. Matt’s team uses TeamCity as its build server.

Read more ›

Posted in awesome chefs, chef, cloud, community, customers

Chef at the 2015 Red Hat Summit

Red Hat Summit Please join Chef this week in Boston at the 2015 Red Hat Summit! This is your chance to learn more about Red Hat’s plans for not just Red Hat Enterprise Linux but the many other open source products they work on and provide.

Chef supports Red Hat Enterprise Linux across all of our client, developer and server products. While we currently support Red Hat Enterprise Linux 5, 6, and 7 on x86, we will be adding support for Red Hat Enterprise Linux 7.1 on POWER very soon (contact partnereng@chef.io for early access). We also work with their OpenStack offerings and are looking into their newer offerings like OpenShift and ManageIQ.

We recently did a cookbook to kick the tires on Red Hat’s new Project Atomic, a container-based application and services deployment operating system. The cookbook provisions virtual Atomic hosts on top of CentOS 7, deploying the Docker registry, Flannel virtual networking, etcd for service registry, and Kubernetes for cluster management. Stop by the booth and we’d love to show it in action and talk about how the cookbook and Project Atomic work.

We’ll be in booth 1101 and we’re getting started at the Welcome Reception Tuesday night and handing out swag. We’ll be there all week and we’re looking forward to talking about Chef, Red Hat, and anything else you want to discuss.

Posted in community

Security Releases: Chef Server 12, Enterprise Chef 11, Chef Manage

Ohai Chefs!

Today we have releases of Chef Server 12.1.0, Enterprise Chef Server 11.3.2, and Chef Manage 1.17.0 which contain the following security updates:

  • Redis 2.8.21

This update addresses CVE-2015-4335, a remote code execution vulnerability in Redis. We recommend that users of Chef Manage and of Chef Server in HA or Tiered topologies update as soon as possible. Open Source Chef Server 11 is not affected. Supermarket will ship with an updated Redis in the next release. Chef Servers in a standalone configuration are configured such that Redis only listens for local connections; however, we still encourage everyone to upgrade.

Updated packages are available for immediate download on http://downloads.chef.io and via our Apt and RPM repositories.

In addition to this security update, Chef Server 12.1.0 has performance improvements, new features, and bug fixes. Please see the Chef Server 12.1 Release Announcement.

Posted in announcements, release, security Tagged with: , ,

Chef Server 12.1 Release Announcement

Ohai Chefs!

I’m pleased to announce that Chef Server 12.1.0 is now available for download on the Chef Downloads Page and via our Apt and RPM repositories. Here are some of this release’s highlights:

  • Significant performance improvements.
  • Policyfile APIs are significantly more complete and are enabled by default.
  • Server API Versioning: API 0 is now deprecated, and current API version level is 1.
  • Key Rotation enhancements.
  • Security update from postgres 9.2.9 to 9.2.10.
  • Solr update from 4.5.1 to 4.9.1.
  • Redis updated to 2.8.21
  • Erlang updated from R16B03-1 to 17.5
  • JRE update from 7u25 to 8u31, which includes both security and performance improvements
  • Multiple bug fixes and component updates.
  • A number of improvements made to enhance the overall quality of Chef Server, streamline testing, and to make contributing to Chef Server as straight-forward as possible.

    Read more ›

Posted in announcements, release Tagged with:

Darwin, Dodd-Frank and the Lean Enterprise

What are the biggest ideas that will shape 21st Century companies?

Opinions vary, but here’s my nomination for the top three:

  1. Natural Selection. The basic idea is that, over many iterations, the fittest are selected, and the weak wither away. Natural selection has been applied to economics, management theory (read corporate politics), computer programming and other disciplines.
  2. Conway’s Law. Conway’s Law states that organizations create systems that resemble their communication structures. If the idea of fitness became pervasive in the 20th century, the story of modern corporate change in the 21st is one of breaking down silos, especially between functional contributors to the product development process. DevOps is a famous example. Some extend it to DevSecOps. What’s next? MarkDevSecOps? FinDevMarkSecOps?
  3. Lean principles. Lean principles were first applied to manufacturing, but the core precepts of Lean thinking have since been applied to many different types of production lines, including software. The main idea is that if you focus on customer value and remove everything that does not contribute to it, you have an efficient, high-value process.
Here’s why I believe these three ideas are so important. External regulatory frameworks are not themselves responsible for the existence of competition, but they set the boundaries of the game. In other words, they alter the environment in which naturally occuring economic selection takes place. The beak of the finch has to meet EU standards!

Read more ›

Posted in catv, devops, security, webinar

Chef Server 12.1.0 RC3 Now Available

Ohai Chefs,

We’re pleased to announce that Chef Server 12.1.0 RC3 is now available for download. RC3 is the follow-up to RC1, which we announced on May 28th.

What’s New Since RC1

  • Erlang 17: We’ve upgraded the Erlang distribution that we ship with the Chef Server to Erlang 17.5
  • Solr Upgrade Fixes: We’ve fixed an issue that prevented Chef Server from running the latest version of Solr after an upgrade. If you upgraded from a previous version, you would continue to run the version of Solr that shipped with that Chef Server.
  • Actions Messages Password Filtering: The Chef Server now filters out password information before sending data off to the Chef Analytics queue.

What happened to RC2

We had to skip RC2 for this release because it encountered a failure during the build and release process. Remediations were made to the process and the version was bumped to RC3 accordingly. RC3 is the follow-up release to RC1.

Where Can I Download It

Release Candidate builds of the Chef Server can be downloaded from the Packagecloud current repository. The direct links to the build are:

Posted in community

Introducing feedback.chef.io

Chef’s Product team is pleased to announce the launch of feedback.chef.io, our new site for collecting and responding to product feedback.  The site hosts three feedback forums, one each for Chef, Analytics and Delivery.  The Delivery forum is currently invite-only for participants in the early access program, but will be made public in the future.

The Product and Engineering teams at Chef are incorporating this new feedback channel into our planning and prioritization, based on what we hear from all of you.  Effective today, feedback.chef.io becomes “source of truth” for Chef to respond to your product ideas.  We invite all of our users to visit the site to create their own requests, as well as to comment and vote on feedback from other members of the Chef community.
 
Requests for support should continue to be directed to support@chef.io or by using our web-based ticket interface as described here.
 
This has no impact on the existing RFC process for Chef’s open source projects, which will remain as-is.  We anticipate that when appropriate, ideas from feedback.chef.io will flow into the RFC process. Bugs for open source Chef products will continue to be worked through github, but higher-level feature requests should be submitted here.
 
If you have any questions or suggestions, please post a comment below.  We want to make this tool as useful as it can be.  Now let’s get started!

Posted in analytics, announcements, chef, community, Delivery, engineering