hi, On Mon, May 16, 2016 at 9:00 PM, Ihar Hrachyshka <ihrac...@redhat.com> wrote: > +1 for earlier time. But also, have we booked any channel for the meeting? > Hijacking #openstack-neutron may not work fine during such a busy (US) time. > I suggest we propose a patch for > https://github.com/openstack-infra/irc-meetings
i agree and submitted a patch. https://review.openstack.org/#/c/316830/ > > Ihar > >> On 10 May 2016, at 20:35, Cathy Zhang <cathy.h.zh...@huawei.com> wrote: >> >> It is always hard to find a day and time that is good for everyone around >> the globe:-) >> The first meeting will still be UTC 1700 ~ UTC 1800 May 17 on Neutron >> channel. >> In the meeting, we can see if we can reach consensus on a new meeting time. >> >> Cathy >> >> -----Original Message----- >> From: Takashi Yamamoto [mailto:yamam...@midokura.com] >> Sent: Tuesday, May 10, 2016 12:40 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 >> >> On Tue, May 10, 2016 at 12:41 AM, <thomas.mo...@orange.com> wrote: >>> 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 ? >> >> +1 for earlier >> >>> 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; arma...@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; '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/ap >>>> i.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_sf >>>> c/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 >>>> Cathy> 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 >>> >>> >>> >>> ______________________________________________________________________ >>> ___________________________________________________ >>> >>> 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. >>> >>> >>> >>> ______________________________________________________________________ >>> ____ 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 >> __________________________________________________________________________ >> 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 __________________________________________________________________________ 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