cucumber-chef 1.0.0 → 1.0.1

data/Gemfile

@@ -12,6 +12,8 @@ gem "cucumber-nagios", ">= 0"
 gem "rspec", ">= 0"
 gem "fog", ">= 0"
 gem "thor", ">= 0"
+gem "awesome_print", ">= 0"
+gem "net-scp", ">= 0"
 
 group :development do
   gem "bundler", "~> 1.0.0"

data/README.md

@@ -1,36 +1,44 @@
 Cucumber-chef is a library of tools to enable the emerging discipline of infrastructure as code to practice test driven development.  It provides a testing platform within which cucumber tests can be run which provision lightweight virtual machines, configure them by applying the appriporaite Chef roles to them, and then run acceptance and integration tests against the environment.
 
-## Installation 
+## Overview
 
-Cucumber-chef is distributed as a gem.  Until it's published on Rubygems, you'll need to build the gem yourself.  Check the project out, and then build and install the gem.
+Cucumber-chef begins with a very simple premise.  If we are framing our infratructure as code - if we're writing cookbooks, recipes and other pieces of automation in a high level programming language, such as Ruby, then it makes sense to follow the current wisdom across the software development world to maximise the quality, maintainability and reusability of our code, providing maximum chance that we'll deliver value with it.  One area which has been shown to have a very positive effect is the practive of 'test-driven' development.  In this paradigm, the developer begins by writing a test that captures the intended behaviour of the code  they are going to write.  This test will start out by failing.  The developer then writes code to make the test pass, and iterates thereafter.  
 
-First ensure you have bundler available, and then run:
+Cucumber-chef provides a framework to make it easier to do test-driven development for infrastructure.  It does this by providing a test infrastructure, in the cloud, which provides a very fast, lightweight and cheap way to fire up virtual machines for testing.  We call this the "test lab".
 
-    $ bundle install
+As you might have guessed from the name, we're going to write high level acceptance tests using Cucumber.  Cucumber-Chef provides step definitions and helper methods to make it easy to provision and manage machines with Chef, and then build end-to-end tests.
 
-Cucumber-chef uses Jeweler (see https://github.com/technicalpickles/jeweler) for managing gem builds , publishing and dependencies.  To build the gem simply run:
+## Getting started
 
-    $ rake build
+Getting started with Cucumber-Chef is a simple, three step process:
 
-This will result in the gem appearing in pkg/.  Install it:
+1) Install Cucumber-Chef
+2) Integrate with Hosted Chef and Amazon EC2
+3) Run cucumber-chef setup
 
-    $ gem install pkg/cucumber-chef-0.0.4.gem
+### Installing Cucumber-Chef
 
-## Overview
+Installing Cucumber-Chef is simple.  It's distributed as a RubyGem, so you can simply run:
 
-Cucumber-chef begins with a very simple premise.  If we are framing our infratructure as code - if we're writing cookbooks, recipes and other pieces of automation in a high level programming language, such as Ruby, then it makes sense to follow the current wisdom across the software development world to maximise the quality, maintainability and reusability of our code, providing maximum chance that we'll deliver value with it.  One area which has been shown to have a very positive effect is the practive of 'test-driven' development.  In this paradigm, the developer begins by writing a test that captures the intended behaviour of the code  they are going to write.  This test will start out by failing.  The developer then writes code to make the test pass, and iterates thereafter.  
-
-Cucumber-chef provides a framework to make it easier to do test-driven development for infrastructure.
+    $ gem install cucumber-chef
 
-### Vocabulary
+Once installed, you can run cucumber-chef on the command line to get an overview of the tasks it can carry out.
 
-Throughout this documentation, a few terms will crop up regularly.  It makes sense to define these up front, as they're just terms we've been using since we started writing cucumber-chef.  They may even change, but in the meantime, so we're all n the same page, here are some of the terms we use:
+    $ cucumber-chef 
+    Tasks:
+      cucumber-chef connect                 # Connect to a container in your test lab
+      cucumber-chef destroy                 # Destroy running test labs
+      cucumber-chef displayconfig           # Display the current config from knife.rb
+      cucumber-chef help [TASK]             # Describe available tasks or one specific task
+      cucumber-chef info                    # Display information about the current test lab
+      cucumber-chef project <project name>  # Create a project template for testing an infrastructure
+      cucumber-chef setup                   # Set up a cucumber-chef test lab in Amazon EC2
+      cucumber-chef test                    # Run a cucumber-chef test suite from a workstation.
+      cucumber-chef upload <project name>   # Upload a cucumber-chef test
 
