Open Stack

On 11/03/2015 12:19 PM, Ihar Hrachyshka wrote:
> Now, I don't think that we need two APIs for the same thing. I would
> be glad if we instead converge on a single API, making sure all cases
> are covered. In the end, the feature is just a building block for
> other features, like fwaas, security groups, or QoS.
>
> We could build traffic classifier use cases on top of service groups,
> though the name of the latter is a bit specific, and could use some
> more generalization to cover other cases where we need to classify
> traffic that may belong to different services; or vice versa, may
> split into several categories, even while having a single service source.
>
> I encourage those who work on traffic classifier, and those who will
> implement and review service group feature, to start discussion on how
> we converge and avoid multiple APIs for similar things.

+1000

Please do not create 3 APIs that essentially do the exact same thing. I 
think Sean's on the right track with the modeling he's been doing in his 
PoC library.

I think the classifier spec from Yuji Azama is better than the 
networking-sfc service function chaining API proposal because, well, it 
actually describes an API instead of a series of CLI commands.

The problem with the classifier proposal, though, is that it flattens 
the API into just the rules part, discarding the grouping part that 
allows one to define groups of rules. The service-group[-rules] spec 
gets this part correct.

At this point, I'd recommend just enhancing the existing security-group 
and security-group-rules APIs, though, since having both "service-group" 
and "security-group" in the API referring to similar concepts will be 
quite confusing IMHO. But then, Sean has told me he doesn't want to 
change the original AWS security group concept in the Neutron API... I'm 
on the fence about whether that would really be problematic if the 
security-group[-rules] API is enhanced/evolved appropriately.

In short, my preference, in order, would be:

1) Enhance/evolve the existing security-groups and security-group-rules 
API in Neutron to support more generic classification of traffic from L2 
to L7, using mostly the modeling that Sean has put together in his PoC 
library.

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.

Best,
-jay