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
https://wiki.onap.org/display/DW/Database%2C+Java%2C+Python%2C+Docker%2C+Kubernetes%2C+and+Image+Versions
1) 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 impacted (RISK#6 Guilin Risks)

Commitment based on Ericsson

MEDIUM RISK - Need further assessment on DCAE components impacted 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 (can be fixed - https://wiki.web.att.com/pages/viewpage.action?spaceKey=ECOMPC&title=Cloudify+Manager+patches+and+fixes) +pasword impact :  Cloudify + Bootstrap, DH, Dashboard (can 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. VES-Mapper/RESTConf  - TBC  (RISK#7 Guilin Risks)

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

Commitment : Multiple companies

• dependency)
• VES-Mapper/RESTConf  - Resource TBC 

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

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

Commitment : Multiple companies 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