Page Comparison

0

(given CLAMP is design time there is no point to adhere to L2 requirement) 

• Level 0: no performance testing done
• Level 1: baseline performance criteria identified and measured  (such as response time, transaction/message rate, latency, footprint, etc. to be defined on per component)
• Level 2: performance improvement plan created 
• Level 3: performance improvement plan implemented for 1 release (improvement measured for equivalent functionality & equivalent hardware)

minimum level for Dublin is 0 except for Control Loop projects. 

see Performance levels

• Level 0: none beyond release requirements
• Level 1: 72 hour component-level soak test (random test transactions with 80% code coverage; steady load)
• Level 2: 72 hour platform-level soak test (random test transactions with 80% code coverage; steady load)
• Level 3: track record over 6 months of reduced defect rate

minimum level for Dublin:2 

see Stability levels

1

(given CLAMP is design time there is no point to adhere to L2 requirement) 

• Level 0: no redundancy
• Level 1: support manual failure detection & rerouting or recovery within a single site; tested to complete in 30 minutes
• Level 2: support automated failure detection & rerouting 
  • within a single geographic site
  • stateless components: establish baseline measure of failed requests for a component failure within a site 
  • stateful components: establish baseline of data loss for a component failure within a site

• Level 3: support automated failover detection & rerouting 

  • across multiple sites 

  • stateless components 

    • improve on # of failed requests for component failure within a site 

    • establish baseline for failed requests for site failure 

  • stateful components 

    • improve on data loss metrics for component failure within a site 

    • establish baseline for data loss for site failure

Minimum Levels (Dublin)

• Runtime Projects: Level 2 (stretch goal Level 3)
  • NOTE: For Dublin, the building blocks will be put in place for Level 3 geo-redundancy, and a few projects will pilot it
• All other Projects: Level 1 (stretch goal Level 2)

see Resiliency Levels 

same as in Casablanca, not enough resource to allocate to this effort.

see Security Levels

• Level 0: no ability to scale
• Level 1: supports single site horizontal scale out and scale in, independent of other components
• Level 2: supports geographic scaling, independent of other components
• Level 3: support scaling (interoperability) across multiple ONAP instances

Minimum Levels (Dublin)

• Runtime Projects: Level 1 
  • NOTE: For Dublin, the building blocks will be put in place for Level 2 geographic scaling, and a few projects will pilot it
• All other Projects: Level 0 

see Scalability levels 

1

(2, if CLAMP can get more resource from the community)

• Level 1:
  • All ONAP components will use a single logging system.
  • Instantiation of a simple ONAP system should be accomplished in <1 hour with a minimal footprint
• Level 2:
  • A component can be independently upgraded without impacting operation interacting components
  • Component configuration to be externalized in a common fashion across ONAP projects
  • All application logging to adhere to ONAP Application Logging Specification v1.2
  • Implement guidelines for a minimal container footprint
• Level 3
  • Transaction tracing across components

Minimum Levels (Dublin)

• All Projects: Level 2
  • New projects should adhere to v1.2
  • Existing projects have stretch goal for v1.2
• Stretch Goal: Level 3 
• Note: some work will be done in Dublin to test/prep for a release upgrade strategy

see Manageability Levels 

1

(2, if CLAMP can get more resource from the community)

• Level 1:

  • • User guide created
    • Deployment documentation
    • API documentation
    • Adherence to coding guidelines
• Level 2:
  
  • API Documentation
    • • All new API’s must adhere to the ONAP API Common Versioning Strategy and Documentation Guidelines
      • All existing APIs must be documented in Swagger 2.0
• Level 3
  • • Consistent UI across ONAP projects
    • Usability testing conducted
    • API Documentation
      • All new API’s, all external APIs, and all existing API’s that are modified must adhere to the ONAP API Common Versioning Strategy and Documentation Guidelines
• Level 4
  
  • • API Documentation
      • All API’s for a given project must adhere to the ONAP API Common Versioning Strategy and Documentation Guidelines

  Minimum Levels (Dublin)

  • All Projects: Level 2
  • Stretch Goal: External APIs also follow the Versioning Strategy

  
  

• see Usability Levels