This Page will show the Daily status of the ONAP master branch with info such as issues/WA/relevant info regarding the ONAP components - latest update now on vCPE Integration Test Progress

In this way we will be able to track the progress of all the Projects under ONAP, and to be able to solve issues faster while everyone is familiar with the latest issues and get info how to solve them with the info below.

For stabilizing the ONAP, we are considering vFW use case (Open loop)asa E2E flow. Below are the issues we are facing while wetrytosetup a stable environment torunthevFW use case successfully. Please observe the status info below regarding all ONAP (Heat based)components in Openstack.

Contacts

Ran Pollak, Michael O'Brien, Geora Barsky, Parvez Shaik, 


see  INT-106 - Getting issue details... STATUS

Automated R1 Deployments Testing Healthcheck

EnvironmentResults
OOM

Every 2 hours

http://jenkins.onap.info/job/oom-cd/

HEATPending


Run every 2 hours

http://jenkins.onap.info/job/oom-cd/

Integration Test Blocking Issues

Gildas TSC Daily JIRA link  https://lists.onap.org/pipermail/onap-tsc/2017-October/003766.html

JIRA Integration Open Issues (label=Integration)

Key Summary Created Updated Assignee Reporter P Status
Refresh

Blocking Issues for ONAP 1.1 R1 Integration - workarounds

Component Status (20171023 currently determining)

 Component

Docker download date

Number of running dockers

Docker Image availability

Kubernetis

Robot “health-check”


Robot “health-check”

JIRA

Workdarounds

vFirewall






AAF






AAI1








AAI2








APPC




PASS 


CLAMP


 PASS 


CLI






CONSUL






DCAE-CONT

ROLLER








DCAE zldc<dc> vi cdap(3), pstg, coll


FAIL 


DCAEGEN2





https://lists.onap.org/pipermail/onap-discuss/2017-October/005378.html


DNS -SERVER








LOG






VID




PASS 


ROBOT




PASS 


SDC




PASS


kube2msb (registrator)






MSB






MSO (heat)

SO (k8s)




PASS


PORTAL




PASS


POLICY




PASS


SDNC




PASS


MESSAGE -ROUTER








MULTICLOUD






USECASE-UI






VF-C






VNFSDK






JIRA Integration Closed Issues (label=Integration)

Key Summary Created Updated Assignee Reporter P Status Resolution
Refresh






  • No labels

