documentation updates and test_containers target
Change-Id: Idea1a3de9dd23d57db3eefd072d650e7db2e0036
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