diff --git a/README.md b/README.md
index 275d16f..5a56d69 100644
--- a/README.md
+++ b/README.md
@@ -1,11 +1,92 @@
 ## Service Profiles
 
-This repository contains service profiles. Each service profile specifies a graph of services that will be instantiated. 
+This repository contains service profiles, one per directory, which configures
+XOS with a graph of services to be instantiated.  These configurations automate
+the creation of containers, loading things into the onboarding synchronizer,
+and starting XOS.
 
-Notable service profiles include:
+### Using this repo
 
-* `cord-pod`: Standard R-CORD service stack, for both single-node-pod and multiple node pod installs. 
-* `frontend`: Designed for frontend development, this profile starts XOS, but does not start any synchronizers other than the onboarding synchronizer. 
-* `test-standalone`: Runs a test suite that tests the REST API and Tosca API.
+Most frequently, this `service-profile` repo is checked out by
+[platform-install](https://github.com/opencord/platform-install/) during a
+conventional build of a CORD pod.  The `cord-pod` style repos work in this way.
 
-The directory `common` is not a service profile, but contains various common files and tools that are used by the other service profiles.
+When using the testing configurations like `test-standalone` and `frontend`,
+this repo can be checked out on it's own on a
+
+The directory `common` is not a service profile, but contains various common
+files and tools that are used by the other service profiles.  The
+`common/Makefile` has many common targets and is included by the other
+makefiles.  `common/Makedefs` specifies the git URL's and branches to use of
+dependent software, which you may need to change if you're doing development on
+a specific service.
+
+In most cases, a profile is started by running `make local_containers; make` in
+it's directory. See the per-directory README's for more information, or the
+list of targets below.
+
+### Notes on specific profiles
+
+#### Used to build CORD pods:
+
+ - `cord-pod`: [R-CORD](https://wiki.opencord.org/display/CORD/Residential+CORD)
+  (Residential)
+ - `opencloud`: [Opencloud](http://www.opencloud.us/) configuration
+ - `mcord`: [M-CORD](https://wiki.opencord.org/display/CORD/Mobile+CORD)
+  (Mobile)
+ - `metronetwork`: Metro Network/Enterprise
+  [E-CORD](https://wiki.opencord.org/display/CORD/Enterprise+CORD)
+ - `acord`: [Analytics for
+  CORD](https://wiki.opencord.org/display/CORD/Analytics+for+CORD)
+
+#### Testing configurations:
+
+ - `frontend`: Designed for [frontend
+  development](https://wiki.opencord.org/display/CORD/User+experience+and+UI),
+  this profile starts XOS without synchronizers (other than onboarding) for
+  quick UI iteration.
+ -  `test-standalone`: Runs a test suite that tests the REST API and Tosca API.
+
+### Creating a new profile
+
+The `devel` or `opencloud` configurations are good examples to start with.  All
+configurations should start with defining `CONFIG_DIR`, `COMMON_DIR` (which
+specify paths and should generally be the same as all other configurations),
+the `.DEFAULT_GOAL` which specifies the target to start, and the
+`DOCKER_PROJECT` and `BOOTSTRAP_PROJECT` variables that specify the names for
+the docker containers created during the build process.
+
+Next, include the `$(COMMON_DIR)/Makefile` which specifies common targets.
+Before adding a new target, consier adding it to the common Makefile if is
+useful across multiple profiles.
+
+Define the default target, and the customize the other targets - most of the
+time, the targets you'll need to customize are `onboarding` and `podconfig`,
+which control which TOSCA files are loaded and which service synchronizer
+containers are created by the onboarding synchronizer.
+
+You'll also need to create a `xos.yaml` which specifies the configuration of
+the onboarded XOS container, and `docker-compose-bootstrap.yml` which
+configures the bootstrap containers.  Optionally, create a `cleanup.sh` to
+clean up between run, if your service profile requires it.
+
+## Utility/Convenience targets
+
+There are several make targets created to help manage and the build process,
+which are defined in `common/Makefile`. Run these within the service directories:
+
+ - Build the containers from scratch using the local XOS source tree: `make
+   local_containers`
+ - Boostrap XOS and start containers: `make`
+ - Stop the containers: `make stop`
+ - Delete the containers (Database contents is deleted): `make rm`
+ - Update XOS source tree: `make update_xos`
+ - Update Services source trees: `make update_services`
+ - View logs: `make showlogs_bootstrap` and `make showlogs`
+ - See what containers are running: `make ps`
+ - Open a shell on the XOS Bootstrap UI container: `make enter-bootstra-ui`
+ - Open a shell on the XOS UI container: `make enter-ui`
+ - Open a shell on the Database container: `make enter-db`
+
+
+
diff --git a/common/Makefile b/common/Makefile
index 6a54b74..79e69b6 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -141,6 +141,8 @@
 
 local_containers: prereqs xos_download update_certs xos_base_c xos_devel_c
 
+test_containers: local_containers xos_test_c
+
 update_certs:
 	echo "" > $(XOS_DIR)/containers/xos/local_certs.crt
 	for CRT in $$(ls /usr/local/share/ca-certificates/*) ; do \
@@ -158,6 +160,7 @@
 xos_test_c:
 	cd $(XOS_DIR)/containers/xos; make test
 
+
 # utilties/convenience targets
 cleanup: stop rm
 	$(CONFIG_DIR)/cleanup.sh
diff --git a/cord-pod/README.md b/cord-pod/README.md
index 120a9ce..7eb3f57 100644
--- a/cord-pod/README.md
+++ b/cord-pod/README.md
@@ -3,73 +3,96 @@
 ## Introduction
 
 This directory holds files that are used to configure a development POD for
-CORD.  For more information on the CORD project, including how to get started, check out
-[the CORD wiki](http://wiki.opencord.org/).
+CORD.  For more information on the CORD project, including how to get started,
+check out [the CORD wiki](http://wiki.opencord.org/).
 
-XOS is composed of several core services that are typically containerized. [Dynamic On-boarding System and Service Profiles](http://wiki.opencord.org/display/CORD/Dynamic+On-boarding+System+and+Service+Profiles) describes these containers and how they fit together.
+XOS is composed of several core services that are typically containerized.
+[Dynamic On-boarding System and Service
+Profiles](http://wiki.opencord.org/display/CORD/Dynamic+On-boarding+System+and+Service+Profiles)
+describes these containers and how they fit together.
 
-This document is primarily focused on how to start the cord-pod service-profile. This service profile is usually located in `~/service-profile/cord-pod/` on an installed pod. This directory is usually located in the `xos` virtual machine.
+This document is primarily focused on how to start the cord-pod
+service-profile. This service profile is usually located in
+`~/service-profile/cord-pod/` on an installed pod. This directory is usually
+located in the `xos` virtual machine.
 
 ### Prerequisites
 
 The following prerequisites should be met:
 
-1. OpenStack should be installed, and OpenStack services (keystone, nova, neutron, glance, etc) should be started.
-2. ONOS should be installed, and at a minimum, ONOS-Cord should be running the VTN app.
+1. OpenStack should be installed, and OpenStack services (keystone, nova,
+   neutron, glance, etc) should be started.
+2. ONOS should be installed, and at a minimum, ONOS-Cord should be running the
+   VTN app.
 
 The usual way to meet these prerequisites is by following one of the methods of
-[building a CORD POD on the CORD Wiki](https://wiki.opencord.org/display/CORD/Build+a+CORD+POD).
+[building a CORD POD on the CORD
+Wiki](https://wiki.opencord.org/display/CORD/Build+a+CORD+POD).
 
 ### Makefile Targets to launch this service-profile
 
 These are generally executed in sequence:
 
 #### `make local_containers`
-Builds the `xosproject/xos`, `xosproject/xos-synchronizer`, and `xosproject/xos-onboarding-synchronizer` container images from source.
+
+Builds the `xosproject/xos`, `xosproject/xos-synchronizer`, and
+`xosproject/xos-onboarding-synchronizer` container images from source.
 
 #### `make`
-Bootstraps xos and onboards a stack of typical cord services. While the services are onboarded, they are not yet configured
+
+Bootstraps xos and onboards a stack of typical cord services. While the
+services are onboarded, they are not yet configured
 
 #### `make vtn`
-Configures the vtn service. If you are using a custom platform that differs from a typical single-node-pod experiment, then you may wish to `make vtn-external.yaml`, then edit the autogenerated `vtn-external.yaml`, and finally run `make vtn`.  
+
+Configures the vtn service. If you are using a custom platform that differs
+from a typical single-node-pod experiment, then you may wish to `make
+vtn-external.yaml`, then edit the autogenerated `vtn-external.yaml`, and
+finally run `make vtn`.
 
 #### `make fabric`
+
 Configures the fabric service.
 
 #### `make cord`
+
 Configures the cord stack.
 
 #### `make cord-subscriber`
+
 Creates a sample subscriber in the cord stack.
 
 #### `make exampleservice`
+
 Builds an example service that launches a web server.
 
 ### Utility Makefile targets
 
-#### `make stop`
-Stops all running containers.
-
-#### `make rm`
-Stops all running containers and then permanently destroys them. As the database is destroyed, this will cause loss of data.
-
 #### `make cleanup`
-Performs both `make stop` and `make cleanup`, and then goes to some extra effort to destroy associated networks, VMs, etc. This is handy when developing using single-node-pod, as it will cleanup the XOS installation and allow the profile to be started fresh.
+
+Performs both `make stop` and `make cleanup`, and then goes
+to some extra effort to destroy associated networks, VMs, etc. This is handy
+when developing using single-node-pod, as it will cleanup the XOS installation
+and allow the profile to be started fresh.
 
 ### Developer workflow
 
 A common developer workflow that involves completely restarting the profile is:
 
 1. Upload new code
-2. Execute `make cleanup; make; make vtn; make fabric; make cord; make cord-subscriber; make exampleservice`
+2. Execute `make cleanup; make local_containers; make; make vtn; make fabric;
+   make cord; make cord-subscriber; make exampleservice`
 
-This workflow exercises many of the capabilities of a CORD POD.  It
-does the following:
+This workflow exercises many of the capabilities of a CORD POD.  It does the
+following:
   - Tears down XOS as well as all OpenStack state that it created
   - Onboards all CORD services, and configures the ONOS apps
   - Creates a sample CORD subscriber (which spins up a vSG)
-  - Onboards `exampleservice` (described in the [Tutorial on Assembling and On-Boarding Services](https://wiki.opencord.org/display/CORD/Assembling+and+On-Boarding+Services%3A+A+Tutorial))
-  - Creates an `exampleservice` tenant (which creates a VM and loads and configures Apache in it)
+  - Onboards `exampleservice` (described in the [Tutorial on Assembling and
+    On-Boarding
+    Services](https://wiki.opencord.org/display/CORD/Assembling+and+On-Boarding+Services%3A+A+Tutorial))
+  - Creates an `exampleservice` tenant (which creates a VM and loads and
+    configures Apache in it)
 
 ### Useful diagnostics
 
@@ -84,27 +107,30 @@
 hostname=nova-compute, hostMgmtIp=192.168.122.177/24, dpIp=192.168.199.1/24, br-int=of:0000000000000001, dpIntf=veth1, init=COMPLETE
 Total 1 nodes
 ```
-The important part is the `init=COMPLETE` at the end.  If you do not see this, refer to
-[the CORD VTN Configuration Guide](https://wiki.opencord.org/display/CORD/VTN+Configuration+Guide) for
-help fixing the problem.  This must be working to bring up VMs on the POD.
+
+The important part is the `init=COMPLETE` at the end.  If you do not see this,
+refer to [the CORD VTN Configuration
+Guide](https://wiki.opencord.org/display/CORD/VTN+Configuration+Guide) for help
+fixing the problem.  This must be working to bring up VMs on the POD.
 
 #### Inspecting the vSG
 
-The above series of `make` commands will spin up a vSG for a sample subscriber.  The
-vSG is implemented as a Docker container (using the
-[andybavier/docker-vcpe](https://hub.docker.com/r/andybavier/docker-vcpe/) image
-hosted on Docker Hub) running inside an Ubuntu VM.  Once the VM is created, you
-can login as the `ubuntu` user at the management network IP (172.27.0.x) on the compute node
-hosting the VM, using the private key generated on the head node by the install process.
-For example, in the single-node development POD configuration, you can login to the VM
-with management IP 172.27.0.2 using a ProxyCommand as follows:
+The above series of `make` commands will spin up a vSG for a sample subscriber.
+The vSG is implemented as a Docker container (using the
+[andybavier/docker-vcpe](https://hub.docker.com/r/andybavier/docker-vcpe/)
+image hosted on Docker Hub) running inside an Ubuntu VM.  Once the VM is
+created, you can login as the `ubuntu` user at the management network IP
+(172.27.0.x) on the compute node hosting the VM, using the private key
+generated on the head node by the install process.  For example, in the
+single-node development POD configuration, you can login to the VM with
+management IP 172.27.0.2 using a ProxyCommand as follows:
 
 ```
 ubuntu@pod:~$ ssh -o ProxyCommand="ssh -W %h:%p ubuntu@nova-compute" ubuntu@172.27.0.2
 ```
 
-Alternatively, you could copy the generated private key to the compute node
-and login from there:
+Alternatively, you could copy the generated private key to the compute node and
+login from there:
 
 ```
 ubuntu@pod:~$ scp ~/.ssh/id_rsa ubuntu@nova-compute:~/.ssh
@@ -112,8 +138,8 @@
 ubuntu@nova-compute:~$ ssh ubuntu@172.27.0.2
 ```
 
-Once logged in to the VM, you can run `sudo docker ps` to see the running
-vSG containers:
+Once logged in to the VM, you can run `sudo docker ps` to see the running vSG
+containers:
 
 ```
 ubuntu@mysite-vsg-1:~$ sudo docker ps
@@ -123,7 +149,9 @@
 
 #### Logging into XOS on CloudLab (or any remote host)
 
-The [CORD POD installation process](https://wiki.opencord.org/display/CORD/Build+a+CORD+POD)
-forwards port 80 on the head node to the `xos` VM.
-You should be able to access the XOS GUI by simply pointing your browser at the head
-node.  Default username/password is `padmin@vicci.org/letmein`.
+The [CORD POD installation
+process](https://wiki.opencord.org/display/CORD/Build+a+CORD+POD) forwards port
+80 on the head node to the `xos` VM.  You should be able to access the XOS GUI
+by simply pointing your browser at the head node.  Default username/password is
+`padmin@vicci.org/letmein`.
+
diff --git a/devel/README.md b/devel/README.md
index 5dbad10..35db4c9 100644
--- a/devel/README.md
+++ b/devel/README.md
@@ -1,11 +1,10 @@
 # XOS development environment
 
-This configuration can be used to do basic end-to-end development of XOS.  It launches
-XOS in three Docker containers (development GUI, Synchronizer, database) and configures XOS
-to talk to an OpenStack backend.  *docker-compose* is used to manage the containers.
+This configuration can be used to do basic end-to-end development of XOS.
 
-**NOTE: If your goal is to create a development environment for [CORD](http://opencord.org/), 
-this configuration is not what you want.  Look at the [cord-pod](../cord-pod) configuration instead!**
+**NOTE: If your goal is to create a development environment for
+[CORD](http://opencord.org/), this configuration is not what you want.  Look at
+the [cord-pod](../cord-pod) configuration instead!**
 
 ## How to run it
 
@@ -16,10 +15,13 @@
 ### CloudLab
 
 To get started on CloudLab:
-* Create an experiment using the *OpenStack* profile.  Choose *Kilo* and
-disable security groups.
-* Wait until you get an email from CloudLab with title "OpenStack Instance Finished Setting Up".
-* Login to the *ctl* node of your experiment and run:
+
+ - Create an experiment using the *OpenStack* profile.  Choose *Kilo* and
+   disable security groups.
+ - Wait until you get an email from CloudLab with title "OpenStack Instance
+   Finished Setting Up".
+ - Login to the *ctl* node of your experiment and run:
+
 ```
 ctl:~$ git clone https://github.com/open-cloud/xos.git
 ctl:~$ cd xos/xos/configurations/devel/
@@ -28,12 +30,12 @@
 
 ### DevStack
 
-On a server with a fresh Ubuntu 14.04 install, 
-[this script](https://raw.githubusercontent.com/open-cloud/xos/master/xos/configurations/common/devstack/setup-devstack.sh)
-can be used to bootstrap a single-node DevStack environment that can be used
-for basic XOS development.
-The script installs DevStack and checks out the XOS repository.  Run the script
-and then invoke the XOS configuration for DevStack as follows:
+On a server with a fresh Ubuntu 14.04 install,
+`common/devstack/setup-devstack.sh` can be used to bootstrap a single-node
+DevStack environment that can be used for basic XOS development.  The script
+installs DevStack and checks out the XOS repository.  Run the script and then
+invoke the XOS configuration for DevStack as follows:
+
 ```
 ~$ wget https://raw.githubusercontent.com/open-cloud/xos/master/xos/configurations/common/devstack/setup-devstack.sh
 ~$ bash ./setup-devstack.sh
@@ -41,33 +43,16 @@
 ~/xos/xos/configurations/devel$ make devstack
 ```
 
-This setup has been run successfully in a VirtualBox VM with 2 CPUs and 4096 GB RAM.
-However it is recommended to use a dedicated server with more resources.
+This setup has been run successfully in a VirtualBox VM with 2 CPUs and 4096 GB
+RAM.  However it is recommended to use a dedicated server with more resources.
 
 
 ## What you get
 
-XOS will be set up with a single Deployment and Site.  It should be in a state where
-you can create slices and associate instances with them.
+XOS will be set up with a single Deployment and Site.  It should be in a state
+where you can create slices and associate instances with them.
 
-Note that there are some issues with the networking setup in this configuration:
-VMs do not have a working DNS configuration in `/etc/resolv.conf`.  If you fix this
-manually then everything should work.
+Note that there are some issues with the networking setup in this
+configuration: VMs do not have a working DNS configuration in
+`/etc/resolv.conf`.  If you fix this manually then everything should work.
 
-## Docker Helpers
-
-Stop the containers: `make stop`
-
-Restart the containers: `make stop; make [cloudlab|devstack]`
-
-Delete the containers and relaunch them: `make rm; make [cloudlab|devstack]`
-
-Build the containers from scratch using the local XOS source tree: `make containers`
-
-View logs: `make showlogs`
-
-See what containers are running: `make ps`
-
-Open a shell on the XOS container: `make enter-xos`
-
-Open a shell on the Synchronizer container: `make enter-synchronizer`
diff --git a/frontend/README.md b/frontend/README.md
index 9e10d83..341dd12 100644
--- a/frontend/README.md
+++ b/frontend/README.md
@@ -1,78 +1,97 @@
 # XOS UI Development
 
 This configuration launches the XOS GUI and database in separate containers
-using docker-compose.  The Synchronizer is not started and there is no openstack backend connected for XOS.  This configuration is intended for developing the XOS GUI.
+using docker-compose.  The Synchronizer is not started and there is no
+openstack backend connected for XOS.  This configuration is intended for
+developing the XOS GUI.
 
 ## Getting Started
 
 - Navigate to `/service-profile/configurations/frontend` folder
 - Run `make` command
 
-You'll be able to visit XOS at `0.0.0.0:9000` and the `xos/core/xoslib` folder is shared with the container. This means that any update to that folder is automatically reported in the container.
+You'll be able to visit XOS at `0.0.0.0:9000` and the `xos/core/xoslib` folder
+is shared with the container. This means that any update to that folder is
+automatically reported in the container.
 
 ### Working on the Django Application
+
 If you need to work on the Django application itself:
-- comment out the `sleep 86400` command for the `xos_bootstrap_ui` container in `docker-compose-bootstrap.yml`
-- comment the `python /opt/xos/manage.py runserver 0.0.0.0:9998 --insecure --makemigrations` in the same file
+
+- comment out the `sleep 86400` command for the `xos_bootstrap_ui` container in
+  `docker-compose-bootstrap.yml`
+- comment the `python /opt/xos/manage.py runserver 0.0.0.0:9998 --insecure
+  --makemigrations` in the same file
 - run `make local_containers`.
 - run `make`
 
-You'll notice that the `make` command will hang on to `Waiting for XOS to start listening on port 9998`, so in another shell:
-- run `make enter-bootstrap-ui`, this will bring you inside the running bootstrap container
-- from inside the bootstrap container run `python /opt/xos/manage.py runserver 0.0.0.0:9998 --insecure --makemigrations`
+You'll notice that the `make` command will hang on to `Waiting for XOS to start
+listening on port 9998`, so in another shell:
 
-As this command finish his execution you'll notice that the `make` command will resume and end. Once it has endend your development environment is up and running. 
+- run `make enter-bootstrap-ui`, this will bring you inside the running
+  bootstrap container
+- from inside the bootstrap container run `python /opt/xos/manage.py runserver
+  0.0.0.0:9998 --insecure --makemigrations`
 
-If you are working on core files (not involving services) you can use the `bootstrap_ui` container as target, so connect to port `9998`. To simplify the development `xos/core` and `xos/api/utility` folders are shared between the host filesystem and the container, so you don't have to manually copy file inside the the running `bootstrap_ui` container.
+As this command finish his execution you'll notice that the `make` command will
+resume and end. Once it has endend your development environment is up and
+running.
 
-If instead you are working on services or services API your target container should be the `ui` container, so connect to port `9999`. Note that the `ui` container can be rebuilt from the `synchronizer` container, and it will pull the container in the docker registry, not your local one.
+If you are working on core files (not involving services) you can use the
+`bootstrap_ui` container as target, so connect to port `9998`. To simplify the
+development `xos/core` and `xos/api/utility` folders are shared between the
+host filesystem and the container, so you don't have to manually copy file
+inside the the running `bootstrap_ui` container.
+
+If instead you are working on services or services API your target container
+should be the `ui` container, so connect to port `9999`. Note that the `ui`
+container can be rebuilt from the `synchronizer` container, and it will pull
+the container in the docker registry, not your local one.
 
 > _NOTE:
-> Please be careful and do not commit migrations, private keys or other autogenerated files._
+> Please be careful and do not commit migrations, private keys or other
+> autogenerated files._
 
 
 ### Using Vagrant
 
-Vagrant environment is provided with a ubuntu_14.04 box (ubuntu/trusty64). 
+Vagrant environment is provided with a ubuntu_14.04 box (ubuntu/trusty64).
 
-It will run xos on the following address `192.168.46.100:9999`. 
-It will also share the `service-profile` and `xos` folder with the vagrant box. These two directory are intended to be side by side.
+It will run xos on the following address `192.168.46.100:9999`.
+
+It will also share the `service-profile` and `xos` folder with the vagrant box.
+These two directory are intended to be side by side.
 
 How to set it up:
+
 - Start the Vagrant box: `vagrant up`
 - Enter Vagrant box: `vagrant ssh`
 - Start XOS: `cd /opt/service-profile/frontend` and run `make`
 
-### Docker Helpers
-
-Stop the containers: `make stop`
-
-Restart the containers: `make stop; make`
-
-Delete the containers and relaunch them: `make rm; make`
-
-Build the containers from scratch using the local XOS source tree: `make local_containers`
-
-View logs: `make showlogs`
-
-See what containers are running: `make ps`
-
-Open a shell on the XOS container: `make enter-xos`
-
 ## Docs
 
 You can find a Swagger documentation for endpoint at: `http://0.0.0.0:9000/docs/`
 
 ## Populate the Data Model with custom data
 
-Sometimes while developing the GUI is usefull to have control over the DataModel. Sample `tosca` recipes for different configuration are defined in the `mocks` folder, and corresponding `make` commands are provided.
+Sometimes while developing the GUI is usefull to have control over the
+DataModel. Sample `tosca` recipes for different configuration are defined in
+the `mocks` folder, and corresponding `make` commands are provided.
 
 - Bring up the **CORD** data model: `make mock-cord`
 - - Bring up the **M-CORD** data model: `make mock-mcord`
 
 ## JS Styleguide
 
-This project is following [Google JavaScript Style Guide](https://google.github.io/styleguide/javascriptguide.xml). To contribute please install [Eslint](http://eslint.org/) in your editor and run `npm run eslint` before commit.
+This project is following [Google JavaScript Style
+Guide](https://google.github.io/styleguide/javascriptguide.xml). To contribute
+please install [Eslint](http://eslint.org/) in your editor and run `npm run
+eslint` before commit.
 
 > _NOTE_:
-> Many of the already present file were not Style compliant. Linting for them has been disabled as it was to time consuming fix all of them. If **you are going to work** on that files, please **start fixing style issues**, and then **remove the `/* eslint-disable */`** comment
+> Many of the already present file were not Style compliant. Linting for them
+> has been disabled as it was to time consuming fix all of them. If **you are
+> going to work** on that files, please **start fixing style issues**, and then
+> **remove the `/* eslint-disable */`** comment
+
+
diff --git a/metronetwork/README.md b/metronetwork/README.md
index de027c8..6afba7c 100644
--- a/metronetwork/README.md
+++ b/metronetwork/README.md
@@ -1,79 +1,95 @@
-# XOS MetroNetwork 
+# XOS MetroNetwork
 
-This configuration launches the XOS, GUI bootstrap, and synchronizer bootstrap as separate containers. It also
-onboards the metronetwork service, which results in two other containers being created, one for the GUI and one
-for the synchronizer.
+This configuration launches the XOS, GUI bootstrap, and synchronizer bootstrap
+as separate containers. It also onboards the metronetwork service, which
+results in two other containers being created, one for the GUI and one for the
+synchronizer.
 
 ## Getting Started
 
 - Navigate to `service-profile/metronetwork` folder
 - Run `make` command
 
-You'll be able to visit XOS at `0.0.0.0:9998` and the `xos/core/xoslib` folder is shared with the container. This means that any update to that folder is automatically reported in the container.
+You'll be able to visit XOS at `0.0.0.0:9998` and the `xos/core/xoslib` folder
+is shared with the container. This means that any update to that folder is
+automatically reported in the container.
 
 ### Working on the Django Application
+
 If you need to work on the Django application itself:
-- comment out the `sleep 86400` command for the `xos_bootstrap_ui` container in `docker-compose-bootstrap.yml`
-- comment the `python /opt/xos/manage.py runserver 0.0.0.0:9998 --insecure --makemigrations` in the same file
+
+- comment out the `sleep 86400` command for the `xos_bootstrap_ui` container in
+  `docker-compose-bootstrap.yml`
+- comment the `python /opt/xos/manage.py runserver 0.0.0.0:9998 --insecure
+  --makemigrations` in the same file
 - run `make containers`.
 - run `make`
 
-You'll notice that the `make` command will hang on to `Waiting for XOS to start listening on port 9998`, so in another shell:
-- run `make enter-bootstrap-ui`, this will bring you inside the running bootstrap container
-- from inside the bootstrap container run `python /opt/xos/manage.py runserver 0.0.0.0:9998 --insecure --makemigrations`
+You'll notice that the `make` command will hang on to `Waiting for XOS to start
+listening on port 9998`, so in another shell:
 
-As this command finish his execution you'll notice that the `make` command will resume and end. Once it has endend your development environment is up and running. 
+- run `make enter-bootstrap-ui`, this will bring you inside the running
+  bootstrap container
+- from inside the bootstrap container run `python /opt/xos/manage.py runserver
+  0.0.0.0:9998 --insecure --makemigrations`
 
-If you are working on core files (not involving services) you can use the `bootstrap_ui` container as target, so connect to port `9998`. To simplify the development `xos/core` and `xos/api/utility` folders are shared between the host filesystem and the container, so you don't have to manually copy file inside the the running `bootstrap_ui` container.
+As this command finish his execution you'll notice that the `make` command will
+resume and end. Once it has endend your development environment is up and
+running.
 
-If instead you are working on services or services API your target container should be the `ui` container, so connect to port `9999`. Note that the `ui` container can be rebuilt from the `synchronizer` container, and it will pull the container in the docker registry, not your local one.
+If you are working on core files (not involving services) you can use the
+`bootstrap_ui` container as target, so connect to port `9998`. To simplify the
+development `xos/core` and `xos/api/utility` folders are shared between the
+host filesystem and the container, so you don't have to manually copy file
+inside the the running `bootstrap_ui` container.
+
+If instead you are working on services or services API your target container
+should be the `ui` container, so connect to port `9999`. Note that the `ui`
+container can be rebuilt from the `synchronizer` container, and it will pull
+the container in the docker registry, not your local one.
 
 > _NOTE:
-> Please be careful and do not commit migrations, private keys or other autogenerated files._
-
+> Please be careful and do not commit migrations, private keys or other
+> autogenerated files._
 
 ### Using Vagrant
 
-Vagrant environment is provided with a ubuntu_14.04 box (ubuntu/trusty64). 
+Vagrant environment is provided with a ubuntu_14.04 box (ubuntu/trusty64).
 
-It will run xos on the following address `192.168.46.100:9999`. 
-It will also share the `service-profile` and `xos` folder with the vagrant box. These two directory are intended to be side by side.
+It will run xos on the following address `192.168.46.100:9999`.
+
+It will also share the `service-profile` and `xos` folder with the vagrant box.
+These two directory are intended to be side by side.
 
 How to set it up:
 - Start the Vagrant box: `vagrant up`
 - Enter Vagrant box: `vagrant ssh`
 - Start XOS: `cd /opt/service-profile/metronetwork` and run `make`
 
-### Docker Helpers
-
-Stop the containers: `make stop`
-
-Restart the containers: `make stop; make`
-
-Delete the containers and relaunch them: `make rm; make`
-
-Build the containers from scratch using the local XOS source tree: `make containers`
-
-View logs: `make showlogs`
-
-See what containers are running: `make ps`
-
-Open a shell on the XOS container: `make enter-xos`
-
 ## Docs
 
 You can find a Swagger documentation for endpoint at: `http://0.0.0.0:9998/docs/`
 
 ## Populate the Data Model with custom data
 
-Sometimes while developing the GUI is usefull to have control over the DataModel. Sample `tosca` recipes for different configuration are defined in the `mocks` folder, and corresponding `make` commands are provided.
+Sometimes while developing the GUI is usefull to have control over the
+DataModel. Sample `tosca` recipes for different configuration are defined in
+the `mocks` folder, and corresponding `make` commands are provided.
 
 - Bring up the **CORD** data model: `make mock-cord`
 - - Bring up the **M-CORD** data model: `make mock-mcord`
 
 ## JS Styleguide
 
-This project is following [Google JavaScript Style Guide](https://google.github.io/styleguide/javascriptguide.xml). To contribute please install [Eslint](http://eslint.org/) in your editor and run `npm run eslint` before commit.
+This project is following [Google JavaScript Style
+Guide](https://google.github.io/styleguide/javascriptguide.xml). To contribute
+please install [Eslint](http://eslint.org/) in your editor and run `npm run
+eslint` before commit.
 
 > _NOTE_:
-> Many of the already present file were not Style compliant. Linting for them has been disabled as it was to time consuming fix all of them. If **you are going to work** on that files, please **start fixing style issues**, and then **remove the `/* eslint-disable */`** comment
+> Many of the already present file were not Style compliant. Linting for them
+> has been disabled as it was to time consuming fix all of them. If **you are
+> going to work** on that files, please **start fixing style issues**, and then
+> **remove the `/* eslint-disable */`** comment
+
+
diff --git a/opencloud/README.md b/opencloud/README.md
index 97449ed..0df651f 100644
--- a/opencloud/README.md
+++ b/opencloud/README.md
@@ -1,24 +1,3 @@
-# XOS OpenCloud Portal
+# XOS OpenCloud configuration 
 
-This configuration can be used to bring up XOS on the OpenCloud portal.  It launches
-XOS in three Docker containers (development GUI, Synchronizer, database) and configures XOS
-with the `opencloud.yaml` TOSCA file in this directory.  *docker-compose* is used to manage
-the containers.
-
-## Docker Helpers
-
-Stop the containers: `make stop`
-
-Restart the containers: `make stop; make`
-
-Delete the containers and relaunch them: `make rm; make`
-
-Build the containers from scratch using the local XOS source tree: `make containers`
-
-View logs: `make showlogs`
-
-See what containers are running: `make ps`
-
-Open a shell on the XOS container: `make enter-xos`
-
-Open a shell on the Synchronizer container: `make enter-synchronizer`
+This configuration can be used to bring up XOS on the OpenCloud portal.
diff --git a/test-standalone/README.md b/test-standalone/README.md
index 32e7c95..14f1a7d 100644
--- a/test-standalone/README.md
+++ b/test-standalone/README.md
@@ -1,11 +1,15 @@
-# API Test Configuration
+# XOS API Test Configuration
 
-This configuration is intended to be used to test the API,
-to use it:
+This configuration is intended to be used to test the API, to use it, clone
+`service-profile` onto a supported machine (Ubuntu 14.04 currently), then run
+the following commands:
 
-- `make containers`
-- `make`
+ - `make test_containers`
+ - `make`
+ - `make test`
+ - `make test-tosca`
 
-Then anytime is needed `make test` (`xos/api` folder is shared with the container)
+Note that this test will be automatically executed by [OpenCord
+Jenkins](https://jenkins.opencord.org/) on checkin to the `xos` repo, so it's a
+good idea to make sure these tests pass after doing work on that repo.
 
-Note that this test will be automatically executed by (Jenkins)[https://jenkins.opencord.org/]
\ No newline at end of file