Neutron/CommonFlowClassifier
Contents
- 1 IRC Discussion Meeting Information
- 2 Meetings
- 2.1 Discussion Topic NEXT
- 2.2 Discussion Topic 28 February 2017
- 2.3 Discussion Topic 14 February 2017
- 2.4 Discussion Topic 17 January 2017
- 2.5 Discussion Topic 6 December 2016
- 2.6 Discussion Topic 22 November 2016
- 2.7 Discussion Topic 11 October 2016
- 2.8 Discussion Topic 27 September 2016
- 2.9 Discussion Topic 5 July 2016
- 2.10 Discussion Topic 14 June 2016
- 2.11 Discussion Topic 17 May 2016
- 3 Meet-up Discussion Notes
- 4 Overview
- 5 Contributors
IRC Discussion Meeting Information
Every two weeks (on odd weeks) on Tuesday at 1700 UTC in #openstack-meeting.
Meeting time and day might change as of the beginning of March 2017. Please check back soon.
Meetings
Previous Meeting Logs
http://eavesdrop.openstack.org/meetings/network_common_flow_classifier/
Discussion Topic NEXT
- PoC status
- Open discussion
Discussion Topic 28 February 2017
- Post-PTG summary
- PoC status
- Next steps for the CCF
- Open discussion
Discussion Topic 14 February 2017
- Approach A - PoC status
- PTG information
- Open discussion
Discussion Topic 17 January 2017
- Approach A - PoC status
- Open discussion
Discussion Topic 6 December 2016
- Continue discussion on user-facing API vs. Classification mixins.
- Call for contributors
- Open discussion
Discussion Topic 22 November 2016
- OVS Flow Manager: new patch available at https://review.openstack.org/#/c/323963/
- We have converged to Approach 2 at https://review.openstack.org/#/c/333993/
- Should this approach include a user-facing API?
- Completing the spec and starting the code
- Repo: new repo or neutron-classifier repo?
- Open discussion
Discussion Topic 11 October 2016
Classification Framework
- Can we converge on a first approach (https://review.openstack.org/#/c/333993)?
- Next steps on the common classifier
- Repo: new repo or neutron-classifier repo?
- Barcelona Summit arrangements
OVS Flow Management
- Status of the OVS Flow Management spec: https://review.openstack.org/#/c/320439
- Barcelona Summit arrangements
Open discussion
Discussion Topic 27 September 2016
Classification Framework
- Can we converge on a first approach (https://review.openstack.org/#/c/333993)?
- Next steps on the common classifier
- Repo: new repo or neutron-classifier repo?
- Barcelona Summit arrangements
OVS Flow Management
- Status of https://review.openstack.org/#/c/320439/
- Barcelona Summit arrangements
Open discussion
Discussion Topic 5 July 2016
- General spec discussion: https://review.openstack.org/#/c/333993
Discussion Topic 14 June 2016
- Bug Status: developed as a RFE over neutron-core? https://bugs.launchpad.net/neutron/+bug/1476527 and https://bugs.launchpad.net/neutron/+bug/1583299
- Typed Classifications proposal as superset of original FC (https://bugs.launchpad.net/neutron/+bug/1476527/comments/26)
- Spec on Common Flow Classifier
- POC code for Flow Manager: https://review.openstack.org/#/c/323963/
Discussion Topic 17 May 2016
- Develop this as a bug fix in Neutron or separate stadium project
- Use existing QoS bug https://bugs.launchpad.net/neutron/+bug/1527671 or creating a new one
- Discussion on the comparison table
- API design Spec
Meet-up Discussion Notes
Austin Summit Etherpad discussion notes
https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit
Atlanta PTG main whiteboard drafting
https://drive.google.com/open?id=0B41O7G76VLRpS1VpMW1wZmhVOGs
Overview
Multiple Stadium features inside Neutron need flow classifier functionality. Instead of each feature creating its own FC API, we should have one common FC API that can be used by all the features. Currently the features that need FC are: Tap as a service, SFC, QoS, Security Group, FW, BGP/VPN. Following are some general guielines on the FC API specification: ---Common FC API should not cause a major change of existing FC API used by the features, and should be a superset of existing FC rules used by existing features ---We should come up with one consistent way of defining the API and classification rules, and then associate the FC with each feature.
Currently only networking-sfc and security group have defined and implemented the FC API.
1. First step is to identify the gap between the security group FC API and the networking-sfc FC API. Following is the comparison table and the gap. It seems the SFC FC is superset of security group FC.
2. Second step is to consolidate the two FC into one. Two options: 1) evolve the SFC FC to be the common FC for Tap as a service, SFC, QoS, Security Group, FW, BGP/VPN, 2) evolve the SFC FC to be the common FC for Tap as a service, SFC, QoS, FW, BGP/VPN, but keep the security group separate.
3. Write a spec on the consolidated FC and get it reviewed and consensus reached.