Building SO docker images locally

based on: https://lf-onap.atlassian.net/wiki/display/DW/Building+SO

Accessing Camunda SO Cockpit on lab

(based on: https://lf-onap.atlassian.net/wiki/display/DW/Camunda+custom+workflows)

So port needs to be exposed:

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

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

  processes.xml

  <?xml version="1.0" encoding="UTF-8" ?> <process-application xmlns="http://www.camunda.org/schema/1.0/ProcessApplication" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <process-archive name="mso_war_poc"> <process-engine>default</process-engine> <properties> <property name="isDeleteUponUndeploy">true</property> <property name="isScanForProcessDefinitions">true</property> </properties> </process-archive> </process-application>

  
  
  

• add camunda config

  CamundaConfig.java

  package org.onap.so.bpmn.infrastructure; import org.camunda.bpm.BpmPlatform; import org.camunda.bpm.ProcessEngineService; import org.camunda.bpm.engine.ProcessEngine; import org.camunda.bpm.engine.RepositoryService; import org.camunda.bpm.engine.RuntimeService; import org.camunda.bpm.engine.spring.application.SpringServletProcessApplication; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; @Configuration public class CamundaConfig { @Bean public SpringServletProcessApplication springServletProcessApplication() { return new SpringServletProcessApplication(); } @Bean public ProcessEngineService processEngineService() { return BpmPlatform.getProcessEngineService(); } @Bean public ProcessEngine processEngine(ProcessEngineService processEngineService) { return processEngineService.getDefaultProcessEngine(); } @Bean public RepositoryService repositoryService(ProcessEngine processEngine) { return processEngine.getRepositoryService(); } @Bean public RuntimeService runtimeService(ProcessEngine processEngine) { return processEngine.getRuntimeService(); } }

  
  
  

• 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: https://gerrit.onap.org/r/c/so/+/101907

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 testing 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

Dockerfile

• 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: https://gerrit.onap.org/r/c/so/+/101907

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:

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 workflow application is created here: 

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:

foo deployment log

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.

Running modified Service-Macro-Create workflow

Start the macro create service workflow from VID.

It should also be possible to see the log entries produced during Foo java delegate execution

log entries produced by Foo task implementation deployed as separate war