[openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers
Jay Pipes
jaypipes at gmail.com
Mon Nov 9 12:58:34 UTC 2015
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
More information about the OpenStack-dev
mailing list