Open Stack

+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.Zhang at 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:yamamoto at 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.morin at 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; 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/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: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 
>>> 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-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.
>> 
>> 
>> 
>> ______________________________________________________________________
>> ____ 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
> __________________________________________________________________________
> 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