Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

Purpose

This template is to be used for the “Parallel Deep Dive Sessions to Align with architecture / Use cases” at the may ONAP developers event

Instructions.

The purpose of each section is to translate the use cases and functional architecture into specific identified needs for the components, and to identify potential projects to be proposed.  There are three parts to this exercise:

  1. Identify needs based on the use case and architecture on this module, and potential dependencies on other modules or external artifacts.
  2. Group these into projects.  Consider that coding, documentation, and testing is required.   Include an initial scope for the project.
  3. If time, mapping the needs into the projects.

The need identification table has the following columns

-          Identified need: <slogan for the identified need>

-          Brief need description: <a few sentences describing the need>

-          Driver:<Related use case or architecture change, if any>

-          Dependencies:<identify dependencies on other modules or artifacts (e.g. other onap module, models, …)

-          Project: <If time, after the projects are identified, suggest in which project the need would best fit>

Time keeping suggestion:  The exercise time is 45 minutes.  A good practice would be to split into 20 minutes on need identification and 20 minutes on project proposals.

Exercise output.

ONAP Meeting Session name: integration

Need Identification:

Identified Need

Description

Driver

Dependencies

Project fit
(if time)

Test Suite

robot test suites executed

Consumer driven/broker driven testing framework




Jenkins Job Flow



AutoreleaseTrigger daily autorelease job to build all projects together from source


TemplateTemplates for test suites



Project proposals.

Project 1:

Project ID: integration

Project Name:

-          System Integration and Testing

Project Description

  • Responsible for ONAP cross-projects system integration and all related testing, such as VNF compliant & verification testing, necessary for the successful delivery and industry adaption of the ONAP project as a whole. 
  • Provide integration tools and processes for CI/CD of source master and release branches
  • Consolidation of common test suites

Scope:

  • Provides all the cross-project infrastructure framework and DevOp toolchain, code and scripts, best practice guidance and benchmark, testing reports and white paper related to:
    • Cross projects Continuous System Integration Testing (CSIT)
    • VNF compliant and verification testing leveraging ONAP projects
    • Release delivering of the ONAP project
    • PoC: building and maintenance community integration labs
    • Continuous Distribution (CD) to ONAP community integration labs

Other:

-          Identify baseline code (if any)



Meeting Notes:

#info helen says presents Slidedeck: System Integration and Testing

#info helen says integration team is a helper project.  Not have authority to be gatekeeper.

#info we use necus, docker, slack, bitgeria, swagger

#info helen says for open-o, created many test cases

#info helen says we use test suites robot framework

#info helen shares jenkins job flow

#info danials says this looks like they are complimentary to existing in ECOMP/ONAP with end-to-end testing

#info helen says that for each project, they will create their own CSIT test suite 

#question will there be docker level test?  looking at the docker logs

  • We have the base infrastructure for it.  We do not scan the logs for strings.  The robot test framework will check against the signature of the api call.

#question will there be dynamic testing?

  • We trigger unit level testing triggered automatically by Jenkins at build time

#question In the microsservice, the broker based testing is getting more popular.  

  • consumer driven, broker driven

#question who builds the test?

  • the developer will write the test and the integration team provides the framework, but it will be up to individual projects

#question do we test both expected and unexpected inputs

  • We should test both.

#question can we consider a consolidation of the test?

  • That's the goal of the common integration.

#question do we have a way to leverage localize test environments

  • Requires additional work with LF

#question Can we have test templates

  • That is a good suggestion

#question We need a project to address security concerns

  • The TSC needs to own that and create a committee for that






  • No labels