From 5efe4fcf427c9026e35f3d4926466809c6ef3317 Mon Sep 17 00:00:00 2001
From: Radoslav Pitonak <rpitonak@redhat.com>
Date: Apr 21 2017 08:45:14 +0000
Subject: fixing typos and wrong link


---

diff --git a/README.md b/README.md
index da7571c..e8d25c2 100644
--- a/README.md
+++ b/README.md
@@ -4,29 +4,29 @@
  * __YAML Config file__
      * Each module will need to have yaml config file
      * Config file should cover non generic part - part focused on general module testing
-     * It cloud contain also simple test 
+     * It could contain also simple test
      * __how to write config file__ https://pagure.io/modularity-testing-framework/blob/master/f/docs/howtowriteyamlconf.md
-   
+
  * __Self generated tests__
      * there is possible to write simple tests directly in yaml config file
      * Bash style testing
      * It has  to have solved dependencies inside each module type
-     * Now it just expect to end with `0` return code of command (like: `ls / |grep sbin` directry sbin exists in root dir)
+     * Now it just expect to end with `0` return code of command (like: `ls / |grep sbin` directory sbin exists in root dir)
      * It can contain multiple lines
      * It generates python covered bash tests
-   
+
  * __Avocado tests__
      * There is wrapper class what helps you to tests modules not focusing on module type
      * It uses avocado-framework
      * This test could be primarily used for more complex testing, not previous one
      * General test for modules: `./base/modulelint.py`
      * Example tests in `memcached` module
-   
+
  * __Simple bash tests__
      * There is helper what you can use for writing `bash` like tests
-     * library is https://pagure.io/modularity-testing-framework/blob/master/f/base/bashhelper.py and it is installed as `moduleframework-cmd` command in `/usr/bin`
+     * library is https://pagure.io/modularity-testing-framework/blob/master/f/moduleframework/bashhelper.py and it is installed as `moduleframework-cmd` command in `/usr/bin`
      * Test has to call setup and cleanup of module explicitly
-     * These tests are dependent on return code of commans in test, so in case you have more tests subtest, just count return codes
+     * These tests are dependent on return code of commands in test, so in case you have more tests subtest, just count return codes
      * see example test for https://pagure.io/modularity-testing-framework/blob/master/f/examples/memcached/sanity2.sh
 
 
@@ -39,10 +39,10 @@
  * install vagrant `dnf -y install vagrant`
  * just run `vagrant up`
 
-## Dependencies 
+## Dependencies
  * base dependencies: ```docker python-pip```
  * python dependencies: avocado-framework yaml json
- 
+
 ```bash
 dnf -y install docker python-pip
 ```
@@ -72,7 +72,7 @@ dnf -y install docker python-pip
 
 ## License
  Framework is released under the GPL, version 2 or later, see LICENSE file in project
- 
+
 ## Development
  * automatically built packages (untested): https://copr.fedorainfracloud.org/coprs/jscotka/modularity-testing-framework/
  * aa
diff --git a/docs/howtowriteyamlconf.md b/docs/howtowriteyamlconf.md
index 233584a..aa81fe8 100644
--- a/docs/howtowriteyamlconf.md
+++ b/docs/howtowriteyamlconf.md
@@ -24,7 +24,7 @@ testdependecies:
  * `modulemd-url:` link to modulemd file, now it is not used anyhow, just for installing packages for proper module
  * `service:` In case module is service like memcached, store there port number, can be then used in tests, to not hardcode port number *(Optional)*
  * `packages:` Which packages will be installed inside module (docker container, guest, any type of module)
- * `testdependecies:` Install dependecies on host, what are important for module testing, for example when you would like to use `nc`, you have to install it explicitly, it is not in cloud images.
+ * `testdependecies:` Install dependencies on host, what are important for module testing, for example when you would like to use `nc`, you have to install it explicitly, it is not in cloud images.
 
 ## Module types specification
 It contains specification for each type of module, now for __rpm__ and __docker__ based modules
@@ -48,8 +48,8 @@ module:
  * `start:` how to start service in case it is service, in case of generic module it is *(Optional)*
  * `stop:` how to service service in case it is service, in case of generic module it is *(Optional)*
  * `status:` how to check service state, in case of generic module it is *(Optional)*
- * `labes:` docker labels to check, specific just for *docker* cotainer *(Docker specific)*
- * `cotainer:` where is link to container, now it support docker.io link or using locally tar.gz file specified *(Docker specific)*
+ * `labels:` docker labels to check, specific just for *docker* container *(Docker specific)*
+ * `container:` where is link to container, now it support docker.io link or using locally tar.gz file specified *(Docker specific)*
  *  `repos:` contains all repos what has to be used for this module (typically baseruntime + specific one) *(Rpm specific)*
 
 ## Simple tests inside config
@@ -69,6 +69,5 @@ testhost:
  * `test:` tests what will run inside container - it means that there has to be all dependencies for these test *(Optional)*
   * every command has to finish with __0 return code__ otherwise it will __fail__
   * next level like __processrunning__ is test name what will be visible on output of avocado run, then all lines will be run as commands for this test
- * `testhost:` it is similar to *test*,  just difference is that it runs commands on host machine so that there could be more dependencies than just are in module. I', not sure if this part is usefull, will see after discussion *(Optional)*
+ * `testhost:` it is similar to *test*,  just difference is that it runs commands on host machine so that there could be more dependencies than just are in module. I', not sure if this part is useful, will see after discussion *(Optional)*
   * other specification is same as `test`
-

