testlab 0.6.5 → 0.6.6

Sign up to get free protection for your applications and to get access to all the features.
Files changed (44) hide show
  1. data/README.md +35 -32
  2. data/bin/tl +13 -640
  3. data/lib/commands/container.rb +292 -0
  4. data/lib/commands/network.rb +233 -0
  5. data/lib/commands/node.rb +182 -0
  6. data/lib/commands/testlab.rb +98 -0
  7. data/lib/testlab/container/actions.rb +15 -5
  8. data/lib/testlab/container/io.rb +69 -0
  9. data/lib/testlab/container/lifecycle.rb +6 -10
  10. data/lib/testlab/container/status.rb +1 -1
  11. data/lib/testlab/container.rb +2 -0
  12. data/lib/testlab/network/actions.rb +16 -0
  13. data/lib/testlab/network/lifecycle.rb +14 -20
  14. data/lib/testlab/network/status.rb +11 -5
  15. data/lib/testlab/network.rb +6 -6
  16. data/lib/testlab/node/actions.rb +16 -0
  17. data/lib/testlab/node/lifecycle.rb +15 -11
  18. data/lib/testlab/node/status.rb +1 -2
  19. data/lib/testlab/node.rb +1 -1
  20. data/lib/testlab/provisioner.rb +2 -1
  21. data/lib/testlab/provisioners/apt.rb +1 -1
  22. data/lib/testlab/provisioners/apt_cacher_ng.rb +2 -2
  23. data/lib/testlab/provisioners/bind.rb +1 -1
  24. data/lib/testlab/provisioners/chef_gem.rb +2 -2
  25. data/lib/testlab/provisioners/omnibus.rb +2 -2
  26. data/lib/testlab/provisioners/omnitruck.rb +2 -2
  27. data/lib/testlab/provisioners/raring.rb +1 -1
  28. data/lib/testlab/provisioners/resolv.rb +2 -2
  29. data/lib/testlab/provisioners/route.rb +51 -0
  30. data/lib/testlab/provisioners/shell.rb +1 -1
  31. data/lib/testlab/provisioners/templates/apt/bootstrap.erb +6 -1
  32. data/lib/testlab/provisioners/templates/apt_cacher_ng/bootstrap.erb +4 -1
  33. data/lib/testlab/provisioners/templates/raring/bootstrap.erb +9 -4
  34. data/lib/testlab/utility/logger.rb +87 -0
  35. data/lib/testlab/utility.rb +4 -2
  36. data/lib/testlab/version.rb +1 -1
  37. data/lib/testlab.rb +28 -0
  38. data/spec/container_spec.rb +18 -12
  39. data/spec/network_spec.rb +4 -0
  40. data/spec/node_spec.rb +6 -19
  41. data/spec/provisioners/shell_spec.rb +2 -2
  42. data/spec/support/Labfile +3 -3
  43. data/testlab.gemspec +2 -2
  44. metadata +13 -6
data/README.md CHANGED
@@ -6,36 +6,12 @@
6
6
 
7
7
  # TestLab
8
8
 
9
+ A toolkit for building virtual computer labs.
10
+
9
11
  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`.
10
12
 
11
13
  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.
12
14
 
13
- # Using TestLab Programmatically
14
-
15
- 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:
16
-
17
- log_file = File.join(Dir.pwd, "testlab.log")
18
- @logger = ZTK::Logger.new(log_file)
19
- @ui = ZTK::UI.new(:logger => @logger)
20
- @testlab = TestLab.new(:ui => @ui)
21
-
22
- 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`.
23
-
24
- There are several easy accessors available to grab the first container and execure the command `uptime` on it via and SSH connection:
25
-
26
- container = @testlab.containers.first
27
- container.ssh.exec(%(uptime))
28
-
29
- We can also execute this command via `lxc-attach`:
30
-
31
- container.lxc.attach(%(-- uptime))
32
-
33
- You can access all the nodes for example:
34
-
35
- @testlab.nodes
36
-
37
- For more information see the TestLab Documentation, `testlab-repo`, command-line binary and it never hurts to look at the TestLab source itself.
38
-
39
15
  # Using TestLab Interactively
