testlab 0.6.11 → 0.6.12

data/README.md

@@ -8,13 +8,15 @@
 
 A toolkit for building virtual computer labs.
 
-What is TestLab?  TestLab lets you iterate virtual infrastructure quickly.  Using a `Labfile` you can define how you want your virtual infrastructure laid out.  You can define multiple network segments and containers (i.e. boxen).  TestLab will then setup and teardown this virtual infrastructure as you have dictated in the `Labfile`.
+What is TestLab?  TestLab lets you iterate virtual infrastructure quickly.  Using a `Labfile` you can define how you want your virtual infrastructure laid out.  You can define multiple network segments and containers (i.e. boxen).  TestLab will then setup and tear down this virtual infrastructure as you have dictated in the `Labfile`.
 
-TestLab can be run directly on the command-line or can be interfaced with directly via code.  Unlike the trend with some popular open-source software recently, I want you to build off this API interface and hopefully create tools I would of never dreamed up.
+TestLab can also import and export containers, making it easy to share them.  TestLab supports the latest LXC versions, allowing for ephemeral cloning operations, furthering your ability to iterate quickly.  TestLab can be used for many other applications, including infrastructure unit and integration testing, allowing for vastly more complex configurations and more effective resource sharing than traditional VM solutions.
+
+TestLab can be run via the command-line or can be interfaced with directly via Ruby code.
 
 # Using TestLab Interactively
 
-The TestLab command-line program `tl` follows in the style of git (using the GLI RubyGem).
+The TestLab command-line program `tl` follows in the style of git:
 
     $ tl help
     NAME
@@ -50,7 +52,7 @@ You stand up your lab with the following command:
 
     tl build
 
-You can down the entire lab:
+You can down the entire lab (this would only down the containers on the Local provider for example):
 
     tl down
 
