| commit | a41533fb0a79e7399f7bf0ba53a1211c67e50d04 | [log] [tgz] |
|---|---|---|
| author | Patrick Brady <pb071s@att.com> | Mon Apr 03 09:47:37 2017 -0700 |
| committer | Patrick Brady <pb071s@att.com> | Mon Apr 03 13:36:51 2017 -0700 |
| tree | 8e7e6426a52ce9944baa29afb4ab3fab12e58118 | |
| parent | 6fa6c253d243aa86011d388c6bdc0a9b34284978 [diff] |
Changing to opendaylight version Boron Change-Id: Ic9e2ee43d991f8308afaef7ff5566c27f4119b12 Signed-off-by: Patrick Brady <pb071s@att.com>
The Application Controller (APP-C) is one of the components in the OpenECOMP Platform. Its main function is to perform functions to control the lifecycle of Virtual Functions (VNFs) as well as the components that make up these functions. Therefore, this allows the cloud to be abstracted from Virtual Functions in order to enable repeatable actions, as well as enabling automation and a dynamic configuration approach.
OpenECOMP APP-C is delivered with 3 Docker Containers, which are deployed using Docker Images already containing the APP-C Framework Suite. NOTE: All three containers are hosted on Ubuntu 14.04 LTS OS.
The docker containers described above are set up to be deployed on the same Virtual Machine. Docker Compose is Docker's deployment tool that allows to configure and deploy multiple containers at once.
APP-C (structured as a Maven project) uses the Maven tool to help compile, build, and deploy APP-C Artifacts (usually made up of Java packages) into a Maven Repository. In order to compile and build APP-C, a mvn clean install is executed, which checks for any errors and Java exceptions during compilation process.
mvn clean install, this will generate some code from the yang models.In order to deploy APP-C, a Docker-ready machine needs to be available in order to deploy the APP-C Docker Containers. The following will help explain the requirements in order to run Docker to deploy these containers.
OpenECOMP APP-C docker images are currently stored on the Rackspace Nexus Docker Registry (Maven Repository). The deployment code can be found in the Maven Project that builds and deploys the Docker Images to be deployed in the Nexus Repository (current approach is by using Jenkins). These Docker Images are composed of the APP-C Artifacts (org.openecomp.appc.*) compiled and packaged in the "appc" git repository.
The following Docker images are the actual deployment images used for running APP-C:
Ther following steps are needed to deploy and start OpenECOMP APP-C:
A Jenkins instance for OpenECOMP is required, in which Jenkins Jobs for both the APP-C core code and deployment code are maintained.
Jenkins Job for APP-C Core git project: The Jenkins Job for the APP-C git repository (Core Component) is in charge of compiling and uploading/deploying successfully compiled maven APP-C artifacts into a Nexus/Maven Repository.
Jenkins Job for APP-C Deployment git project: The Jenkins Job is used to run the APP-C Deployment code which ultimately builds and deploy the APP-C Docker Image. Once the Jenkins job runs successfully, the newly compiled images are uploaded to the Nexus Repository. The APP-C Docker image contains all the SDN-C and APP-C artifacts needed to deploy a successful APP-C Component.
As explained in the "APP-C Docker Containers" section, the configuration and set up of the other two docker containers are not maintained by APP-C. MySQL Docker Image is maintained by the Open Source MySQL Community and the Node Red / DGBuilder Docker Image is maintained by SDN-C.
The VM where APP-C will be started needs to have Docker Engine and Docker-Compose installed (instructions on how to set Docker Engine can be found here). The stable version of Docker Engine where APP-C has been tested to work is v1.12. An important requirement in order to access the Docker Image Repository on Nexus Repository (where docker images are currently stored) need to include the Nexus repository certificate imported in the host VM. This is needed for Docker to be able to access the Docker Images required (NOTE: MySQL Docker Image is obtained from the public Docker Hub).
NOTE ON "docker-compose" COMMANDS: The only work if there is a provided docker-compose YAML script in the cmd path
In order to deploy containers, the following steps need to be taken in your host VM (Assuming instructions on how to set up Docker Engine have already been done):
# Install Docker-Compose apt-get install python-pip pip install docker-compose # Login to Nexus Repo to pull Docker Images (this assumes that Nexus Certificate is already imported in the Host VM on /usr/local/share/ca-certificates/ path): docker login <DOCKER_REGISTRY_REPO> # prompts for user credentials as a way to authenticate # Pull latest version of Docker Images (separately) docker pull <APPC_DOCKER_IMAGE_URL> docker pull mysql/mysql-server:5.6 # Default Open-Source MySQL Docker Image docker pull <SDNC_DOCKER_IMAGE_URL> # Pull latest version of Docker Images docker-compose pull # Deploy Containers docker-compose up # add -d argument to start process as a daemon (background process)
# Stop and Destroy Docker Containers (with docker-compose YAML script) docker-compose down # Stop Docker Containers (without docker-compose YAML script) docker stop <APPC_DOCKER_CONTAINER> docker stop <MYSQL_DOCKER_CONTAINER> docker stop <DGBUILDER_DOCKER_CONTAINER> # Destroy Docker Containers (without docker-compose YAML script) docker rm <APPC_DOCKER_CONTAINER> docker rm <MYSQL_DOCKER_CONTAINER> docker rm <DGBUILDER_DOCKER_CONTAINER>
# Check current docker-compose logs generated during 'docker-compose up' process: docker-compose logs # add -f to display logs in real time # Check out docker container's current details docker inspect <DOCKER_CONTAINER> # Verbose output during docker-compose commands docker-compose --verbose <DOCKER_COMPOSE_CMD_ARG>
A Heat template that can be used on RackSpace to spin up the APP-C Host VM as well as the other OpenECOMP Components is available in gitlab. This template would orchestrate the deployment of all OpenECOMP components, which will trigger docker instantiation techniques to start up the containers (either standard docker or docker-compose - depending on how the component's containers get spun up).
First of all, APP-C Features come in the form of Karaf Features (an ODL-OpenDaylight package) which can be composed of one or more OSGI bundles. These features get installed in the ODL framework in order to be used and installed in the APP-C Docker Container (NOTE: SDN-C Core Features also get installed since APP-C docker image uses the SDN-C Core docker image as a base image).
The following command is used to log in / access the docker containers:
docker exec -it <DOCKER_CONTAINER> bash
The following commands are used to check if the APP-C (and SDN-C) Bundles and Features have been installed correctly in ODL (make sure to enter the APP-C Docker Container shell session):
# All commands are done inside the appc docker container # Enter the ODL Karaf Console cd /opt/opendaylight/current/bin ./client -u karaf # Check if features have been installed or not (the ones with an 'X' in the "Installed" column have been successfully installed) feature:list | grep appc # filter app-c features only feature:list | grep sdnc # filter sdn-c features only # Check if bundles have been loaded successfully (the ones with 'Active' in the "State" column have been successfully loaded) bundle:list | grep appc # filter app-c bundles only bundle:list | grep sdnc # grep sdn-c bundles only # Check reason why bundle failed to load bundle:diag | grep <BUNDLE_NAME>
The API Explorer is a GUI provided by OpenDaylight Open Source Framework. This GUI is very useful to send API calls from APIs that are either developed by APP-C or SDN-C frameworks. In order to make these REST calls, some APIs use the RESTCONF protocol to make such calls.
Currently, the APIs that have a Directed Graph (DG) mapped to it are the ones that can be tested which are the SDN-C APIs and APP-C "appc-provider" APIs (LCM APIs will be available to test in later releases).
In order to access this GUI, you need to go to the following website which will prompt for ODL user credentials in order to authenticate (more details on generic API Explorer here):
APP-C Configuration model involves using "default.properties" files (which are usually located in each of the APP-C Features - ../<APPC_FEATURE_BUNDLE>/src/<MAIN_OR_TEST>/resources/org/openecomp/appc/default.properties) for APP-C Feature that have default (or null) property values inside the core APP-C code. These default (or null) properties should be overwritten in the properties file called "appc.properties" located in the APP-C Deployment code (../installation/src/main/appc-properties/appc.properties).
Each APP-C component depends on the property values that are defined for them in order to function properly. For example, the APP-C Feature "appc-rest-adapter" located in the APP-C Core repo is used to listen to events that are being sent and received in the form of DMaaP Messages through a DMaaP Server Instance (which is usually defined as a RESTful API Layer over the Apache Kafka Framework). The properties for this feature need to be defined to point to the right DMaaP set of events to make sure that we are sending and receiving the proper messages on DMaaP.
Currently, there are two ways to change properties for APP-C Features: