Open Stack

Hi Cathy,

Cathy Zhang:
> I will tentatively set the meeting time to UTC 1700 ~ UTC 1800 Tuesday. Hope this time is good for all people who have interest and like to contribute to this work. We plan to start the first meeting on May 17.

I would be happy to participate, but I'm unlikely to be able to attend 
at that time.
Might 15:00 UTC work for others ?
If not, well, I'll make do with log/emails/pads/gerrit interactions.

-Thomas



> -----Original Message-----
> From: Cathy Zhang
> Sent: Thursday, April 21, 2016 11:43 AM
> To: Cathy Zhang; OpenStack Development Mailing List (not for usage questions); Ihar Hrachyshka; Vikram Choudhary; Sean M. Collins; Haim Daniel; Mathieu Rohon; Shaughnessy, David; Eichberger, German; Henry Fourie; armamig at gmail.com; Miguel Angel Ajo; Reedip; Thierry Carrez
> Cc: Cathy Zhang
> Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
>
> 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; 'armamig at 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:ihrachys at 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.Zhang at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.