[openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

Takashi Yamamoto yamamoto at midokura.com
Mon May 16 13:47:11 UTC 2016


On Mon, May 16, 2016 at 10:25 PM, Takashi Yamamoto
<yamamoto at midokura.com> wrote:
> hi,
>
> On Mon, May 16, 2016 at 9:00 PM, Ihar Hrachyshka <ihrachys at 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.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
>>
>>
>> __________________________________________________________________________
>> 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



More information about the OpenStack-dev mailing list