...
- vCPE Use Case
- The vCPE team had a meeting with SDC and MSO teams the past week. As a result, MSO team suggests to change the current Heat templates in order to clearly separate Networks and VNFs.
- This separation represents a more realistic scenario, in which a VNF service (designed via SDC) uses a pre-existing network service from the catalog.
- Teams are discussing what MSO and SDN-C APIs to use, without adding new code at this stage of the project
- Reviewed VPP-based VNF development. The work is finishing up. A minor problem will be fixed soon, and the doc will be released this week.
- Communicated with DCAE to find that both the collector and analytics app have base code ready. Optimization work is ongoing.
- Reviewed workflow design and test with SO team. SO just updated the repo to v1.1, which is a major code merger. SO team did state that the workflow design and test is non-trivial. The team will have another session on this to understand if there is blocking issues and what could be the solution.
- The team has started M4 progress checking for each design and test item: vCPE Design and Test Cases
- VoLTE Use Case
- Finalized the design of networks between vEPC VNFs. Each VNF will have 3 ports for control, data and OM networks respectively. Common control network, data network and OM network will be shared by all VNFs
- Finalized the design of networks between vIMS VNFs, the network design is similar to vEPC VNFs.
- Agreed on DCI network which will use L3 VXLAN as overlay, and underlay remains to be the same of L3 VPN. Also WAN and SPTN will be tested separately during integration test.
- Reviewed A&AI scheme change to support network service instances
- VoLTE development tasks are tracked on VoLTE Use Case Development Tasks
- ONAP installation for Amsterdam release (OOM vs. Heat)
- Added a new CLAMP VM to the Heat stack, as per CLAMP team request.
- Installed ONAP via OOM multiple times in the WindRiver lab. There are issues due to resource limitation (the current VM cannot host more than one full ONAP instance)
- Health status of the ONAP platform doesn't seem dependent on the installation method.
...
- Release / O-Parent
- Independent Versioning and Release Process officially rolled out to the community
- JIRA tickets logged against all project for tracking
- A checklist item has been added to M4 and RCx checklist template
- ONAP Version Manifest Maven Plugin for checking dependency versions has been rolled out
- O-Parent has released two versions of artifacts so far; current version is 0.1.1
- Initial version of O-Parent for Python has been added
- Ongoing help to the community on Jenkins jobs, CSIT, O-Parent implementation
- Independent Versioning and Release Process officially rolled out to the community
- Developer Lab
- Had a meeting to scrub the bugs reported lately by integration team, and listed out top blocking issues.
- Tested ONAP1.1 branch. Created 6 new JIRA tickets