kky

#!/bin/sh

echo "What should the Application be called (no spaces allowed e.g. GCal)?"
read inputline
name=$inputline

echo "What is the url (e.g. https://www.google.com/calendar/render)?"
read inputline
url=$inputline

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")

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

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'])

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

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

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)

jedi4ever

@datadoghq - Overall well done! Here's some feedback:

Signup/User process

• when someone invites you to their datadog/team, you get an email but because you are already registered you can't join their team. Especially annoying for freelancers that work for multiple customers but don't have an email account at the customer site
• disable a user is scary (will this delete it, can I re-create it?); a warning or ? next to it would help for fast understanding
• if the user you invite does not have it's gmail activated yet (google for apps), when the email is added it's send out (but doesn't reach it of course). There is no way of re-sending the invite from the admin side
• the forcing of registering at least one agent/integration is really annoying. if you signup through an ipad or the person signing up (like billing) does not have any way to go past that screen. So you wonder , am I registered or not? In our case the person installed the mac agent from it's laptop to get it going. No need for that imho
• when

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:

fnichol

Format Changes to Test Kitchen's kitchen.yml File

This is happening thanks to a refactoring of the data manipulation code formerly in Kitchen::Config.

There are now 3 main configuration blocks that can be placed in the various levels:

• driver: Configurtation relavent to Kitchen drivers. This is a combination of what was driver_plugin and driver_config. Backwards compatability is guarenteed with the legacy formats for a time, then will be deprecated (with a warning when encountered), then will be removed in a future release.
• provisioner: Configuration relating to the automation tool being used. Currently supporting "chef_solo" and "chef_zero". Previously several Chef-related config paths were dumped in a Suite block, namely data_path, data_bags_path, environments_path, nodes_path, roles_path, etc. These will be supported for backwards compatability, then will be deprecated (with a warning when encountered), then will be removed in a future release.
• busser: Configuration rela