Merge pull request #189 from omahs/patch-1

Fix typos

docs/developer_manual/00-creating-a-new-layer.md

@@ -1,6 +1,6 @@
 # Creating a new layer
 
-The different functionality of the emulator is separated into different layers. `Base` layer, for example, describes the base of the emulation: what autonomous systems (AS) and internet exchanges (IX) are in the emulator, what nodes and networks are in each of the AS, and how nodes are connected with networks. `Bgp` layer, on the other hands, describes how ASes and where are peered with each other, and what's the relation between the peers.
+The different functionality of the emulator is separated into different layers. `Base` layer, for example, describes the base of the emulation: what autonomous systems (AS) and internet exchanges (IX) are in the emulator, what nodes and networks are in each of the AS, and how nodes are connected with networks. `Bgp` layer, on the other hand, describes how ASes and where are peered with each other, and what's the relation between the peers.
 
 To add new functionality into the emulator that works with the entire emulation as a whole, you can create a new layer. Note that if you are creating something that only works with a single node, like a service (like a webapp), you should create a service instead.
 
@@ -20,21 +20,21 @@ This guide is going to cover the following topics:
 
 Render and configuration are two separate steps in the emulator.
 
-Layers will have no knowledge of what or how other layers are configured prior to the render stage. Layers must keep track of the changes they try to make internally within the class. The process of actually makeing changes, like adding nodes, networks, peering configurations, or other fancy stuff like DNS, web server, etc., into the emulation is called rendering.
+Layers will have no knowledge of what or how other layers are configured prior to the render stage. Layers must keep track of the changes they try to make internally within the class. The process of actually making changes, like adding nodes, networks, peering configurations, or other fancy stuff like DNS, web server, etc., into the emulation is called rendering.
 
-During the render stage, the `render` method of each layer will be called in order of their dependencies, and a `Emulator` object will be passed in. The `Emulator` object allows the different layers to collaboratively build a single emulation. 
+During the render stage, the `render` method of each layer will be called in order of their dependencies, and an `Emulator` object will be passed in. The `Emulator` object allows the different layers to collaboratively build a single emulation. 
 
 Configuration is an optional step. In the configure stage, layers will be provided with access to the emulator object. The configure stage allows the layer developer to have more control over the emulation construction.
 
-In the configure stage, layers should register the data that other layers might need. For example, in the `Base` layer, we register the nodes, networks, etc., and resolv all pending networks joins. Layers, however, should not make irreversible changes, as there are chances that other layers will add new data to the emulator.
+In the configure stage, layers should register the data that other layers might need. For example, in the `Base` layer, we register the nodes, networks, etc., and resolve all pending networks joins. Layers, however, should not make irreversible changes, as there are chances that other layers will add new data to the emulator.
 
 The configure stage is especially useful if a layer wants to make changes to another layer but still requires the other layer to have configured the emulator first. Currently, this is used in the `ReverseDomainName` and `CymruIpOrigin` service, both of which create a new zone in the `DomainName` service. They do so in the configure stage, as `DomainName` compiles the `Zone` data structure to zone files in the render stage, and additional zone added after the render stage won't be included in the final output. 
 
 ## Why layers?
 
 In the old design, layers are allowed to access the emulator object and registry outside the render stage, which makes layers deeply coupled with a particular emulator scenario code.
 
-One example of this is the DNS layer. We once bulit a DNS infrastructure with the DNS layer. The old DNS layer uses the host node object to keep track of what nodes are hosting what zone (root zone, com TLD, net TLD, etc.). The `Base` layer creates the node objects, which means now the DNS layer is coupled with this particular `Base` layer. To use this DNS infrastructure in another emulation, we have to copy the `Base` layer along with it, which is not ideal as the base layer contains other ASes and IXes, which might cause conflicts in the other emulation where we try to port to.
+One example of this is the DNS layer. We once built a DNS infrastructure with the DNS layer. The old DNS layer uses the host node object to keep track of what nodes are hosting what zone (root zone, com TLD, net TLD, etc.). The `Base` layer creates the node objects, which means now the DNS layer is coupled with this particular `Base` layer. To use this DNS infrastructure in another emulation, we have to copy the `Base` layer along with it, which is not ideal as the base layer contains other ASes and IXes, which might cause conflicts in the other emulation where we try to port to.
 
 Therefore, we make the design decision to have layers keep track of the changes they try to make internally and only make changes during the render stage, so that the individual layers can be easily taken out and moved to other emulations. In the new design, all services layers (DNS is one of the service layers) keep track of nodes they try to install on with IP address or node name, and they find the node to install the server during render, therefore removes the dependencies on the node objects and `Base` layer.
 
