commit | b67d61fa3ed22f967f00bb12ceab40ad83700e17 | [log] [tgz] |
---|---|---|
author | Srivahni Chivukula <srivahni.chivukula@intel.com> | Tue Sep 18 08:32:49 2018 -0700 |
committer | Srivahni Chivukula <srivahni.chivukula@intel.com> | Tue Sep 18 08:44:30 2018 -0700 |
tree | 06f7707a83fa6d0fbcb37797d3d46f6363cc3838 | |
parent | ae6dd3e07bea17a6e4664a01f142afa8003debbe [diff] |
Add homing to CreateGenericALaCarteService flow Created HomingBB.bpmn in so-bpmn-building-blocks and updated AssignVnfBB to use HomingBB.bpmn. HomingBB.bpmn is made capable of using Sniro/OOF Issue-ID: SO-927 Change-Id: I19c8ada96485f563c2756a22ad3bee4c9367953b Signed-off-by: Marcus G K Williams <marcus.williams@intel.com> Signed-off-by: Srivahni Chivukula <srivahni.chivukula@intel.com>
ONAP MSO is delivered with 2 Docker containers, 1 hosting the database (MariaDB) and 1 hosting the JBoss application server running all ONAP MSO code.
Both containers runs on the same machine and can be started with docker-compose
.
MSO can be compiled with mvn clean install
. Integration tests are started with the following profile -P with-integration-tests
to be edited for rrelease Docker containers are build with the following profile -P docker -Ddocker.buildArg.chef_repo_branch_name=bugfix/external_adress -Ddocker.buildArg.chef_repo_git_username=git -Ddocker.buildArg.chef_repo_address=23.253.149.175/mso -Ddocker.buildArg.chef_repo_git_name=chef-repo
ONAP MSO containers are stored on here for the releases, and here for the snapshots
The following Docker images are the actual deployment images used for running MSO
Name | Tag | Description |
---|---|---|
onap/mso | 1.0.0 | Contains JBoss + OpenJDK + MSO components (BPMN engine and MSO API handlers and adapters) |
library/mariadb | 10.1.11 | MariaDB image from Docker.io, this image hosts the database and is preloaded with MSO schema and configuration at startup |
You can use docker-compose
to start MSO. The file is as the root of the directory. See Getting the containers
to pull the images
A heat template that can be used on RackSpace to spin up the MSO Host VM and run docker-compose is currently being built by the Demo Team.
MSO UIs are not really used for operating MSO, but they provide information on what is currently happening and get an insight on the components.
JBoss Wildly provides administrative functions through the application [server console](https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-Accessingthewebconsole].
Said console can be used to have a look at the status of MSO. It is providing details on deployed artifacts and gives a remote access to the main server log file
The UI can be accessed trough http://containerHostName:9990/
The configuration preloads a default user (admin) with the standard placeholder
password.
The configuration of JBoss should not be touched. But it is possible to look at the two following sections for insights on the MSO health :
Deployments shows what is deployed and running on the application server, you should see the following once MSO is up and running (Actual names of the War files may differ but their numbers and general format should be the same)
to be upload when rrelease
Runtime can be used to have a look a the main server log files, see JVM status and parameters, environment settings etc,...
See the logging section below for more details about other logfiles (EELF framework)
MSO orchestration processes can be monitored with the Camunda Engine cockpit UI. It gives an insight about the available processes, allows to trigger them manually and provides monitoring of the currently running processes
IMPORTANT NOTE : since ONAP MSO only uses Camunda Community version it is not possible to see history of running process as this is an Enterprise feature only.
The cockpit is available at the following address : http://containerHostname:8080/cockpit
When the container is started it will create a default admin user (admin) with the password placeholder
for UI
The cockpit gives an overview of the available BPMN (orchestration) processes (with a visual representation). It is also possible to trigger them from the UI if you know the parameters that are needed.
screenshots to be uploaded when rrelease
Most of the MSO features within ONAP MSO are triggered by using RESTful interfaces. MSO supports both HTTP and HTTPS, but is configured on this release with HTTP only using Basic Authentification.
The MSO APIs are configured to accept requests having a basic auth. header set with various username and password depending on which API is being triggered.
All API endpoints are exposed on port 8080, it is possible to reach all MSO subsystems directly with the proper query (see more information below on how to test MSO functions)
VID endpoint : http://vm1.mso.simpledemo.onap.org:8080/ecomp/mso/infra/serviceInstances/v2
The typical easy way to trigger these endpoints is to use a RESTful client or automation framework.
It is important to understand that the Docker containers are using a configuration file (JSON) in order to provision MSO basic configuration, in the above Jenkins Job, Jenkins pulls that JSON file from the MSO repository, any other mean to provide that JSON file (for specific environments) would also work.
Once the deployment of the docker images is done, you will need to configure your installation to be able to interact with all the components that MSO needs.
Change the environment file located here : /shared/mso-docker.json then run the following command chef-solo -c /var/berks-cookbooks/chef-repo/solo.rb -o recipe[mso-config::apih],recipe[mso-config::bpmn],recipe[mso-config::jra]
Important note: The host mso is mapped automatically to c1.vm1.mso.simpledemo.onap.org in /etc/host of the docker image so you can keep mso:8080 when you want to mention the APIH, JRA or Camunda host.
Here are the main parameters you could change:
The credentials are defined in 2 places:
You can encrypt the JBoss user with the following command echo -n 'LOGIN:ApplicationRealm:PASSWORD' |openssl dgst -md5
and replace the line corresponding to this user in /opt/jboss/standalone/configuration/application-users.properties
You can replace the authentication in the environment by the value returned by the following API GET on http://c1.vm1.mso.simpledemo.onap.org:8080/asdc/properties/encrypt/{value}/{cryptKey}
where {value} is the string login:password and cryptKey (also defined in the environment) is the key to use to encrypt the credentials
Exemple of credentials you could change:
MSO log files are located the JBoss log folder in the container.
EELF framework is used for specific logs (audit, metric and error logs). They are tracking inter component logs (request and response) and allow to follow a complete flow through the MSO subsystem
EELF logs are located at the following location on the MSO JBoss container :
The DEBUG mode is enabled by module and has to be re-enabled if the application restart.
It can be enabled with a GET on the following APIs:
Default JBoss users:
Note that these default users should be changed.
For this first release of MSO, the queries to start the various VNFs should come first through API Handler.
To help with the testing we are providing here a sample SoapUI project [file](add link when rrealease) with the main queries that VID should send to MSO
The MariaDB container can load up special SQL scripts that simulates the loading of ASDC components (as if they were received through the ASDC client)
Simply use the load ability embedded to run the 'preload SQL' script for vFirewall or vDNS
It is also possible to simulate queries to the PO (platform orchestrator) adapter of MSO (thus bypassing BPMN flows and API handler) to verify MSO interaction with Rackspace and verify the behavior of the Adapter (so that it loads HEAT and connect to Rackspace and instantiate elements)
Below is a query used from FireFox RESTClient plugin to trigger MSO adapter directly (replace values accordingly)
POST http://<containername>:8080/vnfs/rest/v1/vnfs/5259ba4a-cf0d-4791-9c60-9117faa5cdea/vf-modules Header: content-type: application/json +Authorization login/password BPELClient/password1$F {"createVfModuleRequest":{"messageId":"ec9537bb-c837-477f-86a5-21c717be96f1-1479156376597","skipAAI":true,"notificationUrl":"http://bpmnhost:8080/mso/vnfAdapterRestNotify","cloudSiteId":"RACKSPACE","tenantId":"1015548","vnfId":"5259ba4a-cf0d-4791-9c60-9117faa5cdea","vnfType":"vfw-service/VFWResource-1","vnfVersion":"1.0","vfModuleId":"7d8412bb-b288-44ff-92ef-723018f940fc","vfModuleName":"MSO_VFW_TEST","vfModuleType":"VF_RI1_VFW::module-1","volumeGroupId":"","volumeGroupStackId":"","baseVfModuleId":"","baseVfModuleStackId":"","requestType":"","failIfExists":true,"backout":true,"vfModuleParams":{"vf_module_name":"MSO_VFW_TEST","vnf_name":"vfw-service/VFWResource-1","vnf_id":"5259ba4a-cf0d-4791-9c60-9117faa5cdea","vf_module_id":"7d8412bb-b288-44ff-92ef-723018f940fc"},"msoRequest":{"requestId":"ec9537bb-c837-477f-86a5-21c717be96f1","serviceInstanceId":"369cdf85-1b61-41ff-b637-c6b7dd020326"},"synchronous":false}}
*** to be completed on rrelease ***
MSO Javadoc and Maven site
*** to be completed on rrelease ***