PMSH and PM-Mapper enhancements

Commitment based on Ericsson

VESCollector + platform/deployment support via config-map

Commitment based on Nokia 

MOD updates 
- Nifi backlog reduction
- New MOD UI/catalog (POC)

Commitment based on AT&T

DCAE Platform (k8splugin, CM/Bootstrap)
Component_spec + Bp-gen
MOD component
OOM revision

Commitment based on Nokia, AT&T

K8splugin change to support k8s 1.17+  

Commitment based on Nokia

Add explicit references to dockerhub or nexus to all images  

Commitment based on Samsung, AT&T

HIGH RISK -

Approved base images list NOT CONFIRMED + MULTIPLE DCAE COMPONENT

IMPACT  (RISK#5- Guilin Risks)

• Approved base image for NodeJS TBC

• Need exception for some DCAE components (Cloudify, MOD) due to upstream dependency
• Need resource/community support due to number of impact component 

Commitment : AT&T, Nokia, Ericsson, Wipro,  ChinaMobile

Per TSC 2.7->3.8 important; 3.7-3.8 (nice to have) 

Except Cloudify and SNMPTrap - all other DCAE components will be migrated to 3.8. SECCOM approved exception on 7/3 (refer jira)

Commitment based on T-Mobile

MEDIUM RISK - Need further assessment on DCAE components

impacted (RISK#6 Guilin Risks)

Commitment based on Ericsson

MEDIUM RISK - Need further assessment on DCAE components

impacted  (RISK#6 Guilin Risks)

Exception required for Cloudify due to upstream dependency. 

Commitment based on Ericsson

Need to be create DCAE jira if OOM team support is confirmed  (may just need to update your tests to use urls instead of IPs)

Impact : DCAE Platfrom helm charts + DCAE Service components deployment (k8splugin for nodeport mapping) + DCAE services dependent on nodeport/API

Resource TBD

1) Evaluate certInitializer integration impact for DCAE-tls init container
2) Possible impact to K8s plugin  (Need more discussion)

Hardcoded pasword impact : 

Cloudify +

 Bootstrap, DH, Dashboard (

to be changed to use secret) 

Commitment based on Orange/Samsung/AT&T

Okay for service components (as CBS is used); Platform component should be okay. MOD - to be verified (possibly MOD/Nifi container) + Dashboard

Need further assesment.  Current list of component impact -  Dashboard/Inventory/TCA-gen2/heartbeat/PM-Mapper/DL-feed/Son-handler

Commitment based on WIPRO

/ChinaMobile

MEDIUM RISK : Due to number of DCAE components impacted.  (RISK#7 Guilin Risks)

• Some MOD components will need exception (due to NiFI upstream dependency)

• VES-Mapper/RESTConf  - Resource TBC 

Commitment : AT&T, Nokia, Ericsson, Wipro,  ChinaMobile

Already complaint for Frankfurt components; new component/enhancement to adhere

Commitment :

 AT&T, Nokia, Ericsson, Wipro,  ChinaMobile

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

2

• 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

• • 0 – none
  • 1 – manual failure and recovery (< 30 minutes)
  • 2 – automated detection and recovery (single site)
  • 3 – automated detection and recovery (geo redundancy)

1+  (Most DCAE components are complaint; will address remaining in Guilin based on resource availability)

• Level 0: None
• Level 1: CII Passing badge
  • Including no critical and high known vulnerabilities > 60 days old
• 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.
• Level 3: CII Gold badge 

1

• 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

1+  (Except logging, all other requirements are met)

• 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

1+

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