...

Scope

What is this release trying to address?

The Casablanca Release will be focusing on the following areas:

• Upgrade to Karaf 4
• Upgrade of ODL to Oxygen (CCSDK dependency)
• Upgrade to Karaf 4
• Migrate DB to use Maria DB with Galera (CCSDK dependency)
• Platform Maturity (i.e., S3P items)
  • Resiliency
    • Address Level 2 - regression from Beijing, plug close gap on DB resiliency.
    • DB Resiliency , which was a limitation in Beijing due to the Active/Standby nature of MySQL. MariaDB w/Galera provides an active-active clustered configuration, which will support local fail-over.
  • Security
    
    • Address outstanding items related to CII Passing Badge, which includes:
      • Clearing all Critical and Medium Nexus IQ Security alerts
      • Addressing 2 other security related items from Passing Badge
  • Scalability
    • Level 1 will be a regression run on Casablanca release - anticipate this to be test only
  • Stability
    
    • Level 1 will be a regression run on Casablanca release - anticipate this to be test only
    • Level 2 requirement is expected to be covered by the Integration team.
    Scalability
  • Security
    
    • Level 1 will be a regression run on Casablanca release - anticipate this to be test only
  Support new LCM action Reboot and various other enhancements to existing LCM actions (Tracked under Epic: APPC-
  • • definition has changed in Casablanca. Not clear we are achieve Level 1
    • Address outstanding items related to CII Passing Badge:
      
      • Clearing Critical and Medium Nexus IQ Security alerts to the extent possible
      • Addressing 2 other security related items from Passing Badge related to encryption
    • Secure DMaaP topics (Dependency on DMaaP project) - Stretch Goal, not currently committed for Casablanca
      
      • DMaaP indicated delivery would be Sept, plus
      • DMaaP story is still not written to enable APPC to assess impact at this stage.
        

• Support new LCM action Reboot and various other enhancements to existing LCM actions (Tracked under Epic: APPC-899)
• Documentation updates for BeijingCasablanca, such as, but not limited to:
  
  • LCM API Guide
  • Release Notes
• Code Coverage for CDT (Javascript) - TBD, no commitment at this stage
  
• Use Cases

  Describe the use case this release is targeted for (better if reference to customer use case).

  The use cases supported in Beijing release will continue to be supported as part of regression assuming all other components do likewise.

  APPC contribute partially to the following use cases as part of the functional requirements.

  • Scaling Use Case - 
    
    • APPC will support retrieving the data to be configured from AAI. This however has a dependency on SO to provide the vnf_Id of the vDNS that was instantiated..
    • Discussions around how Controller Type will be handled are still to vague and unclear, so no commitment can be made to support this. APPC will continue to support APPC and SDNC via the Client Library as was done in Beijing.

  Minimum Viable Product

  Same as was defined for Beijing with the adding of CDT.

  Functionalities

  ...

  • • ConfigScaleOut - Partially supported
      
      • Support Retrieval of configuration data from AAI instead of having SO pass configuration data in payload - (investigate if we can we reuse the named query)
        • Dependency on SO to pass the vf-module-id of the vDNS instance that must be added.
          
      • No commitment on Controller Type since requirements are still unclear.
        
    • Change Management - No Commitment
    • 5G/PNF - No Commitment (although APPC is listed as an impacted component, there does not appear to be any immediate requirement for Casablanca. Items noted are longer road map items)
      

  Use Cases

  Describe the use case this release is targeted for (better if reference to customer use case).

  The use cases supported in Beijing release will continue to be supported as part of regression assuming all other components do likewise.

  APPC will contribute partially to the following use cases as part of the functional requirements.

  • Scaling Use Case - 
    
    • APPC will support retrieving the data to be configured from AAI. This however has a dependency on SO to  pass the vf-module-id of the vDNS that was instantiated..
    • Discussions around how Controller Type will be handled are still too vague and unclear, so no commitment can be made to support this. APPC will continue to support APPC and SDNC via the Client Library as was done in Beijing.

  Minimum Viable Product

  Same as was defined for Beijing with the adding of CDT.

  Functionalities

  List the functionalities that this release is committing to deliver by providing a link to JIRA Epics and Stories. In the JIRA Priority field, specify the priority (either High, Medium, Low). The priority will be used in case de-scoping is required. Don't assign High priority to all functionalities.

  ...

  Area	Actual Level	Targeted Level for current Release	How, Evidences	Comments
  Performance	0	0		0 -- none 1 – baseline performance criteria identified and measured 2 & 3 – performance improvement plans created & implemented
  Stability	1 - project team 2 - Integration team Integration team did a 72 hour test in Beijing	1 - project team 2 - Integration team Assume Integration team will address Level 2 -  72 hour test in Casablanca		0 – none 1 – 72 hours component level soak w/random transactions 2 – 72 hours platform level soak w/random transactions 3 – 6 months track record of reduced defect rate
  Resiliency	2	2 0 – none In Casablanca we will address Resiliency at the DB level since that was a constrain in Beijing. this will be possible with the move to Maria DB w/Galera		0 – none 1 – manual failure and recovery (< 30 minutes) 2 – automated detection and recovery (single site) 3 – automated detection and recovery (geo redundancy)
  Security	1	1? Level 1 definitions in Casablanca where changed.		0 – none 1 – CII Passing badge + 50% Test Coverage 2 – CII Silver badge; internal communication encrypted; role-based access control and authorization for all calls 3 – CII Gold
  Scalability	1	1		0 – no ability to scale 1 – single site horizontal scaling 2 – geographic scaling 3 – scaling across multiple ONAP instances
  Manageability	1	1 1 – single logging system across components; instantiation in Recommendation for Casablanca is Level 2; however, Level 2 requirements are unclear and cannot be committed to.		1 – single logging system across components; instantiation in < 1 hour 2 – ability to upgrade a single component; tracing across components; externalized configuration management
  Usability	1	1	1 – user guide; deployment documentation; API documentation 2 – UI consistency; usability testing; tutorial documentation

  • API Incoming Dependencies

  ...

  For Level 2 All new API’s must adhere to the ONAP API Common Versioning Strategy and Documentation Guidelines;  ?? Does this apply to Reboot? Swagger 2.0? - dependent on what Oxygen supports E2E tutorial ???

  1 – user guide; deployment documentation; API documentation 2 – UI consistency; usability testing; tutorial documentation

  
  

  • API Incoming Dependencies

  List the API this project is expecting from other projects.
  Prior to Release Planning review, Team Leads must agreed on the date by which the API will be fully defined. The API Delivery date must not be later than the release API Freeze date.

  ...

  	API Description	API Definition Date	API Delivery date	API Definition link (i.e.swagger)
  SDC	REST API	Currently Available, but needs to be updated to use onap.org	TBD	Link toward the detailed API description
  AAI	REST API	Currently Available Currently Available Needs further discussion: New Customer query to retrieve data for ScaleOut or does APPC need to build the query??	TBD
  CCSDK	OpenDayLight, SLI, AAI Client, dblib	TBD	TBD
  DMaaP	API  to publish/subscribe to  events sent for VNF/VM action requests.	Currently Available	Currently AvailableWill DMaaP be providing support for secure topics?	TBD	DMaaP API
  AAF	Application Authorization Framework	Currently Available	Currently Available

  ...

  	Description	Version
  ODL	OpenDaylight controller platform	NitrogenOxygen
  Docker	Docker container host	1.12
  MariaDB	data base container	TBD

  ...

  • CSIT tests added as part of R1 will continue to be supported in R3
  • Pairwise testing will be done in the WindRiver Dev lab similar to what was done in R2R3.
  • Epics are created to track testing activities to address Platform Maturity items.

  ...

  Jira Legacy
  server System Jira columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery project=sanbox appc and issuetype in (bug) and affectedVersion = "Beijing Release" AND fixVersion = "Casablanca Release" serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176

  ...

  Risk identified	Mitigation Plan	Contingency Plan
  To fill out	To fill out	To fill out

  • Resources

  Fill out the Resources Committed to the Release centralized page.

  • Release Milestone

  The milestones are defined at the Release Level and all the supporting project agreed to comply with these dates.

  • Team Internal Milestone

  This section is optional and may be used to document internal milestones within a project team or multiple project teams. For instance, in the case the team has made agreement with other team to deliver some artifacts on a certain date that are not in the release milestone, it is erecommended to provide these agreements and dates in this section.

  It is not expected to have a detailed project plan.

  Date	ODL upgrade to Oxygen & DB to MariaDB - depends on CCSDK projects	CCSDK team has started work early on these two dependencies; They are currently telling us they plant o have these ready at start of Casablanca.	Fall back to Nitrogen & MySQL (same as Beijing)
  SO dependency to delivery needed data to support the ScaleOut use case?
  DMaaP support of Secure Topics?

  • Resources

  Fill out the Resources Committed to the Release centralized page.

  • Release Milestone

  The milestones are defined at the Release Level and all the supporting project agreed to comply with these dates.

  • Team Internal Milestone

  This section is optional and may be used to document internal milestones within a project team or multiple project teams. For instance, in the case the team has made agreement with other team to deliver some artifacts on a certain date that are not in the release milestone, it is erecommended to provide these agreements and dates in this section.

  It is not expected to have a detailed project plan.

  Date	Project	Deliverable
  To fill out	To fill out	To fill out

  ...

  Note
  title Note
  The Documentation project will provide the Documentation Tool Chain to edit, configure, store and publish all Documentation asset.

  ...

  
  

  Documentation updates planned for Beijing release are tracked under Documentation Epic: APPC-993

  
  Other Information

  • Vendor Neutral

  ...

  The project team comply with the ONAP Charter.

  ...