motherbrain 0.0.0.placeholder → 0.13.1

data/VAGRANT.md

@@ -0,0 +1,116 @@
+
+# Testing motherbrain Bootstrapping with Vagrant
+
+One of the things we'd like to do is have a Vagrant or Virtualbox/VMware/etc provisioner, so that you can test provisioning locally. Until this is completed, you can test bootstrapping to a set of Vagrant boxes.
+
+## Setup Vagrant
+
+First, make sure you have Vagrant installed by following the directions at [vagrantup.com](http://vagrantup.com). Test that Vagrant is installed correctly with `vagrant -v`:
+
+```
+$ vagrant -v
+Vagrant version 1.2.2
+```
+
+## Create a Vagrantfile
+
+We'll want a Vagrantfile that gives us a box to bootstrap. This file can be anywhere, but it might be best to place it in its own folder, such as `motherbrain-boxes`. Here's the simplest one possible for our needs:
+
+```rb
+Vagrant.configure('2') do |config|
+  config.vm.box = "opscode-centos-6.3"
+  config.vm.box_url = "https://opscode-vm.s3.amazonaws.com/vagrant/boxes/opscode-centos-6.3.box"
+  config.vm.network :private_network, ip: "33.33.33.101"
+end
+```
+
+If you wanted more than one box, you could use Ruby to create multiple boxes:
+
+```rb
+count = 3
+
+Vagrant.configure('2') do |config|
+  (1..count).each do |number|
+    config.vm.define name do |box|
+      box.vm.box = "opscode-centos-6.3"
+      box.vm.box_url = "https://opscode-vm.s3.amazonaws.com/vagrant/boxes/opscode-centos-6.3.box"
+      box.vm.hostname = "box#{number}"
+      box.vm.network :private_network, ip: "33.33.33.#{100 + number}"
+    end
+  end
+end
+```
+
+This will creates 3 boxes (box1, box2, box3) with sequential IP addresses (33.33.33.101, .102, .103).
+
+> A more advanced Vagrantfile can be found at [justincampbell/boxen](https://github.com/justincampbell/boxen). This provides support for specifying the numbers of boxes on the command line, and automatically modifies your `/etc/hosts` file with the box hostnames (`33.33.33.101 box1`).
+
+## Start Vagrant boxes
+
+Now just run `vagrant up`, and you should see the box being created:
+
+```
+motherbrain-boxes$ vagrant up
+Bringing machine 'default' up with 'virtualbox' provider...
+[default] Importing base box 'opscode-centos-6.3'...
+[default] Matching MAC address for NAT networking...
+[default] Setting the name of the VM...
+[default] Clearing any previously set forwarded ports...
+[default] Creating shared folders metadata...
+[default] Clearing any previously set network interfaces...
+[default] Preparing network interfaces based on configuration...
+[default] Forwarding ports...
+[default] -- 22 => 2222 (adapter 1)
+[default] Booting VM...
+[default] Waiting for VM to boot. This can take a few minutes.
+[default] VM booted and ready for use!
+[default] Configuring and enabling network interfaces...
+[default] Mounting shared folders...
+[default] -- /vagrant
+$
+```
+
+We now have a CentOS 6.3 machine waiting for us at `33.33.33.101`.
+
+## Configure motherbrain
+
+Next, we need to tell motherbrain to use the Vagrant SSH user and key. Assuming that we're bootstrapping a node with the "ohai" plugin (a simple cookbook with no dependencies), our bootstrap manifest should look like this:
+
+```json
+{
+  "options": {
+    "ssh": {
+      "user": "vagrant",
+      "keys": ["~/.vagrant.d/insecure_private_key"]
+    }
+  },
+  "nodes": [
+    {
+      "groups": ["ohai::default"],
+      "hosts": ["33.33.33.101"]
+    }
+  ]
+}
+```
+
+The SSH options above will override those in our motherbrain config. Save this file as `vagrant.json`.
+
+## Bootstrapping
+
+Now we're ready to bootstrap our node. We'll tell motherbrain to bootstrap our plugin (ohai in this case) with our `vagrant.json` manifest, and a Chef environment of our username with a `-vagrant` suffix:
+
+```
+ohai$ mb ohai bootstrap vagrant.json -e jcampbell-vagrant
+Determining best version of the ohai plugin to use with the jcampbell-vagrant environment. This may take a few seconds...
+No environment named jcampbell-vagrant was found. Finding the latest version of the ohai plugin instead. This may take a few second...
+using ohai (1.1.8)
+
+Environment 'jcampbell-vagrant' does not exist, would you like to create it? ["y", "n", "q"] ("y") y
+  [bootstrap] searching for environment
+  [bootstrap] Locking chef_environment:jcampbell-vagrant
+  [bootstrap] performing bootstrap on group(s): ["ohai::default"]
+  [bootstrap] Unlocking chef_environment:jcampbell-vagrant
+  [bootstrap] Success
+```
+
+That's it! motherbrain added our Vagrant box to Chef, set the run list, and ran `chef-client` on the box.

data/bin/boot

@@ -0,0 +1,9 @@
+#!/bin/bash
+
+mkdir -p /app/keys
+
+echo $MB_API_KEY | base64 -d > /app/keys/kallan.pem
+echo $MB_VALIDATOR_KEY | base64 -d > /app/keys/riot-validator.pem
+echo $MB_EDB_KEY | base64 -d > /app/keys/encrypted_data_bag_key
+
+exec bundle exec /app/bin/mbsrv -c /app/config.json

data/bin/mb

@@ -0,0 +1,5 @@
+#!/usr/bin/env ruby
+$:.push File.expand_path("../../lib", __FILE__)
+require 'motherbrain'
+
+MB::Cli::Runner.new(ARGV).execute!

data/bin/mbsrv

@@ -0,0 +1,5 @@
+#!/usr/bin/env ruby
+$:.push File.expand_path("../../lib", __FILE__)
+require 'motherbrain'
+
+MB::SrvCtl.run(ARGV, File.basename(__FILE__))

data/config.json

@@ -0,0 +1,32 @@
+{
+  "chef": {
+    "api_url": "https://chef.las1.riotgames.com/organizations/danger_zone",
+    "api_client": "kallan",
+    "api_key": "/app/keys/kallan.pem",
+    "validator_client": "riot-validator",
+    "validator_path": "/app/keys/riot-validator.pem",
+    "encrypted_data_bag_secret_path": "/app/keys/encrypted_data_bag_key"
+  },
+  "ssh": {
+    "user": "root",
+    "sudo": true,
+    "timeout": 15.0
+  },
+  "winrm": {
+    "user": "motherbrain",
+    "password": ""
+  },
+  "ssl": {
+    "verify": false
+  },
+  "log": {
+    "level": "DEBUG"
+  },
+  "plugin_manager": {
+    "eager_loading": false,
+    "async_loading": false
+  },
+  "rest_gateway": {
+    "enable": true
+  }
+}

data/features/cli/bootstrap_command/configurable_scripts.feature

@@ -0,0 +1,32 @@
+Feature: allow additional/configurable bootstrap scripts
+  As a user of the motherbrain (MB) command line interface (CLI)
+  I need a way to specify the bootstrap template to use
+  So I can control the way my nodes are created
+
+  Background:
+    Given a valid motherbrain configuration
+
+  Scenario: default template
+    Given a cookbook "awesomed" at version "1.2.3" with a plugin that can bootstrap
+    When I bootstrap "awesomed"
+    Then the exit status should be 0
+
+  Scenario: custom template
+    Given a cookbook "awesomed" at version "1.2.3" with a plugin that can bootstrap
+    And an extra bootstrap template
+    When I bootstrap "awesomed" with the "extra" bootstrap template
+    Then the exit status should be 0
+
+  Scenario: named template
+    Given a cookbook "awesomed" at version "1.2.3" with a plugin that can bootstrap
+    And an installed bootstrap template named "wibble"
+    When I bootstrap "awesomed" with the "wibble" bootstrap template
+    Then the exit status should be 0
+
+  Scenario: installing template from file
+    When I install a template named "foo" from "foo.erb"
+    Then the "foo" template should exist
+
+  Scenario: installing template from URL
+    When I install a template named "bar" from "http://gist.example.com/bar.gist"
+    Then the "bar" template should exist

data/features/cli/configure_command.feature

@@ -0,0 +1,57 @@
+Feature: configuring the motherbrain (MB) command line interface (CLI)
+  As a user of the motherbrain (MB) command line interface (CLI)
+  I need a way to configure my MB CLI based on answers I provide to a set of questions
+  So it is quick and easy for me to configure or reconfigure my MB CLI
+
+  @spawn
+  Scenario: generating a new config file
+    Given a motherbrain configuration does not exist
+    When I run the "configure" command interactively
+    And I type "https://api.opscode.com/organizations/vialstudio"
+    And I type "reset"
+    And I type "/Users/reset/.chef/reset.pem"
+    And I type "root"
+    And I type "secretpass"
+    Then the output should contain:
+      """
+      Config written to:
+      """
+    And the exit status should be 0
+    And a motherbrain config file should exist and contain:
+      | chef.api_url     | https://api.opscode.com/organizations/vialstudio |
+      | chef.api_client  | reset                                            |
+      | chef.api_key     | /Users/reset/.chef/reset.pem                     |
+      | ssh.user         | root                                             |
+      | ssh.password     | secretpass                                       |
+
+  @spawn
+  Scenario: attempting to generate a new config when one already exists
+    Given a valid motherbrain configuration
+    When I run the "configure" command interactively
+    Then the output should contain:
+      """
+      A configuration file already exists. Re-run with the --force flag if you wish to overwrite it.
+      """
+    And the exit status should be the code for error "ConfigExists"
+
+  @spawn
+  Scenario: forcefully generating a config when one already exists
+    Given a valid motherbrain configuration
+    When I run the "configure" command interactively with:
+      | --force |
+    And I type "https://api.opscode.com/organizations/vialstudio"
+    And I type "reset"
+    And I type "/Users/reset/.chef/reset.pem"
+    And I type "root"
+    And I type "secretpass"
+    Then the output should contain:
+      """
+      Config written to:
+      """
+    And the exit status should be 0
+    And a motherbrain config file should exist and contain:
+      | chef.api_url     | https://api.opscode.com/organizations/vialstudio |
+      | chef.api_client  | reset                                            |
+      | chef.api_key     | /Users/reset/.chef/reset.pem                     |
+      | ssh.user         | root                                             |
+      | ssh.password     | secretpass                                       |

data/features/cli/environment_command/create_command.feature

@@ -0,0 +1,22 @@
+Feature: Creating an environment
+  As a mb user
+  I can create an environment via motherbrain
+  So I can manage an environment without using other tools such as knife
+
+  @chef_server
+  Scenario: Create an environment
+    Given there is not an environment on the chef server named "test_env"
+    When I create an environment named "test_env"
+    Then the exit status should be 0
+    And there should be an environment "test_env" on the chef server
+
+  @chef_server
+  Scenario: Creating an existing environment
+    Given there is an environment on the chef server named "test_env"
+    When I create an environment named "test_env"
+    Then the output should contain:
+      """
+      An environment named 'test_env' already exists in the Chef Server.
+      """
+    And the exit status should be the code for error "EnvironmentExists"
+    And there should be an environment "test_env" on the chef server

data/features/cli/environment_command/destroy_command.feature

@@ -0,0 +1,33 @@
+Feature: Destroying an environment
+  As a mb user
+  I can destroy an environment via motherbrain
+  So I can manage an environment without using other tools such as knife
+
+  Background:
+    Given there is an environment on the chef server named "destroy_me"
+    And we have AWS credentials
+
+  @chef_server
+  Scenario: Destroying an environment
+    When I destroy the environment "destroy_me"
+    Then the exit status should be 0
+    And there should not be an environment "destroy_me" on the chef server
+
+  @chef_server
+  Scenario: Destroying a locked environment
+    Given the environment "destroy_me" is locked
+    When I destroy the environment "destroy_me"
+    Then the output should contain:
+      """
+      The environment "destroy_me" is locked. You may use --force to override this safeguard.
+      """
+    And the exit status should be the code for error "ResourceLocked"
+    And there should be an environment "destroy_me" on the chef server
+
+  @chef_server
+  Scenario: Destroying a locked environment with --force
+    Given the environment "destroy_me" is locked
+    When I destroy the environment "destroy_me" with flags:
+      | --force   |
+    Then the exit status should be 0
+    And there should not be an environment "destroy_me" on the chef server

data/features/cli/environment_command/from_command.feature

@@ -0,0 +1,29 @@
+Feature: Creating an environment from file
+  As a mb user
+  I can create an environment via motherbrain from a file
+  So I can manage an environment without using other tools such as knife
+
+  Background:
+    Given there is a file from input named "spec/fixtures/test_env.json"
+
+  @chef_server
+  Scenario: Create an environment from file
+    Given there is not an environment on the chef server named "test_env"
+    When I create an environment from file "spec/fixtures/test_env.json"
+    Then the exit status should be 0
+    And there should be an environment "test_env" on the chef server
+
+  @chef_server
+  Scenario: Creating an existing environment from file
+    Given there is an environment on the chef server named "test_env"
+    When I create an environment from file "spec/fixtures/test_env.json"
+    Then the output should contain:
+      """
+      An environment named 'test_env' already exists in the Chef Server.
+      """
+    And the exit status should be the code for error "EnvironmentExists"
+    And there should be an environment "test_env" on the chef server
+
+
+
+

data/features/cli/node_limiting.feature

@@ -0,0 +1,47 @@
+Feature: Limiting plugin commands to a subset of nodes
+  As an end-user of a motherbrain plugin
+  I want to be able to limit plugin commands to a subset of matching nodes
+  So I can selectively manage my infrastucture.
+
+   * Can specify one or more hostnames or IP addresses
+   * Can specify a range of IPs
+   * Maybe can specify a regex for hostname matches
+
+  Background:
+    Given a cookbook "foo" with a plugin command "bar" that affects 3 nodes
+
+  Scenario: limiting to a single node by full host + domain
+    When I run the "foo bar --only node1.example.com" command
+    Then the output should contain "Limiting to 1 node(s)"
+    And the exit status should be 0
+
+  Scenario: limiting to a single node by host only
+    When I run the "foo bar --only node1" command
+    Then the output should contain "Limiting to 1 node(s)"
+    And the exit status should be 0
+
+  Scenario: limiting to a single node by IP
+    When I run the "foo bar --only 192.168.1.1" command
+    Then the output should contain "Limiting to 1 node(s)"
+    And the exit status should be 0
+
+  Scenario: limiting to a set of nodes by full host + domain
+    When I run the "foo bar --only node1.example.com,node2.example.com" command
+    Then the output should contain "Limiting to 2 node(s)"
+    And the exit status should be 0
+
+  Scenario: limiting to a set of nodes by host only
+    When I run the "foo bar --only node1,node2" command
+    Then the output should contain "Limiting to 2 node(s)"
+    And the exit status should be 0
+
+  Scenario: limiting to a set of nodes by IP
+    When I run the "foo bar --only 192.168.1.1,192.168.1.2" command
+    Then the output should contain "Limiting to 2 node(s)"
+    And the exit status should be 0
+
+  Scenario: limiting to a set of nodes by IP range
+    When I run the "foo bar --only 192.168.1.1-2" command
+    Then the output should contain "Limiting to 2 node(s)"
+    And the exit status should be 0
+

data/features/cli/plugin_command/list_command.feature

@@ -0,0 +1,46 @@
+Feature: listing the plugins available to motherbrain
+  As a user of the motherbrain command line interface
+  I need a way to list all of the available plugins and versions
+  So I can see what plugins and versions of those plugins I have installed
+
+  Background:
+    Given a valid motherbrain configuration
+    And I have an empty Berkshelf
+    And the Chef Server is empty
+
+  Scenario: listing all plugins
+    Given a cookbook "pvpnet" at version "1.2.3" with a plugin
+    And a cookbook "pvpnet" at version "2.3.4" with a plugin
+    And a cookbook "league" at version "1.0.0" with a plugin
+    When I run the "plugin list" command
+    Then the output should contain:
+      """
+
+      ** listing installed plugins...
+
+      pvpnet: 1.2.3, 2.3.4
+      league: 1.0.0
+      """
+    And the exit status should be 0
+
+  Scenario: listing plugins when there are no plugins installed
+    When I run the "plugin list" command
+    Then the output should contain:
+      """
+      No plugins found in your Berkshelf:
+      """
+    And the exit status should be 0
+
+  Scenario: listing remote plugins
+    Given a cookbook on the Chef Server "ruby" at version "1.2.3" with a plugin
+    And a cookbook on the Chef Server "elixir" at version "2.0.0" with a plugin
+    When I run the "plugin list" command with:
+      | --remote |
+    Then the output should contain:
+      """
+      ** listing installed and remote plugins...
+
+      ruby: 1.2.3
+      elixir: 2.0.0
+      """
+    And the exit status should be 0