Thanks for being on top of this.
I made some comments on the etherpad. IMO probably, this is better as a
simple extension
of the api and it's datamodels. Since we won't need to extend core
resources to connect
them to flow classifiers, but in the other hand, we will connect other
services to those
classifiers.
This (if I got it right) will be just a common model (fed through a
common API) to be consumed
by other services.
Vikram Choudhary wrote:
Hi All,
We have started a etherpad link [1] for collecting various use-cases about
flow-classifier.
Request all to provide their opinion on the same. We will be discussing the
same over SFC IRC meeting [2].
Any contribution will be appreciated.
[1] Etherpad Link
https://etherpad.openstack.org/p/flow-classifier
[2] SFC IRC Meeting
http://eavesdrop.openstack.org/#Neutron_Service_Chaining_meeting
Thanks
Vikram
From: Vikram Choudhary
Sent: 05 June 2015 14:42
To: 'Miguel Angel Ajo'
Cc: [email protected]; Henry Fourie; Cathy Zhang; [email protected];
Dongfeng (C); Kyle Mestery; [email protected]; Dhruv Dhody;
Kalyankumar Asangi
Subject: RE: [neutron] Regarding Flow classifiers existing proposals
Thanks Miguel!
From: Miguel Angel Ajo [mailto:[email protected]]
Sent: 05 June 2015 14:12
To: Vikram Choudhary
Cc: [email protected]<mailto:[email protected]>; Henry Fourie; Cathy
Zhang; [email protected]<mailto:[email protected]>; Dongfeng (C); Kyle Mestery;
[email protected]<mailto:[email protected]>; Dhruv Dhody;
Kalyankumar Asangi
Subject: [neutron] Regarding Flow classifiers existing proposals
Added openstack-dev, where I believe this conversation must live.
I totally agree on this, thank you for bringing up this conversation. This is
not something we want to do for QoS this cycle, but probably next cycle.
Anyway, an unified data model and API to create/update classifiers will not
only be beneficial from the code duplication point of view, but will also
provide a better user experience.
I’m all for it.
Best regards,
Miguel Ángel Ajo
On Friday 5 June 2015 at 09:57, Vikram Choudhary wrote:
Dear All,
There are multiple proposal floating around flow classifier rules for Liberty
[1], [2] and [3].
I feel we all should work together and try to address all our use case having a
unified framework rather than working separately achieving the same goal.
Moreover, I can find the proposal for flow classifier as defined by the
existing SFC [2] proposal is too generic and could address all the use cases by
minor extension’s.
In this regard, I would like all to come forward, exchange their thoughts, work
together and make it happen good the first go rather doing the same effort
separately and end up in duplicating code& effort ☹.
I always feel less code will make our life happy in the long run ;)
Please let me know about your views.
[1] Add Neutron API extensions for packet forwarding
https://review.openstack.org/#/c/186663/
[2] Neutron API for Service Chaining [Flow Filter resource]
https://review.openstack.org/#/c/177946/6/specs/liberty/neutron-api-for-service-chaining.rst
[3] QoS API Extension [Defines classifier rule in QoSRule. Classifier rule can
really grow big in the long run]:
https://review.openstack.org/#/c/88599/10/specs/liberty/qos-api-extension.rst
Thanks
Vikram
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
