Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The intention of this page is to highlight differences between the Platform Maturity requirements for data router Casablanca and Dublin releases.

...

Stability

Similar 72 hour component-level soak test done for Casablanca release.

Guidance for Implementation

Please see Casablanca Stability Testing Instructions

Area

Target Level for Casablanca Release

Target Level for Dublin Release

Change required. (details below)

Comments
Performance

1

2
  • Create performance improvement plan.

Performance test results for Casablanca here: Platform maturity: performance/stability test plan.

Identify bottlenecks as a start for improvement plan.


Estimation:

  • Improvement plan: 1
2
  • 72 hour platform-level soak test (random test transactions with 80% code coverage; steady load)
Resiliency22

N/A

  • -2 days of work.
Security1

2

Project level requirements

  • Level 2: CII Silver badge, plus:
    • All internal/external system communications shall be able to be encrypted.
    • All internal/external service calls shall have common role-based access control and authorization using CADI framework.

ONAP Platform-level requirements per release 

Level 2: 70 % of the projects passing silver 

  • with non-silver projects:
    •  completed passing level and 80% towards silver level
    • internal/external system communications shall be able to be encrypted

Encryption not implemented for:

  • InternalServlet (isAuthorizedForInternal)
  • RouteServlet (isAuthorizedForInternal)
  • PublishServlet
  • StatisticsServlet
  • LogServlet

Access control/authorization not implemented.

CII Silver badge

The project MUST document what the user can and cannot expect in terms of security from the software produced
by the project. The project MUST identify the security requirements that the software is intended to meet and an
assurance case that justifies why these requirements are met.

CII Badging Program

Currently DR on Passing level.

Data Router (DR) API Guide

Scalability11

N/A


Estimation:

  • Encryption: 2-3 days of work. (Fairly repetitive work. update classes
    • InternalServlet (isAuthorizedForInternal)
    • RouteServlet (isAuthorizedForInternal)
    • PublishServlet
    • StatisticsServlet
    • LogServlet
    )
  • Role-based access: 1 sprint
Manageability12
  • 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

Currently implemented:

  • SLF4J Log4J (to log events and internal logging) and
  • EELF (for logging API calls) .

Considering eelf is one of the suggested logging frameworks for the spec, and we have nothing implemented for slf4j, we should ideally use only eelf for our logging purposes and replace any log4j logging with eelf


Guidance for Implementation

Usability1

2


API versioning already in place.

Implementing Semantic Versioning for APIs

  • Utilizes the same semantic versioning methodology that is being used for ONAP’s Release Versioning Strategy; therefore, development teams are familiar with the definition of the methodology.
  • For a given a version number, MAJOR.MINOR.PATCH, increment the:
    • MAJOR position when you make any incompatible API change
    • MINOR position when you add functionality in a backwards-compatible manner
    • PATCH (or BUILD) position when you make invisible (and thus backwards-compatible) bug fixes
  • Details of the specification can be found at http://semver.org/

Update classes with Swagger annotations.

Guidance for Implementation

  • This presentation gives a good review of what types of documentation should be done and when in the release lifecycle.
  • Please see the Documentation team for more information.

    Estimation:

    • Use one Logging system: 5 days of work (35 files to update x several line each)
    • Logging to adhere to ONAP Application Logging Specification v1.2: two MDCs implemented (RequestId and InvocationId.
      Nine more to be implemented:

    InstanceID
    ServiceName
    PartnerName
    StatusCode
    ResponseCode
    ResponseDesc
    Severity
    ServerFQDN
    ClientIPAddress)

    Update the format of the logging to conform to v1.2 spec.

    Some additional work required to provide log data to Audit Log and Metric Log. 1 sprint of work.

    • Implement guidelines for a minimal container footprint: 1-2 days
    • Component configuration to be externalized: 1-2 days


    More information on the levels: Platform Maturity Requirements





    Performance

    • 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)

    ...

    • 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

    ...

    ...

      • Consistent UI across ONAP projects
      • Usability testing conducted
      • API Documentation
    • Level 4

    ...