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 99 Next »

This table summarizes the plan in regard to support of "Platform Maturity" for each project in Beijing Release. The data below are extracted from each project plan.

The Platform Maturity recommendations are documented in "Platform Maturity Status" from djhunt

Legend

Color code:

Yellow: same maturity.

Green: improved maturity level.

Red: below maturity level



AREA

Design / Run-Time

Performance

Stability

Resiliency

Security

Scalability

Manageability

Usability

Min TSC Recommendations

Min Runtime: 1

Min Remaining: 0

Min all projects: 1

Min Runtime: 2

Min Remaining: 1

Min all projects: 1

Min Runtime: 1

Min Remaining: 0

Min all projects: 1
Min all projects: 1
Project Name
ActualTargetM4 resultActualTargetM4 resultActualTargetM4 resultActualTargetM4 resultActualTargetM4 resultActualTargetM4 resultActualTargetM4 result
A&AIR01

WIP

Note 11

01

WIP

Note 11

12201

 WIP

Note 10

011111111
Application Authorization FrameworkR01

WIP

Note 11

01

WIP

Note 11

12

WIP

Note 11

01

0

Note 16

01

0

Note 11

111111
APPCR00001

1

Note 12

1

2



01

WIP

Note 13

11

1

Note 14

111111
CLAMPD000011111011111111111
Common Controller SDKR0000

NA

Note 2

NA

Note

2

12

2

01

WIP

Note 18

0

NA

Note 3

NA

Note 3

111111
DCAER11112WIP1

2

Note 1

201WIP01101111WIP
DMaaPR0

1


WIP

Note7

11

WIP

Note7

22201

WIP

Note8


11111112

WIP

Note9

DocumentationNAOversee documentation from all other projects that support their maturity commitments12
External API FrameworkR000000000010000000000
HolmesR01WIP01WIP02101

WIP

Note 19

01

1

Note 20

01

1

Note 20

111

Integration

NAIntegration Team will perform overall E2E  testing with the 4 use cases.
Logging Enhancements Project R00
11
2

2

Note 4


00
11
11
01

WIP

Note 17

Microservices BusR01
01
12
01Note1511
11
11
ModelingD01
11
12
01
01
01
11
Multi VIM/CloudR01
01
12
01
11
01
22
MUSICR11
11
12
22
01
11
11
ONAP CLID & R01
01
12
01
11
11
12
ONAP Operations ManagerR11
01
12
11
01
01
11
ONAP Optimization FrameworkR01

WIP

Note 11

01

WIP

Note 11

12WIP01101WIP01WIP11WIP
ONAP Usecase UI Project ProposalD01
01
12
01
00
01
11
Policy Framework Project ProposalD & R11No work done11

No work done

12WIP11101WIP11WIP11WIP
Portal Platform Project ProposalD & R01
11
12
01
01
11
12
SDN-CR00001

WIP

12201WIP Note 18011111111
Service Design & CreationD00No work done01WIP11No work done01WIP00No work done0

0

Note 5

WIP01WIP
Service OrchestratorR01
01
12
01
01
01
01
VFCR01
01
1220110

1(*)

Note 6


01WIP111
VIDR01
01
12
01
01
0

0

Note 5


11
VNF SDKD000111111011000111111
VNF RequirementsNANA. VNFRQTS is primarily a documentation project and does not deliver ONAP platform code1

VNF Validation (VVP)D




















Note 1: For DCAE the plan is to meet level 2 for DCAE components that can be made into docker containers, but for those components that cannot, it will depend on upstream providers (i.e. Cloudify Manager and CDAP). During M1 review, TSC agree with level 2 ok with exception granted for cloudify

Note 2: For CCSDK, as a project that provides a library framework, CCSDK has no standalone component that can be soaked

Note 3: Scaling does not apply to CCSDK itself, as a set of libraries.

Note 4: LOG: standard OOB OOM Kubernetes resilience/stability

Note 5: SDC and VID. For Manageability, instantiation in < 1 hour is already supported. No plan to support single loging in Beijing.

Note 6: Due to lack of resources, VF-C may not achieve scalability level 1 for all components in this release and plans to support scalability level 1 for part of  components first.

Note 7: 72 hrs. Soak test completed for Message router and in progress for Bus controller.

Note 8: We reached 50% code coverage for Message Router. Code coverage for Bus controller is in progress.

Note 9: Documentation is completed for Message router, in progress for Bus controller.

Note 10: AAI hasn't cleared vulnerable dependencies and won't be clear before M4 but we have a plan to have them clear by release

Note 11: Performance and scalability tests will be performed during integration testing

Note 12: 72 hour soak test completed on Amsterdam code base due to defect APPC-658 which prevents DMaaP messages from being received or sent.  Test results and notes can be found at:  ONAP APPC 72 Hour Stability Test Results. Once DMaaP issue is resolved on Beijing, we will re-run 72 hour soak test.

Note 13: CII Passing is 95%; Code Coverage is at 48.2% and progressing; however, not likely to meet 50% by 3/29.

Note 14: APPC component is fully scalable via approach of using Kubernetes, APPC instances (N+) can be added to the cluster; however, due to constraints encountered with MySQL DB, the DB is not scalable until we migrate to MariaDB plus Galera (planned for Casablanca per feedback from CCSDK), which would provide the active-active architecture. Further details are tracked under OOM project (OOM-733), who we've been working with. 

Note 14: MSB CII Badge progress is 98% ; the main challenge for us is to fix all the security issues above level 4, we're still working on that. The coverage is already above 50%.

Note 16: AAF latest code set supports certificate manager and  OAuth. Need to test the security during integration testing

Note 17: logging spec page being finalized with mostly AT&T - spawned a Casablanca spec moving forward

Note 18: Remaining security vulnerabilities in CCSDK are due to library versions delivered in OpenDaylight Nitrogen release.  These cannot be cleared without breaking OpenDaylight platform.

Note 19: The current status of  Holmes CII Badge progress is 98%. There's still one severe problem unsolved. But it seem to be a false positive. Details could be found at Holmes Security/Vulnerability Threat Impact Analysis. Now we are still working on the issues ranked above L4.

Note 20: Holmes itself has implemented all the functionalities regarding scaling and logging. Now we are still working with the DCAE team for integration.

Note 21: Remaining security vulnerabilities in SDNC are due to versions delivered in base platforms (OpenDaylight Nitrogen and NodeRed).  These need to be cleared in these dependent projects and then SDNC will use updated version of base platforms.

  • No labels