ONAP Beijing Release Developer Forum

Development at ONAP occurs on the master branch. The ONAP project is therefore in need of an automated end-to-end integration sanity to declare a particular tagged build sane and working at some defined level of functionality. This tagged build would represent a snapshot of war/jar artifacts and docker images - usually a nightly or commit triggered tag. Automatically determining the status of the master master branch can be accomplished by running a continuous deployment framework after CI finishes and builds the artifacts in response to a git merge trigger callback. This presentation will go over a particular implementation of a short regression test (as opposed to a full long regression) - that exercises an extended health check and the automated subset of the vFirewall use case demo to mark a particular tagged build as good. Developers can then consume the build/pull and update their environments with only builds marked as OK (a TBD level). This CD job can also verify that a commit did not break integration with other components - as much as the sanity can provide maximum spanning coverage for. The presentation will run from triggered Jenkins jobs that deploy for example an Amazon AWS EC2 spot VM, deploy OOM, run health and the vFirewall, collect logs/results and tear down the temporary VM. The process from the Jenkins artifact creation trigger to VM teardown is between 20-60 min per trigger - depending on docker image preload. A combination of several pre-recordings and parallel live/background demos will compress the actual time to demonstrate ONAP CD in several passes. Northbound clients like the OPNFV Auto project and CNCF can also mark builds as ready to work with by subscribing to the CD result stream. In summary: Automatically deploy ONAP OOM based on git submission artifact generation Run extended healthcheck and automated parts of vFirewall E2E sanity use case Report back on whether specific tag (code, artifacts, docker image repos) is sane and ready for developer and northbound (CNCF, OPNFV) consumption By default tear down OOM deployment after testing - or keep a rolling set - up for testing, or provide saved tagged AMI for later reproduction The CD deploy will - depending on commit/merge load test 1 or more merges per CD job See redeploy sh script on https://jira.onap.org/browse/INT-120, https://jira.onap.org/browse/OOM-150 - Deployment Integration Jenkins job using OOM-K8S - to validate branch Rotating live deployments in a public lab on AWS EC2 Feeds directly into the development process, could show benefits vs Docker Compose/Vagrant Discuss https://jira.onap.org/browse/OOM-357 - CNCF CrossCloud Deployment/CI Integration with ONAP Discuss https://wiki.onap.org/display/DW/OPNFV+Integration - OPNFV Northbound client integration with ONAP Discuss results of OPNFV Plugfest - https://wiki.opnfv.org/display/EVNT/Plugfest+Planning+Page 1 week before our F2F See prototype on https://wiki.onap.org/display/DW/ONAP+on+Amazon+EC2 See Tracking Wiki at https://wiki.onap.org/display/DW/ONAP+on+Kubernetes See Tracking JIRA at https://jira.onap.org/browse/OOM-393 and https://jira.onap.org/browse/INT-120 Recommended Prerequisites: "An Introduction to the ONAP Operations Manager (OOM)" "Deploy ONAP/OOM on any Environment" Recommended Follow Up Presentations: "ONAP/OOM for Developers"