#opnfv-copper: Copper Weekly Meeting

Meeting summary

1. 1. Bryan Sullivan (bryan_att, 15:05:03)
   2. Prakash Kanthi (bryan_att, 15:05:14)
   3. Prakash Kanthi (Prakash_DataTap, 15:05:14)
   4. OK, here is a quick summary of status (bryan_att, 15:05:45)
   5. the 19th call was cancelled and I sent an email (bryan_att, 15:06:08)
   6. The latest docs build was completed and is now linked to the wiki (bryan_att, 15:06:38)
   7. https://wiki.opnfv.org/copper (bryan_att, 15:06:58)
   8. see "Current working draft of use cases, architecture, and requirements analysis" (bryan_att, 15:07:18)
   9. http://artifacts.opnfv.org/copper/design_docs/index.html (bryan_att, 15:07:51)
   10. I will move contend from the wiki into the doc as the work progresses (bryan_att, 15:08:13)
   11. Anyone can propose additional content in the doc - there is still significant analysis to do on the config requirements capabilities of various VIMs (bryan_att, 15:09:44)
   12. e.g. as they use Heat, flavors, Nova scheduler hints, MD-SAL, etc (bryan_att, 15:10:30)
   13. What I plan to do is develop a use case demo and implement the various resource requirements as model data (e.g. TOSCA) or test driver code that exercise existing OpenStack and ODL etc functionality (bryan_att, 15:11:50)
   14. The first step is still though getting a lab off the ground and I am working with Spirent to do that in their vctlab environment (bryan_att, 15:12:31)
   15. Nothing more to share at the moment except perhaps some sense of the project planning for B release (bryan_att, 15:12:53)
   16. Tacker has a means to specify the TOSCA templates that Heat can understand and have the ability to hook in a mgmt and monitoring driver. (Prakash_DataTap, 15:13:41)
   17. Do you see that as a viable part of the demo? (Prakash_DataTap, 15:13:58)
   18. Yes, that will be part of it. Any work to create an example, e.g. using a Tacker standalone environment, would be helpful (bryan_att, 15:14:52)
   19. For example, take a simple use case and describe how the TOSCA template would look (bryan_att, 15:15:23)
   20. One advantage I see with this is, all the VNFs can be instructed on what mgmt/monitoring drivers find out when policies are breached (Prakash_DataTap, 15:15:33)
   21. Sure, I can try building TOSCA templates for the UseCases you can add to this list. (Prakash_DataTap, 15:16:15)
   22. Tacker drivers can detect the policy breaches (Prakash_DataTap, 15:16:41)
   23. As Tacker can also communicate with other VNFs, we will have that feedback loop open, if needed (Prakash_DataTap, 15:17:13)
   24. A simple use case is a web server behind a firewall, with a cache between it and the firewall. (bryan_att, 15:17:19)
   25. agree (Prakash_DataTap, 15:17:52)
   26. It would be good to describe in the design doc how Tacker can detect policy breaches (bryan_att, 15:18:03)
   27. I can take up that task (Prakash_DataTap, 15:18:26)
   28. e.g. in the requirements section (bryan_att, 15:18:59)
   29. http://artifacts.opnfv.org/copper/design_docs/requirements.html (bryan_att, 15:19:02)
   30. there is a description of how various components can be used to implement the requirements (bryan_att, 15:19:22)
   31. in the process of describing and validating the solutions we will uncover gaps (bryan_att, 15:20:02)
   32. or in the best case end us with a clear description of how the Copper goals can be achieved today with existing components (bryan_att, 15:20:41)
   33. So put any proposed changes in using git and I will review them in gerrit (bryan_att, 15:21:11)
   34. agree (Prakash_DataTap, 15:21:13)
   
   
2. AOB (bryan_att, 15:21:25)
   1. nope, i will review the UseCases. Thanks (Prakash_DataTap, 15:22:14)

Action items

1. (none)

People present (lines said)

1. bryan_att (32)
2. Prakash_DataTap (11)
3. collabot (3)