@@ -87,7 +87,7 @@ Example of locations of some other objects in the emulator (in the format of `sc
 - IX100's router server node: `ix/rs/ix100`.
 - The `Base` layer: `seedemu/layer/Base`.
 
-To test if an object exist, use `has`:
+To test if an object exists, use `has`:
 
 ```python
 if registry.has('150', 'rnode', 'router0'):
@@ -122,11 +122,11 @@ As mentioned earlier, layers may access each other and make changes to each othe
 
 A layer can require itself to be rendered before or after another layer or ask the emulator to error out when another layer does not exist. This mechanism is called layer dependency. To add a dependency, layer can call `Layer::addDependency`.
 
-`addDependency` takes three parametners:
+`addDependency` takes three parameters:
 
 - `layerName`: string, name of the layer to target.
 - `reverse`: bool, when `True`, this `addDependency` creates a reverse dependency. Regular dependency requires the target layer to be rendered/configured before the current layer, while a reverse dependency requires the current layer to be rendered/configured before the target layer.
-- `optional`: bool, when `True`, the emulator will contine render even if the target layer does not exist in the emulation.
+- `optional`: bool, when `True`, the emulator will continue render even if the target layer does not exist in the emulation.
 
 ## Working with merging
 
@@ -140,10 +140,10 @@ The `getName` call takes no parameter and should return the name of the merger.
 
 ### `Merger::getTargetType`
 
-The `getTargetType` call takes no parameter and should return the name of type that this merger targers. For example, a merger that targets the `Base` layer should return `BaseLayer` here.
+The `getTargetType` call takes no parameter and should return the name of type that this merger targets. For example, a merger that targets the `Base` layer should return `BaseLayer` here.
 
 ### `Merger::doMerge`
 
 The `doMerge` call takes two parameters. Call them `objectA` and `objectB`. When user performs a merge by calling `newEmulator = emulatorA.merge(emulatorB)`, `objectA` will be the object from `emulatorA`, and `objectB` will be the object from `emulatorB`. 
 
-The call should return a new, merged object of the same type with the `objectA` and `objectB`. 
+The call should return a new, merged object of the same type with the `objectA` and `objectB`. 

docs/developer_manual/03-createing-a-new-rap.md

@@ -1,12 +1,12 @@
 # Creating a new remote access provider (RAP)
 
-A remote access provider contains the logic to enable remote access to a network. The way a remote access provider work is that the emulator will provide the remote access provider with:
+A remote access provider contains the logic to enable remote access to a network. The way a remote access provider works is that the emulator will provide the remote access provider with:
 
 - The network to enable remote access on. 
 - A for-service bridging network: this network is not a part of the emulation. Instead, it was used by special services like this to communicate with the emulator host.
 - A bridging node: this node is not a part of emulation. It is a special node that will have access to both the for-service bridging network and the network to enable remote access on.
 
-Then, what a remote access provider usually do is:
+Then, what a remote access provider usually does is:
 
 - Start a VPN server, listen for incoming connections on the for-service bridge network, so the emulator host can port-forward to the VPN server and allow hosts in the real world to connect.
 - Add the VPN server interface and the network to enable remote access on to the same bridge so that clients can access the network.
@@ -27,6 +27,6 @@ The first is a reference to the current emulator instance, in case the access pr
 
 The second is a reference to the network instance of the network to be bridged to - in other words, the goal is to provide remote access to this network.
 
-The third is a reference to a service node. A service node is not part of the emulation. This node can be used to run software (like VPN server) for remote access. This node will be under the same scope as the network passed as the second parameter. The node will be an empty node - no networks connected, no software installed. The regular APIs like `joinNetwork` and `addSoftware` works. 
+The third is a reference to a service node. A service node is not part of the emulation. This node can be used to run software (like VPN server) for remote access. This node will be under the same scope as the network passed as the second parameter. The node will be an empty node - no networks connected, no software installed. The regular APIs like `joinNetwork` and `addSoftware` work. 
 
-The last is a reference to the for-service network. The for service network has a name that begins with `000`; therefore it ensures that whatever nodes joined this network will have this network as their default gateway if compiled by the `Docker` compiler. This will ensure the default gateway works even if the user uses the `selfManagedNetwork` option. If compiled by the `Docker` compiler, this network will have NAT access to the internet.
+The last is a reference to the for-service network. The for service network has a name that begins with `000`; therefore it ensures that whatever nodes joined this network will have this network as their default gateway if compiled by the `Docker` compiler. This will ensure the default gateway works even if the user uses the `selfManagedNetwork` option. If compiled by the `Docker` compiler, this network will have NAT access to the internet.

docs/developer_manual/README.md

@@ -13,7 +13,7 @@
 
 # Contributing to SEED Emulator
 
-Thank you for considering contributing to SEED Emualtor! We appreciate your interest in making our open-source project better.
+Thank you for considering contributing to SEED Emulator! We appreciate your interest in making our open-source project better.
 
 ## How Can You Contribute?