Open Stack

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/api.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_sfc/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 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