Agree with Paul and Louis. The networking-sfc repo should be preserved to support the service function chain functionality. Flow classifier is just needed to specify what flows will go through the service port chain.
The flow classifier API is designed as a separate plugin which is independent of the port chain plugin. We will support the effort of evolving it to a common service classifier API and moving it out of the networking-sfc repo when the time comes. Thanks, Cathy -----Original Message----- From: Henry Fourie [mailto:louis.fou...@huawei.com] Sent: Wednesday, November 11, 2015 2:33 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers Paul, Agree completely that the networking-sfc repo should be preserved as it includes functionality beyond that of just a classifier - it defines the service chain structure. Work on a common service classifier API could be done by the networking-sfc team to help in evaluating that API. - Louis -----Original Message----- From: Paul Carver [mailto:pcar...@paulcarver.us] Sent: Wednesday, November 11, 2015 1:07 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers On 11/10/2015 8:30 AM, Sean M. Collins wrote: > On Mon, Nov 09, 2015 at 07:58:34AM EST, Jay Pipes wrote: > >> 2) Keep the security-group API as-is to keep outward compatibility with AWS. >> Create a single, new service-groups and service-group-rules API for >> L2 to L7 traffic classification using mostly the modeling that Sean has put >> together. >> Remove the networking-sfc repo and obselete the classifier spec. Not >> sure what should/would happen to the FWaaS API, frankly. > > As to the REST-ful API for creating classifiers, I don't know if it > should reside in the networking-sfc project. It's a big enough piece > that it will most likely need to be its own endpoint and repo, and > have stakeholders from other projects, not just networking-sfc. That > will take time and quite a bit of wrangling, so I'd like to defer that > for a bit and just work on all the services having the same data > model, where we can make changes quickly, since they are not visible > to API consumers. > I agree that the service classifier API should NOT reside in the networking-sfc project, but I don't understand why Jay suggests removing the networking-sfc repo. The classifier specified by networking-sfc is needed only because there isn't a pre-existing classifier API. As soon as we can converge on a common classifier API I am completely in favor of using it in place of the one in the networking-sfc repo, but SFC is more than just classifying traffic. We need a classifier in order to determine which traffic to redirect, but we also need the API to specify how to redirect the traffic that has been identified by classifiers. __________________________________________________________________________ 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 __________________________________________________________________________ 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 __________________________________________________________________________ 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
