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



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to