Remove references to slave

Instead of calling things slaves, either rename them to "nodes" or "followers",
depending on the context
This commit is contained in:
Clint Shryock 2014-05-29 09:12:23 -05:00
parent 188b26719c
commit 7f7a107a3e
2 changed files with 14 additions and 14 deletions

View File

@ -99,9 +99,9 @@ web and DB machine. You could also optionally be specific and say
Additionally, you can specify a regular expression for matching only Additionally, you can specify a regular expression for matching only
certain machines. This is useful in some cases where you specify many similar certain machines. This is useful in some cases where you specify many similar
machines, for example if you're testing a distributed service you may have machines, for example if you're testing a distributed service you may have
a `master` machine as well as a `slave0`, `slave1`, `slave2`, etc. If you a `leader` machine as well as a `follower0`, `follower1`, `follower2`, etc. If you
want to bring up all the slaves but not the master, you can just do want to bring up all the followers but not the leader, you can just do
`vagrant up /slave[0-9]/`. If Vagrant sees a machine name within forward `vagrant up /follower[0-9]/`. If Vagrant sees a machine name within forward
slashes, it assumes you're using a regular expression. slashes, it assumes you're using a regular expression.
## Communication Between Machines ## Communication Between Machines
@ -135,10 +135,10 @@ Vagrant to _not_ start specific machines. Example:
```ruby ```ruby
config.vm.define "web" config.vm.define "web"
config.vm.define "db" config.vm.define "db"
config.vm.define "db_slave", autostart: false config.vm.define "db_follower", autostart: false
``` ```
When running `vagrant up` with the settings above, Vagrant will automatically When running `vagrant up` with the settings above, Vagrant will automatically
start the "web" and "db" machines, but will not start the "db\_slave" machine. start the "web" and "db" machines, but will not start the "db\_follower" machine.
You can manually force the "db\_slave" machine to start by running You can manually force the "db\_follower" machine to start by running
`vagrant up db_slave`. `vagrant up db_follower`.

View File

@ -19,9 +19,9 @@ you wanted to create three machines:
<pre class="prettyprint"> <pre class="prettyprint">
(1..3).each do |i| (1..3).each do |i|
config.vm.define "slave-#{i}" do |slave| config.vm.define "node-#{i}" do |node|
slave.vm.provision "shell", node.vm.provision "shell",
inline: "echo hello from slave #{i}" inline: "echo hello from node #{i}"
end end
end end
</pre> </pre>
@ -34,16 +34,16 @@ the value of a variable used within the configs. For example, the loop below
<pre class="prettyprint"> <pre class="prettyprint">
# THIS DOES NOT WORK! # THIS DOES NOT WORK!
for i in 1..3 do for i in 1..3 do
config.vm.define "slave-#{i}" do |slave| config.vm.define "node-#{i}" do |node|
slave.vm.provision "shell", node.vm.provision "shell",
inline: "echo hello from slave #{i}" inline: "echo hello from node #{i}"
end end
end end
</pre> </pre>
The "for i in ..." construct in Ruby actually modifies the value of `i` The "for i in ..." construct in Ruby actually modifies the value of `i`
for each iteration, rather than making a copy. Therefore, when you run this, for each iteration, rather than making a copy. Therefore, when you run this,
every slave will actually provision with the same text. every node will actually provision with the same text.
This is an easy mistake to make, and Vagrant can't really protect against it, This is an easy mistake to make, and Vagrant can't really protect against it,
so the best we can do is mention it here. so the best we can do is mention it here.