On Mon, May 16, 2016 at 10:25 PM, Takashi Yamamoto <yamam...@midokura.com> wrote: > 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/
oops, unfortunately there seems no meeting channel free at the time slot. > >> >> 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
