[Yahoo-eng-team] [Bug 1619084] [NEW] Release request for networking-sfc for stable/Mitaka
Public bug reported: Branch: stable/mitaka New Tag: 2.0.0 The Mitaka release of networking-SFC contains several enhancements and bug fixes. All code patches have been reviewed. In addition, comprehensive end-to- end integration testing with many different CLI combinations have been tested. The community project team has agreed that the codes are ready for release. ** Affects: networking-sfc Importance: Critical Assignee: cathy Hong Zhang (cathy-h-zhang) Status: New ** Affects: neutron Importance: Undecided Status: New ** Tags: release-subproject ** Also affects: neutron Importance: Undecided Status: New ** Tags added: release-subproject -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1619084 Title: Release request for networking-sfc for stable/Mitaka Status in networking-sfc: New Status in neutron: New Bug description: Branch: stable/mitaka New Tag: 2.0.0 The Mitaka release of networking-SFC contains several enhancements and bug fixes. All code patches have been reviewed. In addition, comprehensive end- to-end integration testing with many different CLI combinations have been tested. The community project team has agreed that the codes are ready for release. To manage notifications about this bug go to: https://bugs.launchpad.net/networking-sfc/+bug/1619084/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1572656] Re: Neutron IETF Service Function Chaining API
** Changed in: networking-sfc Status: Incomplete => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1572656 Title: Neutron IETF Service Function Chaining API Status in networking-sfc: Invalid Status in neutron: Incomplete Bug description: The ability to dynamically instantiate Service Function Chains (SFCs) is sought by many. Doing so with OpenStack via Neutron brings additional value since basic networking is already handled and a framework is in place for translating network abstractions to back-ends such as virtual switches and SDN controllers. With that in mind, only additional logic for traffic classification and steering, plus an API capable of reflecting these capabilities, needs to be added to make Neutron the single API necessary to instantiate and manage Service Function Chains together with the pure networking abstraction. To manage notifications about this bug go to: https://bugs.launchpad.net/networking-sfc/+bug/1572656/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1583299] [NEW] Add a Common Flow Classifier in Neutron
Public bug reported: [Existing problem] Currently, multiple Stadium features inside Neutron need flow classifier functionality. In the future there could be more Neutron features that will need this functionality. Instead of each feature creating its own FC API and resource, we should have one common FC API and resource inside Neutron that can be used by all the networking features in OpenStack (inside or outside of Neutron stadium). This will avoid a lot of redundancy and maintenance issues. [Proposal] Currently the features that need FC are: Tap as a service, SFC, QoS, FW, BGP/VPN, GBP. There has been a meeting discussion in the Austin Summit (https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit). The interested party has a follow-on meeting discussion on 5/17/2016 (http://eavesdrop.openstack.org/meetings/network_common_flow_classifier/2016/network_common_flow_classifier.2016-05-17-17.02.html). According to the consensus of the meeting, a new RFE for flow classifier should be submitted in neutron-core and we will develop FC as a RFE over neutron-core. A general guideline on the FC design is that it should provide a superset of FC rules used by existing features and the FC rules should be easy to extend for new features in the future. ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1583299 Title: Add a Common Flow Classifier in Neutron Status in neutron: New Bug description: [Existing problem] Currently, multiple Stadium features inside Neutron need flow classifier functionality. In the future there could be more Neutron features that will need this functionality. Instead of each feature creating its own FC API and resource, we should have one common FC API and resource inside Neutron that can be used by all the networking features in OpenStack (inside or outside of Neutron stadium). This will avoid a lot of redundancy and maintenance issues. [Proposal] Currently the features that need FC are: Tap as a service, SFC, QoS, FW, BGP/VPN, GBP. There has been a meeting discussion in the Austin Summit (https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit). The interested party has a follow-on meeting discussion on 5/17/2016 (http://eavesdrop.openstack.org/meetings/network_common_flow_classifier/2016/network_common_flow_classifier.2016-05-17-17.02.html). According to the consensus of the meeting, a new RFE for flow classifier should be submitted in neutron-core and we will develop FC as a RFE over neutron-core. A general guideline on the FC design is that it should provide a superset of FC rules used by existing features and the FC rules should be easy to extend for new features in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1583299/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1537267] Re: release request for networking-sfc in Mitaka time frame
** Changed in: networking-sfc Importance: Undecided => Critical ** Changed in: networking-sfc Status: New => Fix Released ** Changed in: networking-sfc Status: Fix Released => Fix Committed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1537267 Title: release request for networking-sfc in Mitaka time frame Status in networking-sfc: Fix Committed Status in neutron: Fix Released Bug description: Branch: stable/mitaka We also has stable/liberty branch for release against liberty branch code base and would like to release it too. The release of networking-sfc contains feature support for service function chaining. release version: 1.0.0 All code patches have been reviewed (open for review and collecting comments for a very long time) and merged. Test scripts have also been merged. In addition, comprehensive end-to-end integration testing within the same subnet and across different subnets with many different CLI combinations have been tested. The community project team has agreed that the codes are ready for release so that more people can give it a try and give input on future enhancement. To manage notifications about this bug go to: https://bugs.launchpad.net/networking-sfc/+bug/1537267/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1537267] [NEW] release request for networking-sfc in Mitaka time frame
Public bug reported: Branch: stable/mitaka We also has stable/liberty branch for release against liberty branch code base and would like to release it too. The release of networking-sfc contains feature support for service function chaining. release version: 1.0.0 ** Affects: networking-sfc Importance: Undecided Assignee: cathy Hong Zhang (cathy-h-zhang) Status: New ** Affects: neutron Importance: Wishlist Assignee: Kyle Mestery (mestery) Status: New ** Tags: release-subproject ** Also affects: neutron Importance: Undecided Status: New ** No longer affects: neutron ** Project changed: networking-sfc => neutron ** Also affects: networking-sfc Importance: Undecided Status: New ** Changed in: networking-sfc Assignee: (unassigned) => cathy Hong Zhang (cathy-h-zhang) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1537267 Title: release request for networking-sfc in Mitaka time frame Status in networking-sfc: New Status in neutron: New Bug description: Branch: stable/mitaka We also has stable/liberty branch for release against liberty branch code base and would like to release it too. The release of networking-sfc contains feature support for service function chaining. release version: 1.0.0 To manage notifications about this bug go to: https://bugs.launchpad.net/networking-sfc/+bug/1537267/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1450625] Re: common service chaining driver API
** Changed in: neutron Status: Opinion = In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1450625 Title: common service chaining driver API Status in OpenStack Neutron (virtual network service): In Progress Bug description: This feature/bug is related to bug #1450617 (Neutron extension to support service chaining) Bug #1450617 is to add a neutron port chaining API and associated neutron port chain manager to support service chaining functionality. Between the neutron port manager and the underlying service chain drivers, a common service chain driver API shim layer is needed to allow for different types of service chain drivers (eg. OVS driver, different SDN Controller drivers) to be integrated into the Neutron. Different service chain drivers may have different ways of constructing the service chain path and use different data path encapsulation and transport to steer the flow through the chain path. With one common interface between the Neutron service chain manager and various vendor-specific drivers, the driver design/implementation can be changed without changing the Neutron Service Chain Manager and the interface APIs. This interface should include the following entities: * An ordered list of service function instance clusters. Each service instance cluster represents a group of like service function instances which can be used for load distribution. * Traffic flow classification rules: It consists of a set of flow descriptors. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1450625/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1450617] [NEW] Neutron extension to support service chaining
Public bug reported: Currently Neutron does not support service chaining. To support service chaining, Service VMs must be attached to points of the network and then traffic must be steered between these attachment points. There are two steps in creating a service chain. First, Services VMs (such as FW VM) need to be created and connected to a Neutron network via Neutron ports. After that, selected traffic flows need to be steered through an ordered sequence of these service VM ports. Current OpenStack already support creation of service VMs and attachment of these service VMs to Neutron network ports. What is missing is an API to specify classification rules of the selected flow and the sequence of service VM ports the selected flow needs to go through so that it can get the desired service treatment. Neutron API can be extended to fill in this gap. This new port chain API does not need to know the actual services attached to these Neutron ports since the Service VM creation API already has this information. In summary, first the service function is instantiated and connected to the network through Neutron ports. Once the service function is attached to Neutron ports, the ports are included in a port chain to allow the service function to provide treatment to the user's traffic. ** Affects: neutron Importance: Undecided Assignee: cathy Hong Zhang (cathy-h-zhang) Status: In Progress ** Tags: rfe ** Changed in: neutron Assignee: (unassigned) = cathy Hong Zhang (cathy-h-zhang) ** Changed in: neutron Status: New = In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1450617 Title: Neutron extension to support service chaining Status in OpenStack Neutron (virtual network service): In Progress Bug description: Currently Neutron does not support service chaining. To support service chaining, Service VMs must be attached to points of the network and then traffic must be steered between these attachment points. There are two steps in creating a service chain. First, Services VMs (such as FW VM) need to be created and connected to a Neutron network via Neutron ports. After that, selected traffic flows need to be steered through an ordered sequence of these service VM ports. Current OpenStack already support creation of service VMs and attachment of these service VMs to Neutron network ports. What is missing is an API to specify classification rules of the selected flow and the sequence of service VM ports the selected flow needs to go through so that it can get the desired service treatment. Neutron API can be extended to fill in this gap. This new port chain API does not need to know the actual services attached to these Neutron ports since the Service VM creation API already has this information. In summary, first the service function is instantiated and connected to the network through Neutron ports. Once the service function is attached to Neutron ports, the ports are included in a port chain to allow the service function to provide treatment to the user's traffic. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1450617/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
