...
International numbers available: https://zoom.us/zoomconference?m=viiAIbYha1FHOg4qZy9wY3LoQsy9Ut2P
Meeting Attendees
- Brian Hedstrom
- Lianhao Lu
- Andrei Kojukhov
- Takamune Cho (App-C)
- Tina Tsou
- David Shadmi
- Alexander Vul
- Andy Mayer
- Paul Miller (AT&T)
Meeting Agenda & Minutes
Agenda Items | Notes | ||||||||
---|---|---|---|---|---|---|---|---|---|
Logistics
| |||||||||
ONAP Developers Event Overview
| Items to be discussed and/or resolved: Should VNF SDK project take over the License Builder User Interface currently in SDC Once SDC on-boards the VNF, the VNFD should not be modified with SP extensions. This can be added as meta-data. (Alex & Andrei) Has the VVP project agreed to take on the new VEVP functionality? This needs discussed within the project team for R2. How does APP-C integrate with SDC? (Paul) How can vendors add data such as Ansible playbooks/Chef Cookbooks (and APP-C Template). Should APP-C integrate with VVP (VEVP) to accomplish this? Testing needs to be done for this. You need an ONAP Self Serve test environment. The APP-C UI is used to configure the playbook. This should be part of SDC as part of the design studio. Are these playbooks part of the VNF Package placed in the Marketplace? Alex mentioned a white paper written on this topic using NETCONF/YANG as a case study for VNF configuration/testing. Need to specify what artifacts we are supporting. Security needs to be concern around trusted sources (VNF itself and for Ansible Server). AT&T did a security risk assessment, and raised some items. Should these be brought to the Security Subcommittee? Who covers Ansible within the boundaries of ONAP? Start with Jason Hunt and new Software Architecture sub-team. Alex raised the concern that TOSCA (templates, simple YAML 1.2) items need resolved ASAP. How can we reuse the Amsterdam code for validation? We need to make sure we have the right things in the Info Model. This needs nailed down by Jan 8. We need to schedule a meeting between SDC, VVP and VNFSDK. First week of January? | ||||||||
| Notes from last meeting: Chris presenting the current R2 feature set. Sonar will be used to measure the code quality and code coverage for Java source code. Wenyao: Feature/Function Testing as a sub-project in R2. We brought the framework in from Open-O. Is this the test framework for a VNF? There is a robot framework. It can inject some data. Functional testing of VNFs should not be in scope (Brian). Andrei believes ONAP should do some level of non-functional testing, but in a separate project such as VVP. Andrei: Should we start creating a user story based on what we described as basics security features of ETSI SOL004 in our backlog? Discussion happened around VNF inside versus outside testing (e.g., internal/inside testing of virus checking). Some VNFs will be encrypted. Alex would like to add this item: VNF Templates built to describe VNFs. Could use what SDC was using. Enhance it with the 1.1/1.2 YAML grammar. We should explicitly invite ALL VNF Suppliers to review the project scope and features for R2. Team agrees with the 5 items listed on the R2 planning page. See action items below. Not discussed | ||||||||
Review open action items from last week | VES Collector R2 Resource Needs: VM needs 2 or more CPUs, 2-4 GB RAM, 50 GB HDD. | ||||||||
Combined Overview (what/how) Session for December Developer Forum (Chris Donley and Lianhao Lu)
| Check latest schedule. Alex has an afternoon session for VNF homing/placing. | ||||||||
Both items assigned to Chris. Not discussed | |||||||||
Not discussed | |||||||||
Kubernetes 1.9.0 released last week - stay on 1.8.6 (Michael O'Brien) | https://lists.onap.org/pipermail/onap-discuss/2017-December/007038.html ONAP on Kubernetes#InstallKubectl https://github.com/kubernetes/kubernetes/issues/57528
Not discussed |
Meeting Recording
- Video Recording:
- Audio Only Recording:
Action Items
- Chris Donley will update the R2 Mission statement to define value for both VNF Suppliers and Operators using ONAP. Chris Donley will update the VNF SDK Resources needs to include the VES collector.