Running the ONAP Demos
see also running vFW Demo on ONAP Amsterdam Release
see F2F vetted/merged/collaborated rewrite on Vetted vFirewall Demo - Full draft how-to for F2F and ReadTheDocs
see als vFWCL instantiation, testing, and debuging
ONAP Deployment Videos
ONAP Version | Undercloud | Description | Video |
|---|---|---|---|
1.1 R1 Nov 2017 | Openstack OPEN-LAB | End to End vFirewall from SDC to Closed Loop testing | Pending upload Nov 2017 by Integration team for R1 |
1.0.0 pre Aug 2017 | Rackspace vFirewall E2E | 3 - 1.6G 32min 17:11-17:43 (Run vFirewall demo including closed-loop DMaaP TCA/Measurement stats) (there is a swap of the vLB during onboarding that only affects the service icon - both vLB and vFW are layer 4) | |
1.0.0 pre Aug 2017 | Rackspace ONAP installation (before DCAE) | 1 - 2.2G 23min 16:33-16:57 (bootstrap rackspace ONAP VMs - before 5 DCAE boot up) | |
1.0.0 pre Aug 2017 | Rackspace ONAP installation (DCAE 1.0) | 2 - 1.2G 10min 17:00-17:10 (Observe 5 DCAE VMs come up - wait for ONAP to be stable) - only for timing - does not show much! DCAE 1.0.0 takes up to 26 min to get the dcae-controller docker container up and another 7 min to start orchestration of the cdap cluster check progress by watching the dcae-controller "docker ps" - the collector instance is first to come up, pstg may take up to 24 min after container start and 48 min after VM start, cdap02 is last
| |
|
|
|
|
1.1.0 Oct 2017 | OOM Kubernetes on Rancher on EC2 |
| |
1.0.0 | OOM Kubernetes on Rancher on Openstack | Mike's presentation where the vFirewall comes up - ONAP Operations Manager Project#DemoVideo see min TDB |
VNF Onboarding, Instantiation, and Closed-loop Operations
ONAP Version | Operation | Description | Video |
|---|---|---|---|
Amsterdam Release Nov 2017 (still good for Beijing Release) | VNF Onboarding via SDC | Step-by-step presentation that illustrates how to onboard a VNF via SDC and create a new service | |
Amsterdam Release Nov 2017 (still good for Beijing Release) | vFirewall closed loop | Step-by-step presentation that illustrates how to run closed-loop operations for the vFW use case. | |
Amsterdam Release Nov 2017 (still good for Beijing Release) | vLoadBalancer/vDNS closed loop | Step-by-step presentation that illustrates how to run closed-loop operations for the vLB/vDNS use case | |
Amsterdam Release | vCPE demo | Video that shows vCPE closed loop | |
Amsterdam Release Nov 2017 Alexis | vFirewall closed loop / Vanilla Openstack Private Cloud | Step-by-step presentation of vFW use case and closed-loop operations on a Vanilla Openstack (Newton) private cloud; service and VNF instantiated with SO APIs.
|  |
Amsterdam Release Nov 2017 Alexis | vLB/DNS closed loop / Vanilla Openstack Private Cloud | Step-by-step presentation of vLB/DNS use case and closed-loop operations on a Vanilla Openstack (Newton) private cloud; service and VNF instantiated with SO APIs.
|
ONAP VF Templates
Release | Artifact | References | Description |
|---|---|---|---|
1.0.0/R1 | vFirewall VF Heat Template |
https://nexus.onap.org/content/sites/raw/org.openecomp.demo/heat/vFW/1.0.0/base_vfw.env containing the repo https://nexus.onap.org/content/sites/raw/org.openecomp.demo/vnfs/vfw/1.0.0-SNAPSHOT | vFirewall heat template zips |
1.0.0 | vFirewall SSH key | /testsuite/robot/assets/keys/robot_ssh_private_key.pvt | ssh key for the demo instances (fwl, sink, traffic generator) |
Quickstart Instructions
(The following are a short form of the full demo instructions)
User workflow
Duration: 5 min until robot init/preload - 10 min after that.
Tutorial: Verifying and Observing a deployed Service Instance#vFirewallFlow
Optional |
|---|
R1.0.0 License Model as cs on SDC onboard | new license model | license key groups (network wide / Universal) | Entitlement pools (network wide / absolute 100 / CPU / 000001 / Other tbd / Month) | Feature Groups (123456) | Available Entitlement Pools (push right) | License Agreements | Add license agreement (unlimited) - push right / save / check-in / submit | Onboard breadcrumb VF Onboard | new Vendor (not Virtual) Software Product (FWL App L4+) - select network package not manual checkbox | select LA (Lversion 1, LA, then FG) save | upload zip | proceed to validation | checkin | submit Onboard home | drop vendor software prod repo on "top right" | select, import vsp | create | icon | submit for testing Distributing as jm | start testing | accept as cs | sdc home | see firewall | add service | cat=l4, 123456 create | icon | composition, expand left app L4 - drag both vsps | submit for testing as jm | start testing | accept as gv | approve as op | distribute
|
R1 License Model as cs on SDC onboard | new license model | license key groups (network wide / Universal) | Entitlement pools (network wide / absolute 100 / CPU / 000001 / Other tbd / Month) | Feature Groups (123456) | Available Entitlement Pools (push right) | License Agreements | Add license agreement (unlimited) - push right / save / check-in / submit | Onboard breadcrumb VF Onboard | new Vendor (not Virtual) Software Product (FWL App L4+) - | select network package not manual checkbox | select LA (Lversion 1, LA, then FG) - ignore warning - save | upload vFWSink attachments zip proceed to validation | checkin | submit | 2nd VSP - same above expept vFWPG.zip | proceed validation, checkin submit | Onboard home | drop vendor software prod repo on "top right" | select, import vsp | create | icon | submit for testing - do twice for each vFWSNK, vFWPG Distributing as jm | start testing | accept - for both vFWSNK, vFWPG as cs | sdc home | see firewall | add service | cat=l4, 123456 create | icon | composition, expand left app L4 - drag both vsps | submit for testing as jm | start testing | accept as gv | approve as op | distribute | monitor Robot operations ./demo.sh init_robot see http://amsterdam.onap.info:30209/ http://amsterdam.onap.info:30209/logs/ example health check results http://amsterdam.onap.info:30209/logs/ETE_11778/report.html ./demo.sh init (verify cloud-region in AAI set)
|
todo: incorporate https://lists.onap.org/pipermail/onap-discuss/2017-November/006401.html
todo: add "cli" alternatives to gui/rest commands - http://portal.api.simpledemo.onap.org:9090/
- Tutorial: Accessing the ONAP Portal
- (Optional) Tutorial: Onboarding and Distributing a Vendor Software Product (VSP)
- Tutorial: Creating a Service Instance from a Design Model
- Tutorial: Verifying and Observing a deployed Service Instance
- Tutorial: Demo Environment Restore
- Vetted vFirewall Demo - Full draft how-to for F2F and ReadTheDocs
- Hands On Demo Sessions
- Running ONAP Demos on Azure
- Tutorial: Step by step guide to run vFirewall Closed Loop Demo
- vFW CDS Casablanca
- vDNS CDS Dublin
- vLB CDS El Alto
- vLB CDS Frankfurt
- vFW CDS Dublin
Comments
@Michael O'Brien - (deprecated as of 20170508) - use obrienlabs, @Daniel Rose, @Rich Bennett, @Marco Platania, @Avi Chapnick, @Borislav Glozman, @Luke Parker
Hi All,
I have a couple of questions regarding message-router initial data - topics, topic ACLs and DMaaP keys.
Right now I see that the demo uses zookeeper and kafka binary dump files with pre-populated initial data. DMaaP consumer configuration files have the DMaaP keys matching the data in the dump files.
So the questions are:
How the zookeeper and kafka dump files are created?
Are there already plans to change this approach? If yes, is there story for it?
I see that there is also script for creating the initial DMaaP configuration, but looks like it is not in use because it will create new DMaaP keys and then the keys must be distributed to the clients.
Thanks,
Yury.
@Lusheng Ji, can you please shed light on this?
In long term, authentication should be done through a framework such as the AAF. But before that really happens, there are components still use legacy mechanisms for topic access authentication such as API keys. So what you see is a work-around for supporting preconfigured API keys for authentication. The way it was done was pretty hacky, driven by the deadlines and the lack of proper API support on the Message Router for this use model. Basically I took a snapshot of the running container's directories. I never had the time to get back to this to do it properly, and secretly I also hope that the problem will go away after everybody comes onto the same page of using an authentication framework such as AAF.
Now DMaaP is its own project, I am no longer involved. Perhaps @Varun Gudisena from the DMaaP team can comment on the plan?
DMaaP Message Router currently supports both APIKEY and AAF Authentication. If clients have migrated to start using AAF authentication, they can start disregarding API keys.I recommend using AAF for Authentication
1) The zookeeper and kafka “data log” directories are created under the directories that are specified in kafka’s server.properties and zookeeper’s zoo.cfg (“log”) configuration file.
That are done by zookeeper and kafka service itself when the topic is created or accessed.
I believe they reuse those directories (where the topics, ACL etc are stored in zookeeper / kafka directories) so they don’t have to recreate the topics and ACLs again in the new environment (cluster) from scratch.
API keys are specific to cluster so we cannot create the same values/credentials by extracting outside and use it for another env/cluster.
The application team can choose to recreate the topics in new env and add new keys for those topics, if they are not willing to create dump the binaries/data directories from previous clusters. It is being done for quick activity.
2) We don't have plans for now to change this approach.
Notes: 20170804 Rackspace install of 1.1.0 - nexus repo not resolved - investigating
Cloud-init v. 0.7.9 running 'modules:config' at Fri, 04 Aug 2017 16:30:08 +0000. Up 14.31 seconds.
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not resolve host: nexus.onap.org
chmod: cannot access 'mso_install.sh': No such file or directory
/var/lib/cloud/instance/scripts/part-001: line 23: ./mso_install.sh: No such file or directory
Cloud-init v. 0.7.9 running 'modules:final' at Fri, 04 Aug 2017 16:30:11 +0000. Up 16.58 seconds.
2017-08-04 16:30:11,249 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-001 [127]
2017-08-04 16:30:11,252 - cc_scripts_user.py[WARNING]: Failed to run module scripts-user (scripts in /var/lib/cloud/instance/scripts)
2017-08-04 16:30:11,253 - util.py[WARNING]: Running module scripts-user (<module 'cloudinit.config.cc_scripts_user' from '/usr/lib/python3/dist-packages/cloudinit/config/cc_scripts_user.py'>) failed
Cloud-init v. 0.7.9 finished at Fri, 04 Aug 2017 16:30:11 +0000. Datasource DataSourceConfigDrive [net,ver=2][source=/dev/xvdd]. Up 16.84 seconds
root@vm1-mso:/var/log# cat cloud-init-output.log
could be a proxy issue
root@vm1-mso:/var/log# ping nexus.onap.org
PING cloud.onap.org (199.204.45.137) 56(84) bytes of data.
64 bytes from compute-199-204-45-137.ca-ymq-1.vexxhost.net (199.204.45.137): icmp_seq=1 ttl=51 time=20.1 ms
2nd time around we are looking OK
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
nexus is experiencing periodic DNS issues - perhaps due to the redirect to cloud.onap.org
obrienbiometrics:onap michaelobrien$ dig nexus.onap.org
; <<>> DiG 9.8.3-P1 <<>> nexus.onap.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21803
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;nexus.onap.org. IN A
;; ANSWER SECTION:
nexus.onap.org. 3599 IN CNAME cloud.onap.org.
cloud.onap.org. 10799 IN A 199.204.45.137
;; Query time: 60 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Aug 5 00:00:59 2017
;; MSG SIZE rcvd: 68
Was the fact AAI in 1.1 needs a master gerrit_branch not the 1.0.0-RELEASE branch in the env templates (aai/test-config) was introduced post 1.0.0 on May 3
https://lf-onap.atlassian.net/browse/AAI-136
Checked history - was fixed on June 30 by Marco. My branch is from Aug 3rd though - so for some reason I was still seeing the openecomp folder instead of the renamed onap
docker moves from 1.0 to 1.1, dcae moves to 1.1, gerritt moves to master from 1.0
a pull fixed it
obrienbiometrics:demo michaelobrien$ git pull
Warning: Permanently added '[gerrit.openecomp.org]:29418,[198.145.29.92]:29418' (RSA) to the list of known hosts.
First, rewinding head to replay your work on top of it...
Fast-forwarded master to a94e309943d51a2d56e9aa19a582ac9eb40966e6.
This tree was removed after 20170804 - it is now onap not openecomp
https://gerrit.onap.org/r/gitweb?p=demo.git;a=tree;f=heat/OpenECOMP;hb=HEAD
use
https://gerrit.onap.org/r/gitweb?p=demo.git;a=tree;f=heat/ONAP;hb=master