10 Comments

  1. Helen Chen

    Ran, where did you run those testing? Could you please do it at ONAP community developer lab? Therefore, it is easier for developer to come over check the issue quickly.

  2. Ran Pollak

    Helen, Of course our goal is to run the tests in the ONAP community developer lab and to update this page regarding the results, for now the results are from our own environment.

    1. Michael O'Brien

      Ran,  Hi, very good page and initiative.  Could you post the exact details of your deployment environment (openstack version, heat template type (float/no-float), whether you are testing on Rackspace as well) - see heat/k8s and vf versions at Installing and Running the ONAP Demos#ONAPDeploymentEnvironments.  We should also be able to post K8S status as well soon.  I only ask this because ONAP as you know behaves differently in all 3 environments currently.  This way we could get the best possible current reference environment posted.

      We should correlate with the status for the heat and k8s deployment versions in 

      ONAP Installation Strategy for Release A | OOM Deployment Status

      thank you

      /michael

  3. Josef Reisinger

    If we talk about "master" branch.. what is the correct configuration for the heat template? I downloaded the latest (as it was for me this morning) HEAT onap_openstack_float dated 29.8.2017 and, after filling the "PUT YOUR xyz" HERE", created an ONAP stack. The results I could see are not in-line with the table above. Maybe the HEAT template does not represent the master branch as

    in DCAE controller's cloud-init-output, I can see a

    docker stop/waiting

    docker start/running, process 10087

    Cloning into 'dcae-startup-vm-controller'...

    Already up-to-date.

    ./dcae_vm_init.sh: line 8: make: command not found

    2017-08-31 10:34:11,552 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-001 [127]

    2017-08-31 10:34:11,564 - cc_scripts_user.py[WARNING]: Failed to run module scripts-user (scripts in /var/lib/cloud/instance/scripts)

    2017-08-31 10:34:11,565 - util.py[WARNING]: Running scripts-user (<module 'cloudinit.config.cc_scripts_user' from '/usr/lib/python2.7/dist-packages/cloudinit/config/cc_scripts_user.pyc'>) failed

    Cloud-init v. 0.7.5 finished at Thu, 31 Aug 2017 10:34:11 +0000. Datasource DataSourceOpenStack [net,ver=2].  Up 219.71 seconds

    After installing make, I could to the "make up" and DCAE started to do it's stuff.

    In Portal's cloud-output I can see lots of error messages

    + git pull
    fatal: Not a git repository (or any of the parent directories): .git
    + cd deliveries
    ./portal_vm_init.sh: line 17: cd: deliveries: No such file or directory
    + source .env
    ./portal_vm_init.sh: line 20: .env: No such file or directory
    + ETC=/PROJECT/OpenSource/UbuntuEP/etc
    + mkdir -p /PROJECT/OpenSource/UbuntuEP/etc
    + cp -r 'properties_rackspace/*' /PROJECT/OpenSource/UbuntuEP/etc
    cp: cannot stat 'properties_rackspace/*': No such file or directory
    + docker login -u docker -p docker nexus3.onap.org:10001
    Login Succeeded
    + docker pull nexus3.onap.org:10001/openecomp/:1.1-STAGING-latest
    invalid reference format
    + docker pull nexus3.onap.org:10001/openecomp/:1.1-STAGING-latest
    invalid reference format
    + docker pull nexus3.onap.org:10001/openecomp/:1.1-STAGING-latest
    invalid reference format
    + docker tag nexus3.onap.org:10001/openecomp/:1.1-STAGING-latest :
    Error parsing reference: "nexus3.onap.org:10001/openecomp/:1.1-STAGING-latest" is not a valid repository/tag: invalid reference format
    + docker tag nexus3.onap.org:10001/openecomp/:1.1-STAGING-latest :
    Error parsing reference: "nexus3.onap.org:10001/openecomp/:1.1-STAGING-latest" is not a valid repository/tag: invalid reference format
    + docker tag nexus3.onap.org:10001/openecomp/:1.1-STAGING-latest :
    Error parsing reference: "nexus3.onap.org:10001/openecomp/:1.1-STAGING-latest" is not a valid repository/tag: invalid reference format

    The version(s) from the HEAT template are

    artifacts_version: 1.1.0-SNAPSHOT
    docker_version: 1.1-STAGING-latest

    nexus_url_snapshot: https://nexus.onap.org/content/repositories/snapshots
    gitlab_branch: master
    dcae_code_version: 1.1.0

    Apparently, something went terribly wrong.... Any ideas/hits what it could ?


    1. Josef Reisinger

      Seems as if I had bad luck yesterday ... downloaded and executed a number of XXX_install scripts and, well, as far as I could see, the install worked (Except aai, which I am looking after right now)

  4. Michael O'Brien

    20170907: getting all 5 dcae vms now in rackspace - very nice

    obrienbiometrics:wse_onap michaelobrien$ openstack server list
| 4ace2349-3c04-481e-b1ce-3e1149fdb46a | zldciad4vicdap02    | ACTIVE | oam_onap_1cEY=10.0.4.105; public=,    | Ubuntu 14.04 LTS (Trusty Tahr) (PVHVM)  |

| b1dd657e-b2ad-4a93-90aa-1402090d8ff1 | zldciad4vicdap01    | ACTIVE | oam_onap_1cEY=10.0.4.104; public=   | Ubuntu 14.04 LTS (Trusty Tahr) (PVHVM)  |

| fab4d8cc-8167-4be2-a26a-0210b399d6ec | zldciad4vicdap00    | ACTIVE | oam_onap_K9D5=10.0.4.103; public=| Ubuntu 14.04 LTS (Trusty Tahr) (PVHVM)  |

| 910ee094-c132-4ddb-b7c2-a6746804a2e8 | zldciad4vipstg00    | ACTIVE | oam_onap_K9D5=10.0.4.101; public=    | Ubuntu 16.04 LTS (Xenial Xerus) (PVHVM) |

| 42d80ad1-a20b-4b95-9481-f93be883bc25 | zldciad4vicoll00    | ACTIVE | oam_onap_1cEY=10.0.4.102; public=  | Ubuntu 14.04 LTS (Trusty Tahr) (PVHVM)  |

| 3cbe3be0-aa6a-4679-944f-12c20cf1fee6 | vm1-aai-inst1       | ACTIVE | oam_onap_1cEY=10.0.1.1; public=       |                                         |

| 0833c54b-8789-4564-8f84-58734a98b96d | vm1-portal          | ACTIVE | oam_onap_1cEY=10.0.9.1; public=    |                                         |

| c16d5c95-c9d5-4482-9116-8d825fa6d7a6 | vm1-aai-inst2       | ACTIVE | oam_onap_1cEY=10.0.1.2; public=   |                                         |

| 1cce0910-b248-430f-947b-b3f0109916eb | vm1-policy          | ACTIVE | oam_onap_1cEY=10.0.6.1; public=   |                                         |