40
16
 
41
17
  The TestLab command-line program `tl` follows in the style of git (using the GLI RubyGem).
@@ -48,7 +24,7 @@ The TestLab command-line program `tl` follows in the style of git (using the GLI
48
24
  tl [global options] command [command options] [arguments...]
49
25
 
50
26
  VERSION
51
- 0.6.1
27
+ 0.6.5
52
28
 
53
29
  GLOBAL OPTIONS
54
30
  --version -
@@ -62,6 +38,7 @@ The TestLab command-line program `tl` follows in the style of git (using the GLI
62
38
  down - Offline the test lab
63
39
  setup - Setup the test lab infrastructure
64
40
  teardown - Teardown the test lab infrastructure
41
+ build - Build the test lab infrastructure
65
42
  status - Display information on the status of the test lab
66
43
  node - Manage nodes
67
44
  network - Manage networks
@@ -69,7 +46,7 @@ The TestLab command-line program `tl` follows in the style of git (using the GLI
69
46
 
70
47
  You stand up your lab with the following command:
71
48
 
72
- tl setup
49
+ tl build
73
50
 
74
51
  You can down the entire lab:
75
52
 
@@ -79,7 +56,7 @@ You can also destroy it (only works for VM backed providers; this would be a NO-
79
56
 
80
57
  tl destroy
81
58
 
82
- # Interacting with Containers
59
+ ## Interacting with Containers
83
60
 
84
61
  Most commands dealing will containers will take this argument:
85
62
 
@@ -114,7 +91,7 @@ You can recycle a container, effectively destroying then creating it again, prov
114
91
 
115
92
  tl container recycle -n server-www-1
116
93
 
117
- # Ephemeral Container Cloning
94
+ ## Ephemeral Container Cloning
118
95
 
119
96
  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.
120
97
 
@@ -157,7 +134,7 @@ We can even recycle it while it is in a cloned state:
157
134
 
158
135
  $ tl container recycle -n server-www-1
159
136
 
160
- # Network Routes
137
+ ## Network Routes
161
138
 
162
139
  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`.
163
140
 
@@ -183,7 +160,7 @@ These routes can be manually manipulated as well:
183
160
  del - Delete routes to lab networks
184
161
  show - Show routes to lab networks
185
162
 
186
- # Getting Help
163
+ ## Getting Help
187
164
 
188
165
  TestLab uses the GLI RubyGem, which gives us a command line pattern similar to that of Git. Therefore help is easy to get:
189
166
 
@@ -192,6 +169,32 @@ TestLab uses the GLI RubyGem, which gives us a command line pattern similar to t
192
169
  tl help container
193
170
  tl help network
194
171
 
172
+ # Using TestLab Programmatically
173
+
174
+ 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:
175
+
176
+ log_file = File.join(Dir.pwd, "testlab.log")
177
+ @logger = ZTK::Logger.new(log_file)
178
+ @ui = ZTK::UI.new(:logger => @logger)
179
+ @testlab = TestLab.new(:ui => @ui)
180
+
181
+ 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`.
182
+
183
+ There are several easy accessors available to grab the first container and execure the command `uptime` on it via and SSH connection:
184
+
185
+ container = @testlab.containers.first
186
+ container.ssh.exec(%(uptime))
187
+
188
+ We can also execute this command via `lxc-attach`:
189
+
190
+ container.lxc.attach(%(-- uptime))
191
+
192
+ You can access all the nodes for example:
193
+
194
+ @testlab.nodes
195
+
196
+ For more information see the TestLab Documentation, `testlab-repo`, command-line binary and it never hurts to look at the TestLab source itself.
197
+
195
198
  # REQUIREMENTS
196
199
 
197
200
  * Latest VirtualBox Package