@@ -58,18 +60,33 @@ You can also destroy it (only works for VM backed providers; this would be a NO-
 
     tl destroy
 
+## Getting Help
+
+TestLab uses the GLI RubyGem, which gives us a command line pattern similar to that of Git.  Therefore help is easy to get:
+
+    tl help
+    tl help node
+    tl help container
+    tl help network
+
 ## Interacting with Containers
 
-Most commands dealing will containers will take this argument:
+Almost all commands dealing will containers will take this argument:
 
     COMMAND OPTIONS
         -n, --name=container - Container ID or Name (default: none)
 
 You can interact with containers via SSH:
 
-    tl container ssh -n <container ID>
+    tl container ssh -n <name>
+
+For example:
+
+    tl container ssh -n server-www-1
+
+Would connect to the container defined as 'server-www-1' in our Labfile.
 
-You can pass an optional alternate username and/or identity to use.  By default TestLab will attempt to SSH as the user defined in the `Labfile` for that container, otherwise the default user for the containers distro is used.
+You can pass an optional username and/or identity to use.  By default TestLab will attempt to SSH as the user defined in the `Labfile` for that container, otherwise the default user for the containers distro is used.
 
     $ tl help container ssh
     NAME
@@ -95,7 +112,7 @@ You can recycle a container, effectively destroying then creating it again, prov
 
 ## Ephemeral Container Cloning
 
-As it stands attempting to iterate infrastructure while developing with Vagrant is a slow and painful process.  Enter LXC and it's ephemeral feature.  The idea here is you have a container that is provisioned to a "pristine" state acording to the `Labfile`.  You then clone this container and run actions against the container.  After running your actions against the container you want to maybe tweak your Chef cookbook and re-run it against the container.  As we all know running an ever changing cookbook in development against the same system over and over again causes drift and problems.  With the cloning you can instantly reinstate the container as it was when you first cloned it.
+As it stands attempting to iterate infrastructure with Vagrant is a slow and painful process.  Enter LXC and ephemeral cloning.  The idea here is that you have a container that is provisioned to a "pristine" state according to the `Labfile`.  You then clone this container and run actions against the container.  After running your actions against the container you want to maybe tweak your Chef cookbook, for example, and re-run it against the container.  Running an ever changing cookbook in development against the same system over and over again causes drift and problems.  With the cloning you can instantly reinstate the container as it was when you first cloned it.
 
 Here we are cloning the container for the first time.  It takes a bit longer than normal because TestLab is actually shutting down the container so it can be retained as the "pristine" copy of it, and starting up a ephemeral container in its place.  Subsequent calls to clone are very fast.
 
@@ -112,6 +129,8 @@ Here we are cloning the container for the first time.  It takes a bit longer tha
     [TL] TestLab v0.6.1 Loaded
     [TL] container server-www-1 clone                            # Completed in 1.0281 seconds!
 
+The idea in the above example is that you run the initial clone command to put your container into an ephemeral clone state.  You would then modify the container in some fashion, test, etc.  When you where done with that iteration you would run the clone command again, losing all the changes you did to the container, replacing it with a new clean cloned copy of your original container.  RRP (Rinse, Repeat, Profit)
+
 We can also see the containers status reflects that it is a clone currently:
 
     $ tl container status -n server-www-1
@@ -128,7 +147,7 @@ We can also see the containers status reflects that it is a clone currently:
     |  PROVISIONERS: Resolv/AptCacherNG/Apt/Shell  |
     +----------------------------------------------+
 
-We can easily revert it back to a full container if we want to make changes to it:
+We can easily revert it back to a full container if we want to make "permanent" changes to it:
 
     $ tl container up -n server-www-1
 
@@ -136,9 +155,13 @@ We can even recycle it while it is in a cloned state:
 
     $ tl container recycle -n server-www-1
 
+We can run setup against a clone as well (note: running `build`, calls `up`, which would revert us back to a non-cloned container and we would not want this to happen):
+
+    $ tl container setup -n server-www-1
+
 ## Network Routes
 
-TestLab will add network routes for any networks defined in the `Labfile` with the route flag set to true.  This will allow you to directly interact with containers.  Here is an example of the routes added with the multi-network `Labfile`.
+TestLab will add network routes for any networks defined in the `Labfile` witch have the `TestLab::Provisioner::Route` provisioner class specified for them.  This will allow you to directly interact with containers over the network.  Here is an example of the routes added with the multi-network `Labfile`.
 
     $ tl network route show -n labnet
     [TL] TestLab v0.6.1 Loaded
@@ -146,7 +169,7 @@ TestLab will add network routes for any networks defined in the `Labfile` with t
     10.10.0.0       192.168.33.239  255.255.0.0     UG        0 0          0 vboxnet0
     10.11.0.0       192.168.33.239  255.255.0.0     UG        0 0          0 vboxnet0
 
-These routes can be manually manipulated as well:
+These routes can be manually manipulated as well (regardless of if you have specified the `TestLab::Provisioner::Route` provisioner class for the networks via the `Labfile`):
 
     $ tl help network route
     NAME
@@ -162,15 +185,6 @@ These routes can be manually manipulated as well:
         del  - Delete routes to lab networks
         show - Show routes to lab networks
 
-## Getting Help
-
-TestLab uses the GLI RubyGem, which gives us a command line pattern similar to that of Git.  Therefore help is easy to get:
-
-    tl help
-    tl help node
-    tl help container
-    tl help network
-
 # Using TestLab Programmatically
 
 Accessing TestLab via code is meant to be fairly easy and straightforward.  To get an instance of TestLab you only need about four lines of code:
@@ -180,9 +194,9 @@ Accessing TestLab via code is meant to be fairly easy and straightforward.  To g
     @ui = ZTK::UI.new(:logger => @logger)
     @testlab = TestLab.new(:ui => @ui)
 
-Calling `TestLab.new` without a `:labfile` option will, by default, attempt to read `Labfile` from the current directory.  This behaviour can be changed by passing the `:labfile` key with a path to your desired "Labfile" as the value to your `TestLab.new`.
+Calling `TestLab.new` without a `:labfile` option will, by default, attempt to read `Labfile` from the current directory.  This behavior can be changed by passing the `:labfile` key with a path to your desired "Labfile" as the value to your `TestLab.new`.
 
-There are several easy accessors available to grab the first container and execure the command `uptime` on it via and SSH connection:
+There are several easy accessors available to grab the first container and execute the command `uptime` on it via and SSH connection:
 
     container = @testlab.containers.first
     container.ssh.exec(%(uptime))

data/lib/testlab/container/lifecycle.rb

@@ -15,7 +15,7 @@ class TestLab
 
         please_wait(:ui => @ui, :message => format_object_action(self, 'Setup', :green)) do
 
-          self.provisioners.each do |provisioner|
+          self.container_provisioners.each do |provisioner|
             @ui.logger.info { ">>>>> CONTAINER PROVISIONER SETUP: #{provisioner} <<<<<" }
             p = provisioner.new(self.config, @ui)
             p.respond_to?(:on_container_setup) and p.on_container_setup(self)
@@ -40,7 +40,7 @@ class TestLab
 
         please_wait(:ui => @ui, :message => format_object_action(self, 'Teardown', :red)) do
 
-          self.provisioners.each do |provisioner|
+          self.container_provisioners.each do |provisioner|
             @ui.logger.info { ">>>>> CONTAINER PROVISIONER TEARDOWN: #{provisioner} <<<<<" }
             p = provisioner.new(self.config, @ui)
             p.respond_to?(:on_container_teardown) and p.on_container_teardown(self)
@@ -60,6 +60,11 @@ class TestLab
         true
       end
 
+      # Returns all defined provisioners for this container's networks and the container iteself.
+      def container_provisioners
+        [self.interfaces.map(&:network).map(&:provisioners), self.provisioners].flatten.compact.uniq
+      end
+
     end
 
   end

data/lib/testlab/network/lifecycle.rb

@@ -9,7 +9,7 @@ class TestLab
 
         please_wait(:ui => @ui, :message => format_object_action(self, 'Setup', :green)) do
 
-          self.provisioners.each do |provisioner|
+          self.network_provisioners.each do |provisioner|
             @ui.logger.info { ">>>>> NETWORK PROVISIONER SETUP: #{provisioner} <<<<<" }
             p = provisioner.new(self.config, @ui)
             p.respond_to?(:on_network_setup) and p.on_network_setup(self)
@@ -26,7 +26,7 @@ class TestLab
 
         please_wait(:ui => @ui, :message => format_object_action(self, 'Teardown', :red)) do
 
-          self.provisioners.each do |provisioner|
+          self.network_provisioners.each do |provisioner|
             @ui.logger.info { ">>>>> NETWORK PROVISIONER TEARDOWN: #{provisioner} <<<<<" }
             p = provisioner.new(self.config, @ui)
             p.respond_to?(:on_network_teardown) and p.on_network_teardown(self)
@@ -46,6 +46,11 @@ class TestLab
         true
       end
 
+      # Returns all defined provisioners for this network's containers and the network iteself.
+      def network_provisioners
+        [self.provisioners, self.interfaces.map(&:container).map(&:provisioners)].flatten.compact.uniq
+      end
+
     end
 
   end

data/lib/testlab/node/lifecycle.rb

@@ -15,7 +15,7 @@ class TestLab
 
         please_wait(:ui => @ui, :message => format_object_action(self, 'Setup', :green)) do
 
-          global_provisioners.each do |provisioner|
+          self.all_provisioners.each do |provisioner|
             @ui.logger.info { ">>>>> NODE PROVISIONER SETUP: #{provisioner} <<<<<" }
             p = provisioner.new(self.config, @ui)
             p.respond_to?(:on_node_setup) and p.on_node_setup(self)
@@ -34,7 +34,7 @@ class TestLab
 
         please_wait(:ui => @ui, :message => format_object_action(self, 'Teardown', :red)) do
 
-          global_provisioners.each do |provisioner|
+          self.all_provisioners.each do |provisioner|
             @ui.logger.info { ">>>>> NODE PROVISIONER TEARDOWN: #{provisioner} <<<<<" }
             p = provisioner.new(self.config, @ui)
             p.respond_to?(:on_node_teardown) and p.on_node_teardown(self)
@@ -54,11 +54,11 @@ class TestLab
         true
       end
 
-      def global_provisioners
-        [self.provisioners, self.containers.map(&:provisioners)].flatten.compact.uniq
+      # Returns all defined provisioners for this node and it's networks and containers.
+      def all_provisioners
+        [self.provisioners, self.networks.map(&:provisioners), self.containers.map(&:provisioners)].flatten.compact.uniq
       end
 
     end
-
   end
 end

data/lib/testlab/version.rb

@@ -1,6 +1,6 @@
 class TestLab
   unless const_defined?(:VERSION)
     # TestLab Gem Version
-    VERSION = "0.6.11"
+    VERSION = "0.6.12"
   end
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: testlab
 version: !ruby/object:Gem::Version
-  version: 0.6.11
+  version: 0.6.12
   prerelease: 
 platform: ruby
 authors:
@@ -9,7 +9,7 @@ authors:
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2013-06-19 00:00:00.000000000 Z
+date: 2013-06-22 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: gli
@@ -300,7 +300,7 @@ required_ruby_version: !ruby/object:Gem::Requirement
       version: '0'
       segments:
       - 0
-      hash: -168179665040294334
+      hash: -3900495778607553131
 required_rubygems_version: !ruby/object:Gem::Requirement
   none: false
   requirements:
@@ -309,7 +309,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
       version: '0'
       segments:
       - 0
-      hash: -168179665040294334
+      hash: -3900495778607553131
 requirements: []
 rubyforge_project: 
 rubygems_version: 1.8.25