-* Test Lab: An environment made up (at present) of an EC2 instance, configured to be an LXC host.  This machine does nothing other than provide space in which Linux containers can be created and destroyed.
-* Controller: One special Linux container which acts as the central point from which tests are run.  This machine is where the tests run, and has connectivity and credentials to connect to the machines that are created as part of a test run.
-* Container: A container is a lightweight virtual machine - it is entirely self-contained, with its own process tree, resource constraints, filesystem and network stack.  It shares a kernel with the Test Lab host server.
+### Integrate with Hosted Chef and Amazon EC2
 
-## Getting started
+In it's current incarnation, Cucumber-Chef makes two important assumptions.  Firstly, it assumes you're using Opscode Hosted Chef rather than your own Chef server.  Secondly, it assume that you are comfortable with using Amazon's EC2 service for providing the 'bare metal' on which we set up the test lab.  
 
 Cucumber-chef is tightly integrated with Chef - it uses your knife.rb for credentials, and any cucumber-chef-specific configuration goes in knife.rb under the cucumber-chef namespace.
 
@@ -40,28 +48,84 @@ On installation, the first thing you should do is run:
 
 This will look for your knife.rb, and extract the relevant sections, check them, and display them on the screen.  If any entries are missing, it will alert you.
 
-The current recommendation is to keep your knife.rb inside your organisation's chef repository, in .chef, and use environment variables to specify username, organisation name and cloud provider credentials.  Cucumber-chef supports and encourages this approach.  It will search for a directory called .chef in your current directory, and then carry on going up the directory tree until it finds one.  In practice this means that if you stay within the chef-repo directory for the organisation on which you're working, cucumber-chef will use the knife.rb; if your elsewhere in the filesystem rooted in your home directory, and have .chef in your home directory, cucumber-chef will use that.  Otherwise you'll need to either change into a directory where a .chef can be found, or copy, creatre or link accordingly.  In most cases we anticipate that you'll be inside the chef-repo of your organisation, and the documentation is written from this perspective.
+The recommended best practice for Chef is to keep your knife.rb inside your organisation's Chef repository, inside the .chef directory, and use environment variables to specify username, organisation name and cloud provider credentials.  Cucumber-chef supports and encourages this approach.  It will search for a directory called .chef in your current directory, and then carry on going up the directory tree until it finds one.  In practice this means that if you stay within the chef-repo directory for the organisation on which you're working, cucumber-chef will use the knife.rb; if your elsewhere in the filesystem rooted in your home directory, and have .chef in your home directory, cucumber-chef will use that.  Otherwise you'll need to either change into a directory where a .chef can be found, or copy, creatre or link accordingly.  In most cases we anticipate that you'll be inside the chef-repo of your organisation, and the documentation is written from this perspective.
 
-In its current incarnation, cucumber-chef makes two important assumptions.  Firstly, we assume you're using the Opscode platform rather than your own Chef server.  Secondly, we assume that you are comfortable with using Amazon's EC2 service for providing the 'bare metal' on which we set up the test lab.  Future releases may well allow you to use your own Chef server, and will definitely look at offering alternative cloud providers.  In the meantime, we welcome patches and pull requests!
+If you haven't already, refactor your knife.rb to look like this:
 
-Set your environment variables:
+    current_dir = File.dirname(__FILE__)
+    user = ENV['OPSCODE_USER'] || ENV['USER']
+    log_level :info
+    log_location STDOUT
+    node_name user
+    client_key "#{ENV['HOME']}/.chef/#{user}.pem"
+    validation_client_name "#{ENV['ORGNAME']}-validator"
+    validation_key "#{ENV['HOME']}/.chef/#{ENV['ORGNAME']}-validator.pem"
+    chef_server_url "https://api.opscode.com/organizations/#{ENV['ORGNAME']}"
+    cache_type 'BasicFile'
+    cache_options( :path => "#{ENV['HOME']}/.chef/checksums" )
+    cookbook_path ["#{current_dir}/../cookbooks"]
+
+Now set your Hosted Chef username and organization name using environment variables:
 
     $ export OPSCODE_USER=platform_user_name
     $ export ORGNAME=platform_organisation
+
+Now put your validator and client keys in $HOME/.chef.  Verify that everything still works:
+
+    $ knife client list
+
+If you get results back, we're in business.
+
+Now add the EC2 configuration:
+
+    knife[:aws_access_key_id] = ENV['AWS_ACCESS_KEY_ID']
+    knife[:aws_secret_access_key] = ENV['AWS_SECRET_ACCESS_KEY']
+    knife[:aws_ssh_key_id] = ENV['AWS_SSH_KEY_ID']
+    knife[:identity_file] = "/path/to/aws_ssh_key.pem"
+    knife[:availability_zone] = "eu-west-1a"
+    knife[:region] = "eu-west-1"
+    knife[:aws_image_id] = "ami-339ca947"
+
+Note that right now Cucumber-Chef only supports Ubuntu-based  test labs.
+
+And set your environment variables:
+
     $ export AWS_ACCESS_KEY_ID=SEKRITKEY
     $ export AWS_SECRET_ACCESS_KEY=REELYSEKRITKEY
