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
