irvingpop

#!/opt/opscode/embedded/bin/ruby
#
# Author:: Lamont Granquist (<lamont@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
#

irvingpop

1. Download the database:

curl http://localhost:5984/mydb/_all_docs?include_docs=true > mydb.json

2. Change the first line from:

    {"total_rows":1121,"offset":0,"rows":[
    *TO*
    {"docs":[

irvingpop

backend systems:

• c3.2xlarge - EBS optimized and Enhanced Networking enabled
• DRBD backing volume: 80 GB SSD (ec2 ephemeral storage /dev/xvdb)
• Ubuntu Trusty official release from 11/26/2014
• DRBD 8.4.3 (packaged in Ubuntu kernel extras package)

root@ip-ub-backend1:~# uname -a
Linux ip-ub-backend1.trusty.aws 3.13.0-40-generic #69-Ubuntu SMP Thu Nov 13 17:53:56 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

irvingpop

#!/usr/bin/env ruby

LVM_LV = '/dev/opscode/drbd'
LVM_LV_MOUNT = '/var/opt/opscode/drbd/data'
LVM_SNAP_SIZE = '16G'
FILE_SIZE_MB = 1024
NUM_FILES = 15

def write_files(iterations)
  aggregate_speed = 0

irvingpop

As of March 24, 2015 that the 'windows-guest-support' branch of test-kitchen has been merged to master, but not the equivalent kitchen-vagrant branch.

Using the Windows cookbook, Gemfile like so:

source "https://rubygems.org"

group :development do
  gem "test-kitchen", :git => 'https://github.com/test-kitchen/test-kitchen.git'
  gem 'kitchen-vagrant', git: 'https://github.com/test-kitchen/kitchen-vagrant.git', :branch => 'windows-guest-support'
  gem "berkshelf"

irvingpop

# NOTE:  set all of the workers values to equal the number of CPU cores on the Analytics server

analytics_fqdn "analytics.trusty.aws"
topology "standalone"

alaska['max_task_parallelism'] = 130

alaska['action_queue'] = {}
alaska['action_queue']['workers'] = 8
alaska['action_queue']['max_spout_pending'] = 100

irvingpop

Connecting to your Chef server as an admin, via the API

# launch pry
/opt/opscode/embedded/bin/pry 
[1] pry(main)> require 'chef/rest'
=> true

# create a Chef::REST object pointed at localhost with the pivotal user and pivotal.pem (required for admin operations)
[2] pry(main)> chef_rest = Chef::REST.new('https://localhost/', 'pivotal', '/etc/opscode/pivotal.pem')

irvingpop

#!/opt/opscode/embedded/bin/escript

-define(SELF, 'monitor@127.0.0.1').
-define(BIFROST, 'oc_bifrost@127.0.0.1').
-define(BIFROST_COOKIE, 'oc_bifrost').
-define(ERCHEF, 'erchef@127.0.0.1').
-define(ERCHEF_COOKIE, 'erchef').

get_waiting(Node, Cookie) ->
    erlang:set_cookie(node(), Cookie),

irvingpop

# replaces this file /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/providers/virtualbox/action/sane_defaults.rb
# NOTE: if using a different Vagrant version, adjust the version field accordingly
# NOTE2: only the sections with the IRVING comment have been changed from the default

require "log4r"

module VagrantPlugins
  module ProviderVirtualBox
    module Action
      class SaneDefaults

irvingpop

Customer Scenario

A customer has a Chef Server 12 (HA - DRBD) in Production. They want to test an in-place upgrade (or maintenance) using their current OPC Production data and config. This gives us a good chance to make corrections if we find that their data is too broken for the migrations to handle, and gives the customer experience in managing the upgrade in Production.

The sequence of events will broadly be these:

• Install the same version of Chef Server on the target HA Test cluster
• Restore data from Production instance backup (LVM snapshot or full-stop backup)
• Test