+    $ export AWS_SSH_KEY_ID
+
+And then ensure your AWS ssh key is in place.
 
 Now check your config again, with cucumber-chef display config.  If you get no complaints, you're ready to set up a test lab.
 
+
+### Run cucumber-chef setup
+
+
     $ cucumber-chef setup
 
-This command will set up a complete test lab environment, including a controller.  As long as you've provided valid AWS and Opscode credentials, it will do this automatically.  The process takes about 12 minutes, after which you'll have a fully cuntioning platform available for you to use.
+This command will set up a complete test lab environment, As long as you've provided valid AWS and Opscode credentials, it will do this automatically.  The process takes about 15 minutes, after which you'll have a fully funtioning platform available for you to use.  Let's just quickly review what that means.  You will have an EC2 machine, fully managed by Chef, and providing the following:
+
+* The ability to provision LXC containers
+* The ability to run tests against LXC containers
+* A dedicated container for certain kinds of testing scenarios
 
 The next stage is to set up a project.  A project is simply a directory structure for containing your cucumber features and steps, already set up with an appropriate environment to make use of the step definitions provided with cucumber-chef.  We think it makes most sense to have this in your organisation's chef repo.  Cucumber-chef provides a task which will create a the directory for you, and populate it with a README and an example feature and step.
 
-    $ cucumber-chef project someproject
 
-**TO DO: fix this....**
+    $ cd /path/to/chef-repo
+    $ cucumber-chef project example
+
+This will create a directory, cucumber-chef, and a subdirectory, example.
+
+    └── example
+        ├── README
+        └── features
+            ├── example.feature
+            ├── step_definitions
+            │   └── example_step.rb
+            └── support
+                └── env.rb
 
 ## Writing tests
 
@@ -78,6 +142,12 @@ You can write the tests and Chef code wherever you like.  We're assuming you pre
 
     $ cucumber-chef test myproject
 
-At the moment cucumber-chef doesn't pass though clever filtering and tagging options that cucumber supports - you run all te tests.  We're going to improve that soon, again, patches and pull requests very welcome.
+At the moment cucumber-chef doesn't pass though clever filtering and tagging options that cucumber supports - you run all the tests.  We're going to improve that soon, again, patches and pull requests very welcome.
+
+Running the test task will upload your current project to the test lab, and run the tests, reporting the results back to the screen.  Cucumber-chef also provides an upload task, so you can push the current project to the test lab, and then connect to test lab yourself to run tests in a more granular way.  To do this, you need to know the IP of the test lab.  You can find this out by running:
+
+    $ cucumber-chef info 
+
+At present, Cucumber-Chef only allows one test lab per AWS account and Opscode Hosted Chef account.
+
 
-Running the test task will upload your current project to the controller, and run the tests.

data/VERSION

@@ -1 +1 @@
-1.0.0
+1.0.1

data/cucumber-chef.gemspec

@@ -5,11 +5,11 @@
 
 Gem::Specification.new do |s|
   s.name = %q{cucumber-chef}
-  s.version = "1.0.0"
+  s.version = "1.0.1"
 
   s.required_rubygems_version = Gem::Requirement.new(">= 0") if s.respond_to? :required_rubygems_version=
   s.authors = ["Stephen Nelson-Smith"]
-  s.date = %q{2011-06-14}
+  s.date = %q{2011-06-21}
   s.default_executable = %q{cucumber-chef}
   s.description = %q{Framework for behaviour-drive infrastructure development.}
   s.email = %q{stephen@atalanta-systems.com}
@@ -94,6 +94,8 @@ Gem::Specification.new do |s|
       s.add_runtime_dependency(%q<rspec>, [">= 0"])
       s.add_runtime_dependency(%q<fog>, [">= 0"])
       s.add_runtime_dependency(%q<thor>, [">= 0"])
+      s.add_runtime_dependency(%q<awesome_print>, [">= 0"])
+      s.add_runtime_dependency(%q<net-scp>, [">= 0"])
       s.add_development_dependency(%q<bundler>, ["~> 1.0.0"])
       s.add_development_dependency(%q<jeweler>, ["~> 1.6.2"])
       s.add_development_dependency(%q<rcov>, [">= 0"])
@@ -104,6 +106,8 @@ Gem::Specification.new do |s|
       s.add_dependency(%q<rspec>, [">= 0"])
       s.add_dependency(%q<fog>, [">= 0"])
       s.add_dependency(%q<thor>, [">= 0"])
