Open Stack

Sean and Mickey +1

As much as I like us using the same API to create classifiers (users only need to learn one way) I think for the short term we should work with our own constructs and rely on a common data model. That will allow us to iterate faster on the REST API level and not have premature constraints (as Mickey mentions).

Midterm we should create some common API which is a superset of the functionality of all projects using it.

German



On 11/10/15, 5:30 AM, "Sean M. Collins" <sean at coreitpro.com> wrote:

>On Mon, Nov 09, 2015 at 07:58:34AM EST, Jay Pipes wrote:
>> 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.
>
><snip>
>
>> 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.
>> 
>
>I'd prefer that since we're already redesigning the Firewall API that we
>go ahead and make the Firewall API more expressive, so users can
>classify L2 to L7 traffic and then make filtering decisions. Let's not
>complicate the Security Group API with more advanced features that we
>just bolt on. So my vote is for #2 - with slight adjustments. I still
>think the networking-sfc repo should stay around, and that collaboration
>on the common classifier framework should happen, so that we can start
>both projects (sfc and fwaas) with a common datamodel for the classifier
>piece.
>
>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.
>
>-- 
>Sean M. Collins
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev