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