jkeiser

#--
# Author:: Daniel DeLeo (<dan@opscode.com>)
# Author:: John Keiser (<jkeiser@opscode.com>)
# Copyright:: Copyright (c) 2011 Opscode, Inc.
# License:: Apache License, Version 2.0
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#

jkeiser

%% -*- erlang-indent-level: 4;indent-tabs-mode: nil; fill-column: 92 -*-
%% ex: ts=4 sw=4 et
%%% @author John Keiser <jkeiser@opscode.com>
%%% @copyright Copyright 2012-2012 Opscode Inc.
%%% @doc
%%% REST resource for creating and listing push jobs
%%% @end
-module(pushy_jobs_resource).

-export([init/1,

jkeiser

Hey all,

The knife-essentials commands (knife diff, download, upload, show, list, delete, raw, deps, edit, xargs) have received a major update in master to match knife-essentials 1.3. Some of the bigger changes:

New Commands

knife deps

The knife deps command lets you determine all the dependencies of a given node, role, or cookbook--all the things you would need to upload for it to run. It will run this dependency analysis on your local repository, unless you specify the --remote option.

jkeiser

1 Minute To First Converge

It takes a while to first learn Chef, even with http://learnchef.com. I'd like to get that time down. One of the big hurdles a new user encounters is the need for a server to do many important tasks. A second hurdle is a large amount of configuration and privileges the user needs.

I'd like to get learning Chef down to a 3-step, less than one minute experience of joy and success. And I don't want to do it by building special tools you only use when you're starting up; you should only be doing things that will stand you in good stead as you get more advanced.

The plan

Here's the 3-step of my dreams:

jkeiser

Node Proposal

The "node" concept in Chef right now suffers from a conflation problem between desired node state, and actual node state. This causes a couple of problems:

• Users configure nodes (run lists, tags, attributes) and it sometimes gets overwritten by chef-client
• When editing and viewing node configuration, the data in some views are heavily confused because it is overrun by ohai attributes

Solution: split node configuration (stuff the user passes as input for the node) from runtime data (stuff detected by ohai and spit out at the end of a run) in the Chef server to avoid the config data getting overwritten when data is output (and vice versa). config and runtime are merged during GET /nodes/NAME so that things work seamlessly with Chef 10 and 11 clients.

jkeiser

➜  prod  knife show -VV /cookbooks/adpwchanger/metadata.rb
DEBUG: Signing the request as jkeiser
DEBUG: ---- HTTP Status and Header Data: ----
DEBUG: HTTP 1.1 200 OK
DEBUG: server: nginx/1.0.12
DEBUG: date: Tue, 15 Oct 2013 16:29:43 GMT
DEBUG: content-type: application/json; charset=utf-8
DEBUG: transfer-encoding: chunked
DEBUG: connection: close
DEBUG: status: 200 OK

jkeiser

Setting up with Chef, Windows Version

I decided I'd do some work on Windows today, and noticed a lot of my software was out of date, and there were new dev tools that I want to install. I am tired of installing this shit over and over again every time I have a new computer or wipe the OS. Thankfully, that's what Chef is for! So time for an experiment. Now that chef-client -z is out in Chef 11.8 (yay!) it's time to take the leap and start using Chef to set up my Windows 7 workstation. My goal is modest(ish):

• Update HipChat (I want to use the new Windows msi instead of the Adobe Air version)
• Update Sublime Text 3 (don't need to first-install it yet)
• Use the development console tools outlined here

The stretch:

jkeiser

chef-client -z: From Zero To Chef In 8.5 Seconds

In Chef 11.8, we're excited to introduce local mode with chef-client -z. Designed to get people up and running with Chef as quickly as possible, local mode harnesses the power of chef-zero to let you run recipes and work with the full power of Chef locally without the need to set up a server, register and grab keys, configure the client, or switch to root. It is designed to handle many scenarios, including:

1. Beginners: Local mode lets a new user run their first recipe as fast as possible: install Chef, write recipe, chef-client -z -o cookbookname, done!
2. Rapid Recipe Development: with local mode, you can chef-client, change your recipe/data bags/roles/whatever, and chef-client again with no steps in between.
3. Solo Use: Makes it easy to configure a local workstation of server with Chef, while allowing an easy transition to a real Chef server to handle multip

jkeiser

Installing My Blog

I want to install Ghost as my blog. I want the web server, ghost, and OS, all to receive security updates on a regular schedule without me having to muck with it. (I am willing for the blog to sometimes go down because of this.)

I'll eventually want monitoring and alerting, and backups of the blog entries; uploads of the static site to my web hosting company; automatic DNS configuration; updates of the base OS. But for now I'm modest, I just want Ghost and I want updates.

I want to do this all with Chef. I want to write the Ghost cookbook myself, not because the existing Ghost cookbook is bad, but because I want to get a real feel for how these get written.

Getting Started: Test Kitchen

jkeiser

Provider location proposal (File.exists?)

This proposal attempts to solve two problems:

• The fact that it is hard to create Resources and Providers outside the Chef:: namespace
• The fact that classes in the Chef::Resource and Chef::Provider namespace (like File) make it harder to write providers (calling File.exists? fails because it grabs Chef::Provider::File instead of ::File)

Easy Outside Provider Declarations