SDC Dev onboarding session 2 By Michael Lando

SDC Dev onboarding session 2 By Michael Lando and Vitaliy Emporopulo 2018 -3 -21

Session Agenda • SDC deployment • SDC dev env • SDC onboarding

SDC deployment is docker-based. In Amsterdam release, SDC supported a HEAT-based deployment method. For Beijing, SDC will support OOM as a deployment type and has done considerable modifications to the way we are deployed and monitored to allow easier integration between us and OOM.

SDC deployment dockers Name Description sdc-elasticsearch The docker is responsible for configuring and starting the Elastic server, Server configurations etc. sdc-init-elasticsearch The docker is responsible for loading the information needed by SDC into the Elastic server, Mappings, Kibana dashboards etc. sdc-cassandra The docker is responsible for configuring and starting the Cassandra server, Server configurations, user configurations etc. sdc-cassandra-init The docker is responsible for loading the information needed by SDC into the Cassandra server, key spaces, tables and values etc. sdc-kibana The docker is responsible for configuring and starting the Kibana server, Server configurations etc. sdc-backend The docker is responsible for configuring and starting the jetty back end server, Server configurations etc. sdc-backend-init The docker is responsible for loading the information needed by SDC to function. The docker is responsible for loading the normative types needed for the design. sdc-frontend The docker is responsible for configuring and starting the jetty front end server, Server configurations etc.

SDC dockers deployment order sdc-elasticsearch sdc-cassandra-init sdc-backend sdc-cassandra sdc-init-elasticsearch sdc-kibana sdc-backend-init sdc-frontend

SDC development Env For developers who want to see SDC or who want to contribute to our project we offer two ways of setting up a developer environment. 1. Linux based deployment 2. Vagrant based deployment You can work using a remote Linux Machin/local VM using vagrant. Using the maven configurations you can point the local docker builds to publish them to any docker engine you need.

SDC Onboarding Technical Overview Vitaliy Emporopulo (Amdocs) Mar 20, 2018

Topics • Cloning SDC project and opening it in Intelli. J • Local Maven build. Building the Onboarding without the front-end • Main components • The API/core POM pattern • The platform – configuration, logging, etc. • Deployment. Running on Docker • Coding conventions and static analysis • Code submission guidelines • Writing unit tests. Writing acceptance tests • People to contact

Cloning Behind Corporate Firewall

Full build mvn clean install -P onboarding Build without UI mvn clean install -P onboarding -pl !openecomp-ui mvn clean install -P onboarding -pl ‘!openecomp-ui’ (Linux/Git Bash) Build without UI and common libraries cd openecomp-be mvn clean install

Deployment Units & Flow Vendor • Heat, CSAR • Questionnaire / NFOD • Translation to TOSCA VF <. zip> • Heat Templates (HOT) • Manifest • Artifacts Front-End Box (x 4) Jetty Back-End Box (x 4) Jetty CSAR Onboarding 1. Upload 2. Translate 3. Submit 1+2 Onboarding • • Onboarding 1+2 Cassandra Assets (HTML) Backend proxy 3 3 e. get Browser Catalog 1. Definition 2. Distribution Titan Load-balancer Catalog Onboarding Assets (HTML) Backend proxy Firewall Resource Catalog 3 a. notify Load-balancer Service Catalog • Definition • Distribution • • Authentication/Web Seal Entities Catalog 3 d. get UEB/DMAP 3 b. notify 3 c. notify APPC MSO …

Software Modules Front End Acceptance Tests REST VSP - Vendor Software Product SDC Conflict Management Validation: Heat & Tosca Translation: Heat to Tosca Questionnaire: User-populated data Extract: Heat to Internal Model Healing: Fixes items in old format Compile: Internal Model to Artifacts Enrichment Artifact Generator Activity Log revision history Collaboration Push/pull Versioning Permissions Action Library will be replace by Activity Spec Package: Produces CSAR from Artifacts Revisions Generic Conflict Management VLM - Vendor License Model Configuration Log Application Configuration Health-Check Notifications Frontend Backend

API and Core POMs Hides implementation while exposing API <dependency> <group. Id>…</group. Id> <artifact. Id>bar-api</artifact. Id> <version>${project. version}</version> </dependency> com pile foo run tim e <dependency> <group. Id>…</group. Id> <artifact. Id>bar-core</artifact. Id> <version>${project. version}</version> <scope>runtime</scope> </dependency> bar <modules> <module>bar-api</module> <module>bar-core</module> bar-api implements depends binds to bar-core <dependency> <group. Id>…</group. Id> <artifact. Id>bar-api</artifact. Id> <version>${project. version}</version> </dependency>

Thank you