...
New projects proposal are posted here. These projects need to be reviewed and approved by TSC.
...
Non Functional Requirements | Owner | Sub-category | Project Impacted for Casablanca | Link(s) to High Level Design (HLD) /Low Level Design (LLD) (if any) | Dependency (from/to) another project(s) | T-Shirt Size (XS, S, M, L, XL)* | Project's Impact: Test Only (TO), Code (C) | Committed (C)/Partially Committed (P) or not (N) per Impacted projects | If Partially or not Committed, then what are the gaps per impacted project (people/FTEs; HLD/LLD; etc) | Company Engagement | Notes | M4 Status | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
S3P |
| Likely ALL depending upon TSC determination of new level requirements per category | Usability: New API’s adhere to Versioning strategy Versioning & API Documentation Recommendations Manageability: Adherence to ONAP Logging Spec v1.2 (implementation of the spec will occur in Dublin - Logging Dublin Scope) | Portal: on AAF, MUSIC, OOM VID, Policy, SDC, AAI: on Portal | Portal: XL | Portal: Code | Portal: Not Committed APPC: Partial DCAE: Partial SDC: committed VID: Partial (depends on Portal) AAI: Partial | APPC: Please refer to M1 Planning template for details DCAE: Refer to DCAE R3 M1 Release Planning#PlatformMaturity for details AAI: Please refer to AAI R3 Platform Maturity | Portal: IBM (only forAngularupgrade - shown interest, but not committed yet) | Portal: 1) Looking for resources who can help with adhering logging standards, API versioning and kubernetes deployment of Portal dockers. 2) Furthermore, Portal requires a security expert in addressing angular upgrade to address the Nexus-IQ reported vulnerability (the angular upgrade its self is XL t-shirt size task). | ||||||||||||||
Security | Note: This does not cover what is in S3P. However, based on that it is expected to have a certificate or use CADI to get certificates to enable secure communication Pluggable authentication and Authorization (Use of CADI and ?):
Secure communication toxNFs(Security for 5G Use cases). DCAE, APPC, VFC? VNF requirements. (Secure Communication to Network Functions)
Vnf package security following SOL 004: SDC, VNFreqs, VNF SDC | CADI/AAF Integration: | Portal: on AAF Test coverage (js): (1) js Sonar plug-ins activation (2) min. 3 additional containers per application => Jenkins enhancements (3) Maven build to be updated DMaaP on AAF DCAE on AAF, OOM,DMAAP OOF on AAF | Portal (CADI): M DCAE: XL SDC: L Test coverage (js): All: M/L | Portal: Code SDC: code VID: Code | Portal: Not Committed APPC: Partial OOF: Partial DCAE: Not Committed SDC: Partial VID: Partial (depends on Portal) AAI: Partial | APPC: Please refer to M1 Planning template for details DCAE: Refer to DCAE R3 M1 Release Planning#PlatformMaturity table for open issues/question with current proposal OOF: Please see OOF Casablanca M1 Release Planning Template SDC: because of the size of the sdc source code we will be able to reach only 10% unit test coverage on the Javascript. VNF package security missing information. AAI: Please refer to AAI R3 Platform Maturity | Portal: Looking for resources who understand the AAF based certificate management to upgrade using CADI client in Portal. OOF: Need more clarity on AAF support for python projects in Casablanca | ||||||||||||||||
Upgrade (from Beijing to Casablanca) | All: XL | APPC: Not Committed CLAMP: Not Committed DCAE: Not Committed SDC: not commited VID: Not Committed AAI: Not committed | APPC, CLAMP, Portal, SDC, DCAE, VID, AAI: Lack of resources require additional information (does it include rollback, retrofit, no impact on run-time, etc)? | |||||||||||||||||||||
Architecture Alignment |
|
| DCAE on DMAAP (for DR) | DCAE:XL | DCAE:Partial Commit (New service committed based on Ericsson/Nokia) SDC: partial MultiVIM: Committed External API: Committed SO: Partially committed A&AI: partially committed CCSDK: committed | DCAE: DDS-VES and new analytic platform (FLINK) not committed due to resource. xNF-DCAE authentication not committed due to open issue listed under security. SDC: policy designer not planned for Casablanca, ETSI compliance only sol004 is planed. PNF suport will be done ontop of the existing capabilities. RTC stretch goal. DCAE-DS committed. Flow designer committed. ExtAPI: Interlude is a stretch goal SO: "decomposition" committed; "service instantiation" stretch goal A&AI: abstract topology sync-up committed | Reviewed and accepted at M3 reviews | |||||||||||||||||
HEAT support | HEAT-based ONAP deployment support should be dropped once OOM-based ONAP deployment's issues are fully identified and resolved. Recommendation from TSC: keep supporting HEAT in Casablanca for testing and integration purposes. However, HEAT won't be a gating item at Release Sign-Off. | Portal: on OOM | Portal: S SDC:S | Portal: Code SDC: code | Portal: Not Committed APPC: Will support Heat partially OOF: Support HEAT for testing SDC:committed VID: Partially | Portal: See Risk #4 | Portal: Switching CSIT jobs from using HEAT based to OOM based requires resources who can understand the current setup. | |||||||||||||||||
Internationalization language support | Tao Shen |
|
Design language/internationalization component in Portal and provideserviceapistopartnering apps like Policy, VID, SDC, AAI Note: This will need to go through the whole process (Architecture review,...) to understand whatthesdk will be providing and dependenciesonother ONAP project (Portal, SDC,...) As per Lingli and Tao from chinamobile, this is reviewed and approved by Arch Team. | UsecaseUI: on Portal | Portal: L | Portal: Code | Portal: Partial APPC: Not Committed CLAMP: Not Committed SDC: Not committed VID: Not committed | Portal: Limited resources | Portal: AT&T, ChinaMobile | Portal: Policy, VID, SDC, AAI can choose to use this Internationalization feature based on their capacity. Only UsecaseUI team is committed to develop and use this feature for now in Casablanca. |
Due to lack of resource, this is postpone to Dublin Release | |||||||||||||
Testing |
| Most UI projects with javascript. Recommendation from TSC: This is related to Code Coverage: recommendation is to keep 50% Code Coverage for Casablanca including JavaScript. (In Beijing Release code coverage was only covering Java and Python code, not javascript) | Linux Foundation Unit test and CSIT coverage framework, Policy, VID, SDC, AAI: on Portal, DCAE (for JavaScript coverage) | Portal: XL SDC:S VID:S | Code: portal, SDC, VID | Portal: Partial (no Javascript) APPC: Partial, Java code will maintain 50%, no commitment for Javascript CLAMP: Partial, Java code will maintain 50%, no commitment for Javascript DCAE:Partial (except javascript) SDC: maintain 50% coverage for java and python add 10% coverage for UI(java script) VID: maintain 50% coverage for java add 10% coverage for UI (java script) AAI: Partial, Java code will maintain 50%, add 10% coverage for sparky (javascript) | Portal, APPC, CLAMP, DCAE: See Risk #1 | Portal: AT&T, IBM, TechM | ||||||||||||||||
modeling | Hui Deng | SDC: needs to support composite pattern in R3 SDC/SO/A&AI needs to support Service Order, Service Catalogue, service scaling Modeling runtime needs to be supported by A&AI in release 3 | SDC:not committed SO A&AI - changes to the run-time schema require significant refactoring in all of AAI's client applications. That refactoring might be planned and addressed in R4; for R3, perhaps mapping existing runtime schema to new model definitions can suffice? | SDC: late submission to the requirements for Casablanca, not clear on what are the requirements from sdc. |
...