-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all,
on fwaas design session in Tokyo it was pointed out that for new fwaas API we may want to use service groups [1] that were approved but never merged. As far as I can tell, service groups are designed to catch several criteria to describe a type of networking application 'service'. Possible criteria are e.g.: port, protocol, icmp code or type, ... I need to admit this is was the first time when I heard about this new feature proposed. And it immediately hit me that it somehow resembles traffic classifier feature [2] that we look into QoS context for Mitaka. The classifier thingy is designed to describe traffic types, and is expected to support multiple criteria, including: port, mac, ether type, protocol, ... You can see that the lists of possible criteria are quite similar, and it's of no surprise since for what I wonder both features are designed to do the same thing: to allow to match and classify traffic based on criteria, and then use those sets of criteria to apply different policies (whether it's firewall, QoS marks, or any other action you can think of for specific traffic type). 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. Am I making any sense? [1]: http://specs.openstack.org/openstack/neutron-specs/specs/juno/service-gr oup.html [2]: https://review.openstack.org/#/c/190463/ Ihar -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJWOOy5AAoJEC5aWaUY1u57TF0IAMgfcJosHFPTIOObNxOVdSBv SnCRrTWOH0KKP1omyFh3oEWyiZJcAWarAUYPCdpKDo9PNF73jCUJcE0ieiWnIjzN 2N7Km1c7nxDNla5oGhHIlckVkeVKwrt8y1JiuJkqCB59FlgJ1wCYKiKipx3hQKTN TqmU7kjpt5VL7L1uRCJIQ5GN1vwpEA4xzcBG39xdZe6PzP41ztGDO0Cdkeo63xYj AvvFfW/KxZ332+PyZS4ZtYYLFd33s0PCe70g4CcnfuM/3Ma350gUdJAPdz4knrDx 5f9oPdkJDfBJTmxmz5GJJFKjc/FwFydy5J69jEWSeWKx+dM1tUbCS5hwaloSqk4= =kJ70 -----END PGP SIGNATURE----- __________________________________________________________________________ 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