Building SO docker images locally
based on: https://wiki.onap.org/display/DW/Building+SO
so] mvn clean install -DskipTests=true -Dmaven.test.skip=true -Dcheckstyle.skip
packages] mvn -DskipTests install -P docker -Dmso.chef.git.url.prefix=ssh://user@gerrit.onap.org:29418 -Dmso.chef.git.branchname=dublin -Dmso.chef.git.url.suffix.chef.repo=so/chef-repo -Dmso.chef.git.url.suffix.chef.config=so/so-config -Ddocker.buildArg.http_proxy=<PROXY> -Ddocker.buildArg.https_proxy=<PROXY>
Accessing Camunda SO Cockpit on lab
(based on: https://wiki.onap.org/display/DW/Camunda+custom+workflows)
So port needs to be exposed:
rke-node:~$ kubectl -n onap expose deployment dev-so-so-bpmn-infra --type NodePort --name dev-so-so-bpmn-infra-expose rke-node:~$ kubectl get services --all-namespaces | grep bpmn-infra onap dev-so-so-bpmn-infra-expose NodePort 10.43.93.167 <none> 8081:32500/TCP 4m9s onap so-bpmn-infra ClusterIP 10.43.207.122 <none> 8081/TCP 67d
now using newly exposed port we can access camunda cockpit app on lab. default credentials are admin/admin
General issues
- no guaranttes that all required so functionalities / use cases are covered by test -> High risk of breaking features / requirements we are not aware of
- Integration of spring boot and camunda is not trivial - issue with settin up proper application context
Building docker image with Camunda running on standalone tomcat
- on hold - there is an official camunda docker image that can be used for initial tests
Running SO BPMN infra on standalone camunda
[grabinsk@localhost ~]$ docker run --rm --name camunda -p 8080:8080 -v /home/grabinsk/dev/onap/so/bpmn/mso-infrastructure-bpmn/target/mso-infrastructure-bpmn-1.4.0-SNAPSHOT.war:/camunda/webapps/mso.war:z camunda/camunda-bpm-platform:7.10.0
Changing mso-infrastructure-bpmn into war
Things that needs to be done / seems needed
- change packaging to war
- set 'failOnMissingWebXml' to false on maven-war-plugin (unless we want to play with adding web.xml)
- update groovy verison to 2.4.13 (in onap/so/bpmn/pom.xml)
- change tomcat dependency (spring-boot-starter-tomcat) scope to 'provided'
- change scope of camunda-engine and camunda-engine-plugin-spin to 'provided' (also in so-bpmn-infrasturcture-common nad so-bpmn-infrastructure-flows)
- remove camunda starters dependencies (camunda-bpm-spring-boot-starter-rest, camunda-bpm-spring-boot-starter-webapp)
- add camunda-engine-spring dependency
add META-INF/process.xml
add camunda config
- configure maven 'unpack' plugin to extract content of jars containing bpmn workflow defnitions (so-bpmn-infrastructure-flows, so-bpmn-building-blocks, MSOCommonBPMN?) and tasks (so-bpmn-tasks) since camunda does not look into libs
- fill all properties in application.yaml with values from lab, or some dummy data so (get rid of props related to camunda db access - proper db setup for camunda persistance shall be configured using camunda docker image own properties)
patch file with changes applied on top of dublin release:
can be build with:
mvn clean install -DskipTests=true -Dmaven.test.skip=true -Dcheckstyle.skip
(2 out of 20 tests in mso-infrastructure-bpmn started to fail - needs checking)
Deploying and teseting on Lab
- change mso-bpmn-infra deployment ( kubectl edit deployment -n onap dev-so-so-bpmn-infra )
- image: camunda/camunda-bpm-platform:7.10.0
- containerPort: 8080 #originally it was 8081, but we can not change that in camunda image → we will need to update that in so-bpmn-infra service definition
in "volumeMounts:" add
- mountPath: /camunda/webapps name: webapps
in "volumes:" add
- hostPath: path: /dockerdata-nfs/webapps type: "" name: webapps
- livenessProbe section causes that bpmn pod restarts every 10 min (this is for further investigation). Delete the following:
livenessProbe:
failureThreshold: 3
httpGet:
path: /manage/health
port: 8081
scheme: HTTP
initialDelaySeconds: 600
periodSeconds: 60
successThreshold: 1
timeoutSeconds: 10
- create 'webapps' in /dockerdata-nfs, add writeaccess for everybody to webapps dir (tomcat will want to extract war in that location)
- copy the mso.war to /dockerdata-nfs/webapps (war file name must be 'mso' since it will appear in URL's of exposed services)
- change target port of so-bpmn-infra to 8080 ( kubectl -n onap edit service so-bpmn-infra ))
Adding ONAP CA certificate
Some workflow tasks communicate with external services (like AAI) and need to validate that service certificate authenticity.
Original setup:
- there is some default onap-ca.crt that is copied and preinstalled in base so docker image
- the image allows providing additional certificates mounted as volume, but the pod definition does not make use of that possibility → the hardcoded cert is in use
- system-wide ca cert installation requires root priviledges and the original mso-bpmn-infra app is running as root.
For the POC purpose onap-ca.crt is preinstalled in the image
- it needst to be further analized how to provide possibility to update the cert without the need to use root account
Patch set on top of dublin including building cammunda-based so-bpmn-infra image with hardcoded onap-ca.crt
Logging
Current POC implementation is not using origianl onap - style logback logging config that stores application logs in some files
All logging is output to system out → one can use standard kubectl -n onap logs dev-so-so-bpmn-infra-77cbf89bd7-krdrw commands to see camunda starup logs as well as application logs.
By since no logging level is explicitly configured for mso.war if visibility of debug logs is desired one can configure it by adding logging.level.org.onap: debug into so-bpmn-infra configmap:
kubectl -n onap edit configmap dev-so-so-bpmn-infra-app-configmap
Adding custom workflow application
The goal is to demonstrate that it could be possible to modularize SO into multiple war files so that they can be independently updated without a need to rebuild full so-bpmn-infra docker image.
In reality extracting any self contained workflow module from SO is challanging.
Therefore for the purpose of this POC a war with simple SO BuildingBlock style workflow is created. The workflow consists of single task that delegates execution to a simple Spring bean that performs some logging.
The test wofklow application is created here: https://gitlabe2.ext.net.nokia.com/grabinsk/onap-so-simple-bb
The foo.war can be produced by simple 'mvn package' execution.
Deploying foo.war
Deploying foo.war is done by copying it to onap lab and moving to /dockerdata-nfs/webapps directory that is mounted as /cammunda/webaps inside so-bpmn-infra container.
sudo cp foo.war /dockerdata-nfs/webapps/foo.war
When succeded a similar log output should be found in so container:
Including FooBB in some existing workflow
Inclusion FooBB in Service-Macro-Create workflow can be done by putting a few new entries into database tables used by catalog-db service.
INSERT INTO orchestration_flow_reference (COMPOSITE_ACTION, SEQ_NO, FLOW_NAME, FLOW_VERSION, NB_REQ_REF_LOOKUP_ID) VALUES('Service-Macro-Create', 20, 'FooBB', 1, 101);
INSERT INTO building_block_detail (BUILDING_BLOCK_NAME, RESOURCE_TYPE, TARGET_ACTION) VALUES('FooBB', 'SERVICE', 'CUSTOM');
INSERT INTO orchestration_status_state_transition_directive (RESOURCE_TYPE, ORCHESTRATION_STATUS, TARGET_ACTION, FLOW_DIRECTIVE) VALUES('SERVICE', 'ACTIVE', 'CUSTOM', 'CONTINUE');
running modified Service-Macro-Create workflow
Start the macro create srevice workflow from VID
It should also be possible to see the log entries produced during Foo java delegate execution
2019-11-07 12:32:48.656 INFO 6 --- [pool-2-thread-1] org.onap.so.foo.Foo : _________________________________________________ FOO !!! 2019-11-07 12:32:48.656 INFO 6 --- [pool-2-thread-1] org.onap.so.foo.Foo : variable: `gBuildingBlockExecution`: org.onap.so.bpmn.common.DelegateExecutionImpl@3cbbf5bb 2019-11-07 12:32:48.656 INFO 6 --- [pool-2-thread-1] org.onap.so.foo.Foo : variable: `mso-request-id`: a9b386b2-8abe-4407-b4d7-fa9959e4c251
full log:
macro_service_create_with_fooBB.log