+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
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
