Casablanca Deployment Diagram

in progress


Warning: Draft Content

This wiki is under construction

This page details the current deployment artifacts (VM's, docker containers, ports, WARs ...) based on reverse-engineering a deployed demo as well as the current code base.  These are useful as a snapshot of what is actually running in support of our ONAP architecture - to aide in running/triaging the Demo as it evolves.



OOM Pod Init Dependencies

OOM Pod Dependencies v3 - moved


Version 1.0.0

I

n progress

The above 1.0.0 ONAP deployment diagram is based on the following rackspace environment

artifacts_version: 1.0.0-SNAPSHOT

docker_version: 1.0-STAGING-latest

gerrit_branch: release-1.0.0

 gitlab_branch: master

dcae_code_version: 1.0.0


Notes

I keep forgetting about this page - because its content is hidden by default - Release Notes 1.0.0 draft#VMsandContainers

vFirewall Flow Diagram

List of docker images - https://gerrit.onap.org/r/gitweb?p=integration.git;a=blob;f=packaging/docker/docker-images.csv;h=9bac826b024ed76fb991ea3694ca39a669f53bbe;hb=refs/heads/master


  • No labels

9 Comments

  1. Great Drawing!

    A minor observation: All images are named as Ubuntu 14.04, aren't MSO, Robot and SDC Ubuntu 16.04?

    1. Yes, Robot, MSO and SDC use Ubuntu 16.04

    2. Yes, it is a WIP - likely for the next 48 hours - got it up for a discussion but still editing it/transferring from my notebook.

      lsb_release -a | grep Release

      IE: there are 13 14.0.4 and 4 16.04 VM's (including DCAE zldciad4vipstg00) - also there are 17 VM's (12+ 5 DCAE (non-heat template)) - not including 2-3 after the demo is run.  Several of the docker containers don't have their wars yet - should be clean by Sat.

      /michael 

  2. Is there any significance of the colors used ? for e.g. yellow rectangular dot on each component signifies something?. What is the meaning of Groovy box in DCAE with couple of non-docker green boxes ? Are they processes or VMs ? 

    1. I asked that same question about colors about 16 years ago in a meeting - "they look good" - we all laughed.  Here, they hopefully are used for partitioning by type.

      light blue = jar processes, dark blue = war containers, darkest blue = Maria, yellow = deployed artifacts, orange = zookeeper, green = non-docker processes

      dotted line containers = VM's, solid line boxes are processes (docker/non-docker)

      The template is mostly from AWS - the orange dot containers are VMs via the heat template, the grey containers are VMs outside of the heat template (the 5 dcae ones).

      The groovy section corresponds to construction of the dynamic DCAE VM - still finalizing understanding of how orchestration is done here in DCAE for 1.0.0


  3. The diagram is very clear to understand the various components.

    Some corrections:

    • The external port for Portal VM is 8989 and not 8999.
    • For the SDNC, the Dokcer 'sdnc_controller_container' only exposes port 8282 using internal 8181 port

    Some proposals to improve the diagram:

    • I think we should also associate the Docker name with the various boxes
    • We should align the dependency calls with the graph initiated by Gildas and also draw the intenal links between the containers in a VM.

    I can help to update it, but we should introduce this diagram in the Documentation or OOM repo to facilitate the collaborative work.

    1. Eric,  Will update all.  I was starting a 1.1 version as an embeddable gliffy (editable in the page) - but 1.1.0 is currently failing pulling from nexus.  What I will do is redo it as 1.0 and put in the 1.1 changes around aai/policy... 

      I verified most of these by directly going on each box and validating the docker containers - I might have had a diagram copy/paste - fixed

      For dependency calls - I follow the diagram by Gildas - but we need to differentiate between actual running state (1.1.x and proposed R1 state)

      Internal links are the next step - time permitting - will be easier when the diagram is editable shortly.


      2nd time around we are looking OK for 1.1.0-SNAPSHOT/master - moving on to 1.1 diagram

      Processing triggers for ureadahead (0.100.0-19) ...

        % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

                                       Dload  Upload   Total   Spent    Left  Speed

      100   617    0   617    0     0   2919      0 --:--:-- --:--:-- --:--:--  2924

      100 7857k  100 7857k    0     0  16.9M      0 --:--:-- --:--:-- --:--:-- 16.9M

      Cloning into 'test_lab'...

      Already up-to-date.

      docker command: local docker using unix socket

      tName": "AUTO" } }, "mso-po-adapter-config": { "cloud_sites": [ { "id": "Dallas", "aic_version": "2.5", "lcp_clli": "DFW", "region_id": "DFW", "identity_service_id": "RAX_KEYSTONE" }, { "id": "Northern Virg

      root@vm1-mso:~# docker ps

      CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                                                                              NAMES

      06cf1d40c875        openecomp/mso       "/opt/mso/scripts/..."   4 minutes ago       Up 4 minutes        0.0.0.0:3904-3905->3904-3905/tcp, 0.0.0.0:8080->8080/tcp, 0.0.0.0:9990->9990/tcp   testlab_mso_1

      685df48e1e66        mariadb:10.1.11     "/docker-entrypoin..."   4 minutes ago       Up 4 minutes        0.0.0.0:32768->3306/tcp                                                            testlab_mariadb_1

      /michael

  4. Very nice and explanatory pictures Michael. Is this the finalized deployment topology for R1? Or, are there any changes anticipated?

    Thanks,

    Ramki


    1. Good question, there are currently 3 topologies (released, current, proposed)

      released: 1.0.0 (the old April release - the screencap)

      current: 1.1.0/master (the actual topology - the editable diagram - since master started working again on the 12th we can populate this diagram - any changes to this diagram should come directly from a running system - this is why it is taking a while.  Several of us use these diagrams to diagnose whether a deployment is valid or not) - and for validating a kubernetes deployment.

      proposed: The 3rd diagram (not here yet) would be the conceptual target deployment of R1 (Currently the CLI, Logging and Policy projects are adding containers so these would go there until they actually appear in a rackspace/openstack deployment)

      You are welcome to edit the current diagram - only if you are reverse engineering a "verified" fully deployed build - I am currently validating 20170812 on Rackspace - which looks stable so far for AAI, Portal, SDC, VID.

      The purpose of these diagrams is define what is a "running" system - for validation and triage-throughput - a full R1/R2 architecture is in the architecture section.

      /michael