| 31d391ae-4bbd-4de0-b36c-839ed38ec922 | vm1-sdc             | ACTIVE | oam_onap_1cEY=10.0.3.1; public=   |                                         |

| 0f732d03-5775-49e4-ae90-1f29cd2c548d | vm1-robot           | ACTIVE | oam_onap_1cEY=10.0.10.1; public=    | Ubuntu 16.04 LTS (Xenial Xerus) (PVHVM) |
| f8868e7c-eaf3-4871-b01f-ace9b5e0a214 | vm1-appc            | ACTIVE | oam_onap_1cEY=10.0.2.1;     | Ubuntu 14.04 LTS (Trusty Tahr) (PVHVM)  |

| 66b61a15-bdda-4eeb-be7a-93d05b2a4ab7 | vm1-clamp           | ACTIVE | oam_onap_1cEY=10.0.12.1; public=   | Ubuntu 16.04 LTS (Xenial Xerus) (PVHVM) |

| 27b0f2ee-a727-47cf-a381-da3204d3d8b2 | vm1-vid             | ACTIVE | oam_onap_1cEY=10.0.8.1; public=     | Ubuntu 14.04 LTS (Trusty Tahr) (PVHVM)  |

| d83caddb-9a0e-4d16-9d41-072229abe8e7 | vm1-sdnc            | ACTIVE | oam_onap_1cEY=10.0.7.1; public=    | Ubuntu 14.04 LTS (Trusty Tahr) (PVHVM)  |

| 62a777ea-718d-4f55-9905-b8c01196058a | vm1-message-router  | ACTIVE | oam_onap_1cEY=10.0.11.1; public=   | Ubuntu 14.04 LTS (Trusty Tahr) (PVHVM)  |

| 22c60bfd-8bde-49fc-adb0-e15d9e6fcb8d | vm1-mso             | ACTIVE | oam_onap_1cEY=10.0.5.1; public=   | Ubuntu 16.04 LTS (Xenial Xerus) (PVHVM) |

| 8a789790-b693-41f6-870f-459b07da3f3a | vm1-dcae-controller | ACTIVE | oam_onap_1cEY=10.0.4.1; public=     | Ubuntu 14.04 LTS (Trusty Tahr) (PVHVM)  |

| 8de3a5a2-e0f3-4f45-b483-126d1d845b00 | vm1-dns-server      | ACTIVE | oam_onap_1cEY=10.0.0.1; public=   | Ubuntu 14.04 LTS (Trusty Tahr) (PVHVM)  |

  5. Michael O'Brien

    DCAE 1.0 in ONAP 1.1 is deployment-ok for now - but in order to move forward with the vFirewall sanity - we need AAI stable (both the v8 and during our move to v11)

    We need to address rest calls failing like the following

    AAI-79 - Getting issue details... STATUS

    and 

    https://{{aai_ip}}:8443/aai/v8/service-design-and-creation/models

    used to work - Triaging the issue further and I'll advise

    /michael

  6. Michael O'Brien

    To check your results of any robot command during vFirewall testing - everything is ready in OOM

    Yogini and I needed the logs in OOM Kubernetes - they were already there and with a robot:robot auth

    http://nnnn.onap.info:30209/logs/demo/InitDistribution/report.html

    for example after a

    root@ip-172-31-57-55:/dockerdata-nfs/onap/robot# ./demo-k8s.sh distribute

    find your path to the logs by using for example

    root@ip-172-31-57-55:/dockerdata-nfs/onap/robot# kubectl --namespace onap-robot exec -it robot-4251390084-lmdbb bash

    root@robot-4251390084-lmdbb:/# ls /var/opt/OpenECOMP_ETE/html/logs/demo/InitD                                                            

    InitDemo/         InitDistribution/ 

    path is

    http://nnnn.onap.info:30209/logs/demo/InitDemo/log.html#s1-s1-s1-s1-t1

  7. Andrew Fenner

    Hi,

    I've had an issue with PORTAL on an install today.

    Seems to be a mismatch between docker-compose.yml and where the properties files are copied to in the portal_vm_init.sh

    portal_vm_init.sh copies them to /PROJECT/OpenSource/UbuntuEP/etc but docker-compose.yml is getting them from 

    ${PROPS_DIR}/ECOMPSDKAPP/portal.properties

    PROPS_DIR=/PROJECT/OpenSource/UbuntuEP/properties

      see bug  PORTAL-113 - Getting issue details... STATUS

    /Andrew

  8. Michael O'Brien

    We need to consolidate this page - as in deleting content - I am guilty of this - deleting now