Hi everyone,
We have room 400 at 3:10pm on Thursday available for discussion of the two
topics.
Another option is to use the common room with roundtables in "Salon C" during
Monday or Wednesday lunch time.
Room 400 at 3:10pm is a closed room while the Salon C is a big open room which
can host 500 people.
I am Ok with either option. Let me know if anyone has a strong preference.
Thanks,
Cathy
-----Original Message-----
From: Cathy Zhang
Sent: Thursday, April 14, 2016 1:23 PM
To: OpenStack Development Mailing List (not for usage questions); 'Ihar
Hrachyshka'; Vikram Choudhary; 'Sean M. Collins'; 'Haim Daniel'; 'Mathieu
Rohon'; 'Shaughnessy, David'; 'Eichberger, German'; Cathy Zhang; Henry Fourie;
'arma...@gmail.com'
Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier and OVS
Agent extension for Newton cycle
Thanks for everyone's reply!
Here is the summary based on the replies I received:
1. We should have a meet-up for these two topics. The "to" list are the people
who have interest in these topics.
I am thinking about around lunch time on Tuesday or Wednesday since some of
us will fly back on Friday morning/noon.
If this time is OK with everyone, I will find a place and let you know
where and what time to meet.
2. There is a bug opened for the QoS Flow Classifier
https://bugs.launchpad.net/neutron/+bug/1527671
We can either change the bug title and modify the bug details or start with a
new one for the common FC which provides info on all requirements needed by all
relevant use cases. There is a bug opened for OVS agent extension
https://bugs.launchpad.net/neutron/+bug/1517903
3. There are some very rough, ugly as Sean put it:-), and preliminary work on
common FC https://github.com/openstack/neutron-classifier which we can see how
to leverage. There is also a SFC API spec which covers the FC API for SFC usage
https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst,
the following is the CLI version of the Flow Classifier for your reference:
neutron flow-classifier-create [-h]
[--description <description>]
[--protocol <protocol>]
[--ethertype <Ethertype>]
[--source-port <Minimum source protocol port>:<Maximum source protocol
port>]
[--destination-port <Minimum destination protocol port>:<Maximum
destination protocol port>]
[--source-ip-prefix <Source IP prefix>]
[--destination-ip-prefix <Destination IP prefix>]
[--logical-source-port <Neutron source port>]
[--logical-destination-port <Neutron destination port>]
[--l7-parameters <L7 parameter>] FLOW-CLASSIFIER-NAME
The corresponding code is here
https://github.com/openstack/networking-sfc/tree/master/networking_sfc/extensions
4. We should come up with a formal Neutron spec for FC and another one for OVS
Agent extension and get everyone's review and approval. Here is the etherpad
catching our previous requirement discussion on OVS agent (Thanks David for the
link! I remember we had this discussion before)
https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion
More inline.
Thanks,
Cathy
-----Original Message-----
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
Sent: Thursday, April 14, 2016 3:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS
Agent extension for Newton cycle
Cathy Zhang <cathy.h.zh...@huawei.com> wrote:
> Hi everyone,
> Per Armando’s request, Louis and I are looking into the following
> features for Newton cycle.
> · Neutron Common FC used for SFC, QoS, Tap as a service etc.,
> · OVS Agent extension
> Some of you might know that we already developed a FC in
> networking-sfc project and QoS also has a FC. It makes sense that we
> have one common FC in Neutron that could be shared by SFC, QoS, Tap as a
> service etc.
> features in Neutron.
I don’t actually know of any classifier in QoS. It’s only planned to emerge,
but there are no specs or anything specific to the feature.
Anyway, I agree that classifier API belongs to core neutron and should be
reused by all interested subprojects from there.
> Different features may extend OVS agent and add different new OVS flow
> tables to support their new functionality. A mechanism is needed to
> ensure consistent OVS flow table modification when multiple features
> co-exist. AFAIK, there is some preliminary work on this, but it is not
> a complete solution yet.
I think there is no formal spec or anything, just some emails around there.
That said, I don’t follow why it’s a requirement for SFC to switch to l2 agent
extension mechanism. Even today, with SFC maintaining its own agent, there are
no clear guarantees for flow priorities that would avoid all possible conflicts.
Cathy> There is no requirement for SFC to switch. My understanding is that
current L2 agent extension does not solve the conflicting entry issue if two
features inject the same priority table entry. I think this new L2 agent effort
is try to come up with a mechanism to resolve this issue. Of course if each
feature( SFC or Qos) uses its own agent, then there is no coordination and no
way to avoid conflicts.
> We will like to start these effort by collecting requirements and then
> posting specifications for review. If any of you would like to join
> this effort, please chime in. We can set up a meet-up session in the
> Summit to discuss this face-in-face.
Great. Let’s have a meetup for this topic.
Ihar
__________________________________________________________________________
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
__________________________________________________________________________
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
