| commit | 25deed4a79f520ca1a749d0e99b7605e1d810621 | [log] [tgz] |
|---|---|---|
| author | Saleil Bhat <smbhat@stanford.edu> | Wed Feb 01 17:24:51 2017 -0800 |
| committer | Pingping Lin <pingping@onlab.us> | Thu Feb 02 23:56:14 2017 -0800 |
| tree | c8ec99d6ad91ee52312bca30802283cae4d063c5 | |
| parent | bb11ab5420e84c2b8b5c53f4e3bf1fd76b29fe95 [diff] |
Added 'image_name' property to vSGW and vPGCW tenant node types (so you can specify desired image via TOSCA) changed 'VPGWCComponent' to 'VGPWCTenant' for consistency with model Change-Id: I82d9fe4659941c8a390a1b8477e5e5bb465fc811
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.
Most frequently, this service-profile repo is checked out by platform-install during a conventional build of a CORD pod. The cord-pod style repos work in this way.
When using the testing configurations like test-standalone and frontend, this repo can be checked out and run on it's own on a Ubuntu 14.04 machine.
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.
cord-pod: R-CORD (Residential)opencloud: Opencloud configurationmcord: M-CORD (Mobile)metronetwork: Metro Network/Enterprise E-CORDacord: Analytics for CORDfrontend: Designed for frontend development, 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.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 - this enables the make cleanup target.
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:
make local_containersmakemake stopmake rmmake update_xosmake update_servicesmake showlogs_bootstrap and make showlogsmake psmake enter-bootstrap-uimake enter-uimake enter-db