mastrolinux

datadog-repo:
  pkgrepo:
    - managed
    - humanname: "DataDog Agent"
    - name: deb http://apt.datadoghq.com/ unstable main
    - keyserver: keyserver.ubuntu.com
    - keyid: C7A7DA52
    - file: /etc/apt/sources.list.d/datadog.list

datadog-pkg:

ranjib

Chef 11 introduces event dispatching mechanism, which emits event at different milestones in Chef run (aka lifecycle) , and users can add their custom handlers to hook into these events. Chef formatters already uses this API. For a complete list of currently available events check this

Following is a bare minimal example for adding a custom handler:

chef_event_handler_foo.rb

require 'chef/event_dispatch/base'
class Foo < Chef::EventDispatch::Base
  # lets say hello world when chef run ends
 def run_completed(node)

tobert

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv4.ip_forward=0
net.ipv6.conf.all.forwarding=0
kernel.sysrq = 1
kernel.panic = 300
fs.file-max = 1048576
kernel.pid_max = 999999
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 65536 16777216

nzakas

I'm doing some research on how companies use GitHub Enterprise (or public GitHub) internally. If you can help out by answering a few questions, I'd greatly appreciate it.

1. What is the primary setup? Is there an organization and each official repo is owned by that organization?
2. Does every engineer have a fork of each repo they're working on?
3. Are engineers allowed to push directly to the official repo? Or must all commits go through a pull request?
4. Do engineers work on feature branches on the main repo or on their own forks?
5. Do you require engineers to squash commits and rebase before merging?
6. Overall, what is the workflow for getting a new commit into the main repository?
7. What sort of hooks do you make use of?
8. Are there any ops issues you encountered? (Scaling, unforeseen downtime, etc.)

fnichol

SUITE_NAME=default

# create a bats subdirectory under your desired suite
mkdir -p test/integration/$SUITE_NAME/bats

# create an initial "canary" bats test file
# more examples at:
# * https://github.com/fnichol/chef-rvm/tree/master/test/integration/rubies/bats
# * https://github.com/fnichol/chef-ruby_build/tree/master/test/integration/alltherubies/bats
# * https://github.com/sstephenson/bats

jayjanssen

net.core.somaxconn = 32768
net.ipv4.conf.all.send_redirects = 1
net.ipv4.ip_nonlocal_bind = 1
net.ipv4.tcp_abort_on_overflow = 0
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 16384
net.ipv4.tcp_max_tw_buckets = 262144
net.ipv4.tcp_mem = 200000    280000    300000

tobert

# save some memory on indexes
index_interval: 512

# this can hurt your read latency, but in my experience it's better to stay caught up
compaction_throughput_mb_per_sec: 0

# if you have lots & lots of connections, e.g. from Hadoop, saves memory
rpc_server_type: hsha

alq666

require 'rubygems'
require 'dogapi'

# Create a simple client
# The host is optional here, it's a shortcut to tie event and metrics to a given host
#
# You typically want to do:
#   Dogapi::Client.new(your_actual_api_key_as_a_string, ...)
# We are using ENV to let you experiment via an environment variable.
dog = Dogapi::Client.new(ENV['DATADOG_KEY'])

jtimberman

This is idea brainstorming for a community plugin for releasing cookbooks per Opscode's current process. This would replace the functionality of the "cookbook site share" plugin that is built into Chef, as I believe the cookbook site plugins should use "community" rather than "cookbook site" and be a separate plugin instead of built into Chef and tied to its release cycle.

knife community release COOKBOOK VERSION

Assumes that the repository is release ready, e.g., the current HEAD is the commit that should be released, CHANGELOG is updated already, etc.

1. sets metadata version to the specified VERSION
2. makes a git commit with the release VERSION in the metadata
3. creates a git tag with the bare version, e.g. "1.0.1" not "v1.0.2"
4. pushes to the opscode (or other upstream as apropos) master branch, takes --remote argument as alternate, and pushes git tags

fujin

#!/usr/bin/env ruby

cbdir=ARGV[0]
output = "./deps.dot"

puts "Running on #{cbdir}..."

cb_meta = Dir.glob("#{cbdir}/*/metadata.rb")

fp=File.open(output,"w")