Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

2015-11-13 Thread Ihar Hrachyshka
Paul Carver wrote: On 11/12/2015 3:50 PM, Ihar Hrachyshka wrote: All I am saying is that IF we merge some classifier API into neutron core and start using it for core, non-experimental, features, we cannot later move to some newer version of this API [that you will

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

2015-11-13 Thread Ihar Hrachyshka
German wrote: Ihar, The Service Group API will be added to FWaaS only and remain experimental in M. If the community finds it useful for other areas it can be added to Neutron core once it is matures. I think incubating it inside FWaaS will give us the

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

2015-11-13 Thread Eichberger, German
Ihar, The Service Group API will be added to FWaaS only and remain experimental in M. If the community finds it useful for other areas it can be added to Neutron core once it is matures. I think incubating it inside FWaaS will give us the velocity to iterate quickly and once it matures a

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

2015-11-13 Thread Sean M. Collins
On Fri, Nov 13, 2015 at 01:53:49AM EST, Paul Carver wrote: > On 11/3/2015 1:03 PM, Sean M. Collins wrote: > >Anyway, the code is currently up on GitHub - I just threw it on there > >because I wanted to scratch my hacking itch quickly. > > > >https://github.com/sc68cal/neutron-classifier > > > >

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

2015-11-12 Thread Ihar Hrachyshka
Cathy Zhang wrote: Agree with Paul and Louis. The networking-sfc repo should be preserved to support the service function chain functionality. Flow classifier is just needed to specify what flows will go through the service port chain. The flow classifier API is

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

2015-11-12 Thread Paul Carver
On 11/12/2015 3:50 PM, Ihar Hrachyshka wrote: All I am saying is that IF we merge some classifier API into neutron core and start using it for core, non-experimental, features, we cannot later move to some newer version of this API [that you will iterate on] without leaving a huge pile of

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

2015-11-12 Thread Paul Carver
On 11/3/2015 1:03 PM, Sean M. Collins wrote: Anyway, the code is currently up on GitHub - I just threw it on there because I wanted to scratch my hacking itch quickly. https://github.com/sc68cal/neutron-classifier Sean, How much is needed to turn your models into something runnable to the

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

2015-11-11 Thread Cathy Zhang
, 2015 2:33 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers Paul, Agree completely that the networking-sfc repo should be preserved as it includes functionality beyond that of just

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

2015-11-11 Thread Paul Carver
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

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

2015-11-11 Thread Henry Fourie
. - Louis -Original Message- From: Paul Carver [mailto:pcar...@paulcarver.us] Sent: Wednesday, November 11, 2015 1:07 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers On 11/10/2015

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

2015-11-10 Thread Eichberger, German
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

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

2015-11-10 Thread Sean M. Collins
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

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

2015-11-09 Thread Jay Pipes
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,

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

2015-11-09 Thread Mickey Spiegel
il.com> Date: 11/09/2015 05:04AM Subject: Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers 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 singl

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

2015-11-04 Thread Sean M. Collins
On Tue, Nov 03, 2015 at 02:08:26PM EST, Vikram Choudhary wrote: > Thanks for all your efforts Sean. > > I was actually thinking a separate IRC for this effort would be great and > will help all the interested people to come together and develop. > > Any thoughts on this? Unless it becomes super

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

2015-11-04 Thread Ihar Hrachyshka
Sean M. Collins wrote: Hi Ihar, This sounds good. I actually had a draft e-mail that I've been saving until I got back, that may be relevant. Some contributors met on Friday to discuss the packet classification framework, mostly centered around just building a reusable

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

2015-11-04 Thread Vikram Choudhary
I am fine with this! -Original Message- From: Sean M. Collins [mailto:s...@coreitpro.com] Sent: 04 November 2015 14:28 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers On Tue, Nov

[openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

2015-11-03 Thread Ihar Hrachyshka
-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

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

2015-11-03 Thread Sean M. Collins
Hi Ihar, This sounds good. I actually had a draft e-mail that I've been saving until I got back, that may be relevant. Some contributors met on Friday to discuss the packet classification framework, mostly centered around just building a reusable library that can be shared among multiple

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

2015-11-03 Thread Vikram Choudhary
Thanks for all your efforts Sean. I was actually thinking a separate IRC for this effort would be great and will help all the interested people to come together and develop. Any thoughts on this? Thanks Vikram On Nov 3, 2015 11:54 PM, "Sean M. Collins" wrote: > I made a

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

2015-11-03 Thread Sean M. Collins
I made a very quick attempt to jot down my thoughts about how it could be used. It's based off what I proposed in https://review.openstack.org/238812, and is my attempt to take that review and use SQLAlchemy to make it actually work.