Irving Popovetsky irvingpop

Download the database:

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

Change the first line from:

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

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

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"

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

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

	#!/opt/opscode/embedded/bin/ruby
	#
	# Author:: Lamont Granquist (<[email protected]>)
	# 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
	#

	#!/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

	# 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

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

	-define(SELF, '[email protected]').
	-define(BIFROST, '[email protected]').
	-define(BIFROST_COOKIE, 'oc_bifrost').
	-define(ERCHEF, '[email protected]').
	-define(ERCHEF_COOKIE, 'erchef').

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

	# 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