Open Stack

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.