+      s.add_dependency(%q<awesome_print>, [">= 0"])
+      s.add_dependency(%q<net-scp>, [">= 0"])
       s.add_dependency(%q<bundler>, ["~> 1.0.0"])
       s.add_dependency(%q<jeweler>, ["~> 1.6.2"])
       s.add_dependency(%q<rcov>, [">= 0"])
@@ -115,6 +119,8 @@ Gem::Specification.new do |s|
     s.add_dependency(%q<rspec>, [">= 0"])
     s.add_dependency(%q<fog>, [">= 0"])
     s.add_dependency(%q<thor>, [">= 0"])
+    s.add_dependency(%q<awesome_print>, [">= 0"])
+    s.add_dependency(%q<net-scp>, [">= 0"])
     s.add_dependency(%q<bundler>, ["~> 1.0.0"])
     s.add_dependency(%q<jeweler>, ["~> 1.6.2"])
     s.add_dependency(%q<rcov>, [">= 0"])

data/lib/cucumber/chef/config.rb

@@ -40,7 +40,7 @@ module Cucumber
         @config
       end
 
-      def test_config
+      def self.test_config
         config = self.new
         config[:mode] = "test"
         config

data/lib/cucumber/chef/test_lab.rb

@@ -17,7 +17,7 @@ module Cucumber
           raise TestLabError.new("A test lab already exists using the AWS credentials you supplied")
         end
         server_definition = {
-          :image_id => "ami-339ca947",
+          :image_id => @config[:knife][:aws_image_id],
           :groups => "default",
           :flavor_id => "m1.small",
           :key_name => @config[:knife][:aws_ssh_key_id],

metadata

@@ -2,7 +2,7 @@
 name: cucumber-chef
 version: !ruby/object:Gem::Version 
   prerelease: 
-  version: 1.0.0
+  version: 1.0.1
 platform: ruby
 authors: 
 - Stephen Nelson-Smith
@@ -10,7 +10,7 @@ autorequire:
 bindir: bin
 cert_chain: []
 
-date: 2011-06-14 00:00:00 +01:00
+date: 2011-06-21 00:00:00 +01:00
 default_executable: cucumber-chef
 dependencies: 
 - !ruby/object:Gem::Dependency 
@@ -80,8 +80,30 @@ dependencies:
   prerelease: false
   version_requirements: *id006
 - !ruby/object:Gem::Dependency 
-  name: bundler
+  name: awesome_print
   requirement: &id007 !ruby/object:Gem::Requirement 
+    none: false
+    requirements: 
+    - - ">="
+      - !ruby/object:Gem::Version 
+        version: "0"
+  type: :runtime
+  prerelease: false
+  version_requirements: *id007
+- !ruby/object:Gem::Dependency 
+  name: net-scp
+  requirement: &id008 !ruby/object:Gem::Requirement 
+    none: false
+    requirements: 
+    - - ">="
+      - !ruby/object:Gem::Version 
+        version: "0"
+  type: :runtime
+  prerelease: false
+  version_requirements: *id008
+- !ruby/object:Gem::Dependency 
+  name: bundler
+  requirement: &id009 !ruby/object:Gem::Requirement 
     none: false
     requirements: 
     - - ~>
@@ -89,10 +111,10 @@ dependencies:
         version: 1.0.0
   type: :development
   prerelease: false
-  version_requirements: *id007
+  version_requirements: *id009
 - !ruby/object:Gem::Dependency 
   name: jeweler
-  requirement: &id008 !ruby/object:Gem::Requirement 
+  requirement: &id010 !ruby/object:Gem::Requirement 
     none: false
     requirements: 
     - - ~>
@@ -100,10 +122,10 @@ dependencies:
         version: 1.6.2
   type: :development
   prerelease: false
-  version_requirements: *id008
+  version_requirements: *id010
 - !ruby/object:Gem::Dependency 
   name: rcov
-  requirement: &id009 !ruby/object:Gem::Requirement 
+  requirement: &id011 !ruby/object:Gem::Requirement 
     none: false
     requirements: 
     - - ">="
@@ -111,7 +133,7 @@ dependencies:
         version: "0"
   type: :development
   prerelease: false
-  version_requirements: *id009
+  version_requirements: *id011
 description: Framework for behaviour-drive infrastructure development.
 email: stephen@atalanta-systems.com
 executables: 
@@ -194,7 +216,7 @@ required_ruby_version: !ruby/object:Gem::Requirement
   requirements: 
   - - ">="
     - !ruby/object:Gem::Version 
-      hash: 1974008823645017826
+      hash: 1485817935090543312
       segments: 
       - 0
       version: "0"