Open Stack

Hi Everyone,

Thanks for joining the service chaining project meeting on 6/18/2015. Here is the link to the meeting logs:
http://eavesdrop.openstack.org/meetings/service_chaining/2015/

A brief summary on today’s discussion:


1.      Update on repository creation

Repository has been created on OpenStack.  https://review.openstack.org/#/c/192820/  and https://review.openstack.org/#/c/188637/

            Neutron team has adopted this project.



2.      Finalize the SFC API

Continue collecting review comments and finalize it by next Wednesday, and we will start implementing the APIs



3.      Project management and core members

Cathy will manage the project and is currently running the IRC meetings and technical discussions.

Core members: Kyle Mestery, Armando, Cathy Zhang, Louis Fourie, Swami, Vikram, Nicolas, Mohankumar, Ramanjaneya, Brian, s3wong, Yuji


4.      Finalize the SFC project scope and functional module breakdown
Following is a summary of functional module breakdown and ownership sign-up (adding more people who have signed up as the contributors).
           We will be happy to see more people involved to get this in the direction that suits everybody and reaching us out publicly is best.

*         Integration with Neutron/devstack, CLI, Horizon, Heat------Mohankumar and Ramanjaneya

*         Neutron Service chain API Extension----- Cathy，LouisF

*         Flow Classifier API ---- LouisF，Vikram, Yuji, nbouthors

*         Service chain Plugin: API handling and Data Base----- LouisF, Cathy,Swami, s3wong

*         Service Chain Driver manager----Cathy, Brian

*         OVS Driver ----LouisF, Brian, s3wong

*         Flow Classifier on the data Path--- nbouthors_, Yuji

*         OVS with NSH encapsulation for verification of the OpenStack Service Chain API & Plugin functionality---LouisF, Swami,



5.      Deep dive into technical questions

*    Relationship with use case spec https://review.openstack.org/#/c/169201/

  Our API spec provides the Neutron level design and code to support the use case documented in the above link

*   Why do we need to add “encapsulation” context to the service chain API

   Our API needs to cover both service VMs that do not support new chain header and service VMs that support the new chain header. So the vSwitch  needs to be told which encapsulation format to use for communicating with the service function VMs. That is why we need this context parameter in the API which will be passed down to the vSwitch.



6.      Tentative time line for development of each module

           We will get the feedback from each piece owner about their timeline of completion in next IRC meeting



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150618/4a77b924/attachment.html>