Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
Hi Haim, Thanks for taking care of this. I see that Miguel has started working on the new L2 extension for Flow management。 https://bugs.launchpad.net/neutron/+bug/1563967 https://review.openstack.org/#/c/320439/ We may need to sync up the change with this new work too. Thanks, Cathy From: Haim Daniel [mailto:hdan...@redhat.com] Sent: Thursday, May 26, 2016 5:42 AM To: Ihar Hrachyshka Cc: Cathy Zhang; OpenStack Development Mailing List (not for usage questions); Vikram Choudhary; Sean M. Collins; Mathieu Rohon; Shaughnessy, David; Eichberger, German; Henry Fourie; Armando M. Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle Hi all, sorry for digging up this thread. I took a liberty to submitt an RFE per Ihar's suggestion for the first step (switching to l2 agent extensions): https://bugs.launchpad.net/networking-sfc/+bug/1586024 As a followup on that - hoping to send some wip patches in the near time. Hope to hear your thoughts/suggestions on the $subj. On Fri, Apr 15, 2016 at 2:44 AM, Ihar Hrachyshka mailto:ihrac...@redhat.com>> wrote: Cathy Zhang mailto:cathy.h.zh...@huawei.com>> wrote: 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. Sorry, I probably used misleading wording. I meant, why do we consider the semantic flow management support in l2 agent extension framework a *prerequisite* for SFC to switch to l2 agent extensions? The existing framework should already allow SFC to achieve what you have in the subproject tree implemented as a separate agent (essentially a fork of OVS agent). It will also set SFC to use standard extension mechanisms instead of hacky inheritance from OVS agent classes. So even without the strict semantic flow management, there is benefit for the subproject. With that in mind, I would split this job into 3 pieces: * first, adopt l2 agent extension mechanism for SFC functionality (dropping custom agent); * then, work on semantic flow management support in OVS agent API class [1]; * once the feature emerges, switch SFC l2 agent extension to the new framework to manage SFC flows. I would at least prioritize the first point and target it to Newton-1. Other bullet points may take significant time to bake. [1] https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_agent_extension_api.py 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
Hi all, sorry for digging up this thread. I took a liberty to submitt an RFE per Ihar's suggestion for the first step (switching to l2 agent extensions): https://bugs.launchpad.net/networking-sfc/+bug/1586024 As a followup on that - hoping to send some wip patches in the near time. Hope to hear your thoughts/suggestions on the $subj. On Fri, Apr 15, 2016 at 2:44 AM, Ihar Hrachyshka wrote: > Cathy Zhang wrote: > > >> 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. >> > > Sorry, I probably used misleading wording. I meant, why do we consider the > semantic flow management support in l2 agent extension framework a > *prerequisite* for SFC to switch to l2 agent extensions? The existing > framework should already allow SFC to achieve what you have in the > subproject tree implemented as a separate agent (essentially a fork of OVS > agent). It will also set SFC to use standard extension mechanisms instead > of hacky inheritance from OVS agent classes. So even without the strict > semantic flow management, there is benefit for the subproject. > > With that in mind, I would split this job into 3 pieces: > * first, adopt l2 agent extension mechanism for SFC functionality > (dropping custom agent); > * then, work on semantic flow management support in OVS agent API class > [1]; > * once the feature emerges, switch SFC l2 agent extension to the new > framework to manage SFC flows. > > I would at least prioritize the first point and target it to Newton-1. > Other bullet points may take significant time to bake. > > [1] > https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_agent_extension_api.py > > 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
+1 for the bi-weekly proposal @17:00 UTC Tuesday. IMO, let's start with this and then we can check on the feasibility of having the meeting on a weekly basis. On May 23, 2016 1:10 PM, "Takashi Yamamoto" wrote: > On Wed, May 18, 2016 at 4:57 PM, Miguel Angel Ajo Pelayo > wrote: > > Hey, > > > >Finally we took over the channel for 1h. mostly because the time was > > already agreed between many people on opposed timezones and it was a bit > > late to cancel it. > > > >The first point was finding a suitable timeslot for a biweekly meeting > > -for some time- and alternatively following up on email. We should not > take > > over the neutron channel for these meetings anymore, I'm sorry for the > > inconvenience. > > Tony pointed out that there are bi-weekly slot available. > https://review.openstack.org/#/c/316830/ > i guess the slot is fine for many of us. > > > > > Please find the summary here: > > > > > http://eavesdrop.openstack.org/meetings/network_common_flow_classifier/2016/network_common_flow_classifier.2016-05-17-17.02.html > > > > On Tue, May 17, 2016 at 8:10 PM, Kevin Benton wrote: > >> > >> Yeah, no meetings in #openstack-neutron please. It leaves us nowhere to > >> discuss development stuff during that hour. > >> > >> On Tue, May 17, 2016 at 2:54 AM, Miguel Angel Ajo Pelayo > >> wrote: > >>> > >>> I agree, let's try to find a timeslot that works. > >>> > >>> using #openstack-neutron with the meetbot works, but it's going to > >>> generate a lot of noise. > >>> > >>> On Tue, May 17, 2016 at 11:47 AM, Ihar Hrachyshka > > >>> wrote: > > > > On 16 May 2016, at 15:47, Takashi Yamamoto > > wrote: > > > > On Mon, May 16, 2016 at 10:25 PM, Takashi Yamamoto > > wrote: > >> hi, > >> > >> On Mon, May 16, 2016 at 9:00 PM, Ihar Hrachyshka > >> 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. > > This should be solved either by changing the slot, or by getting a new > channel registered for meetings. Using unregistered channels, > especially > during busy hours, is not effective, and is prone to overlaps for > relevant > meetings. The meetings will also not get a proper slot at > eavesdrop.openstack.org. > > 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 > >>> > >> > >> > >> > __ > >> 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
On Wed, May 18, 2016 at 4:57 PM, Miguel Angel Ajo Pelayo wrote: > Hey, > >Finally we took over the channel for 1h. mostly because the time was > already agreed between many people on opposed timezones and it was a bit > late to cancel it. > >The first point was finding a suitable timeslot for a biweekly meeting > -for some time- and alternatively following up on email. We should not take > over the neutron channel for these meetings anymore, I'm sorry for the > inconvenience. Tony pointed out that there are bi-weekly slot available. https://review.openstack.org/#/c/316830/ i guess the slot is fine for many of us. > > Please find the summary here: > > http://eavesdrop.openstack.org/meetings/network_common_flow_classifier/2016/network_common_flow_classifier.2016-05-17-17.02.html > > On Tue, May 17, 2016 at 8:10 PM, Kevin Benton wrote: >> >> Yeah, no meetings in #openstack-neutron please. It leaves us nowhere to >> discuss development stuff during that hour. >> >> On Tue, May 17, 2016 at 2:54 AM, Miguel Angel Ajo Pelayo >> wrote: >>> >>> I agree, let's try to find a timeslot that works. >>> >>> using #openstack-neutron with the meetbot works, but it's going to >>> generate a lot of noise. >>> >>> On Tue, May 17, 2016 at 11:47 AM, Ihar Hrachyshka >>> wrote: > On 16 May 2016, at 15:47, Takashi Yamamoto > wrote: > > On Mon, May 16, 2016 at 10:25 PM, Takashi Yamamoto > wrote: >> hi, >> >> On Mon, May 16, 2016 at 9:00 PM, Ihar Hrachyshka >> 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. This should be solved either by changing the slot, or by getting a new channel registered for meetings. Using unregistered channels, especially during busy hours, is not effective, and is prone to overlaps for relevant meetings. The meetings will also not get a proper slot at eavesdrop.openstack.org. 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 >>> >> >> >> __ >> 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
No worries. If the slot isn't available maybe we can get infra to add another channel. On Wed, May 18, 2016 at 12:57 AM, Miguel Angel Ajo Pelayo < majop...@redhat.com> wrote: > Hey, > >Finally we took over the channel for 1h. mostly because the time was > already agreed between many people on opposed timezones and it was a bit > late to cancel it. > >The first point was finding a suitable timeslot for a biweekly meeting > -for some time- and alternatively following up on email. We should not take > over the neutron channel for these meetings anymore, I'm sorry for the > inconvenience. > > Please find the summary here: > > > http://eavesdrop.openstack.org/meetings/network_common_flow_classifier/2016/network_common_flow_classifier.2016-05-17-17.02.html > > On Tue, May 17, 2016 at 8:10 PM, Kevin Benton wrote: > >> Yeah, no meetings in #openstack-neutron please. It leaves us nowhere to >> discuss development stuff during that hour. >> >> On Tue, May 17, 2016 at 2:54 AM, Miguel Angel Ajo Pelayo < >> majop...@redhat.com> wrote: >> >>> I agree, let's try to find a timeslot that works. >>> >>> using #openstack-neutron with the meetbot works, but it's going to >>> generate a lot of noise. >>> >>> On Tue, May 17, 2016 at 11:47 AM, Ihar Hrachyshka >>> wrote: >>> > On 16 May 2016, at 15:47, Takashi Yamamoto wrote: > > On Mon, May 16, 2016 at 10:25 PM, Takashi Yamamoto > wrote: >> hi, >> >> On Mon, May 16, 2016 at 9:00 PM, Ihar Hrachyshka < ihrac...@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. This should be solved either by changing the slot, or by getting a new channel registered for meetings. Using unregistered channels, especially during busy hours, is not effective, and is prone to overlaps for relevant meetings. The meetings will also not get a proper slot at eavesdrop.openstack.org. 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 >>> >>> >> >> __ >> 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
Hey, Finally we took over the channel for 1h. mostly because the time was already agreed between many people on opposed timezones and it was a bit late to cancel it. The first point was finding a suitable timeslot for a biweekly meeting -for some time- and alternatively following up on email. We should not take over the neutron channel for these meetings anymore, I'm sorry for the inconvenience. Please find the summary here: http://eavesdrop.openstack.org/meetings/network_common_flow_classifier/2016/network_common_flow_classifier.2016-05-17-17.02.html On Tue, May 17, 2016 at 8:10 PM, Kevin Benton wrote: > Yeah, no meetings in #openstack-neutron please. It leaves us nowhere to > discuss development stuff during that hour. > > On Tue, May 17, 2016 at 2:54 AM, Miguel Angel Ajo Pelayo < > majop...@redhat.com> wrote: > >> I agree, let's try to find a timeslot that works. >> >> using #openstack-neutron with the meetbot works, but it's going to >> generate a lot of noise. >> >> On Tue, May 17, 2016 at 11:47 AM, Ihar Hrachyshka >> wrote: >> >>> >>> > On 16 May 2016, at 15:47, Takashi Yamamoto >>> wrote: >>> > >>> > On Mon, May 16, 2016 at 10:25 PM, Takashi Yamamoto >>> > wrote: >>> >> hi, >>> >> >>> >> On Mon, May 16, 2016 at 9:00 PM, Ihar Hrachyshka >>> 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. >>> >>> This should be solved either by changing the slot, or by getting a new >>> channel registered for meetings. Using unregistered channels, especially >>> during busy hours, is not effective, and is prone to overlaps for relevant >>> meetings. The meetings will also not get a proper slot at >>> eavesdrop.openstack.org. >>> >>> 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 >> >> > > __ > 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
Yeah, no meetings in #openstack-neutron please. It leaves us nowhere to discuss development stuff during that hour. On Tue, May 17, 2016 at 2:54 AM, Miguel Angel Ajo Pelayo < majop...@redhat.com> wrote: > I agree, let's try to find a timeslot that works. > > using #openstack-neutron with the meetbot works, but it's going to > generate a lot of noise. > > On Tue, May 17, 2016 at 11:47 AM, Ihar Hrachyshka > wrote: > >> >> > On 16 May 2016, at 15:47, Takashi Yamamoto >> wrote: >> > >> > On Mon, May 16, 2016 at 10:25 PM, Takashi Yamamoto >> > wrote: >> >> hi, >> >> >> >> On Mon, May 16, 2016 at 9:00 PM, Ihar Hrachyshka >> 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. >> >> This should be solved either by changing the slot, or by getting a new >> channel registered for meetings. Using unregistered channels, especially >> during busy hours, is not effective, and is prone to overlaps for relevant >> meetings. The meetings will also not get a proper slot at >> eavesdrop.openstack.org. >> >> 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 > > __ 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
I agree, let's try to find a timeslot that works. using #openstack-neutron with the meetbot works, but it's going to generate a lot of noise. On Tue, May 17, 2016 at 11:47 AM, Ihar Hrachyshka wrote: > > > On 16 May 2016, at 15:47, Takashi Yamamoto > wrote: > > > > On Mon, May 16, 2016 at 10:25 PM, Takashi Yamamoto > > wrote: > >> hi, > >> > >> On Mon, May 16, 2016 at 9:00 PM, Ihar Hrachyshka > 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. > > This should be solved either by changing the slot, or by getting a new > channel registered for meetings. Using unregistered channels, especially > during busy hours, is not effective, and is prone to overlaps for relevant > meetings. The meetings will also not get a proper slot at > eavesdrop.openstack.org. > > 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
> On 16 May 2016, at 15:47, Takashi Yamamoto wrote: > > On Mon, May 16, 2016 at 10:25 PM, Takashi Yamamoto > wrote: >> hi, >> >> On Mon, May 16, 2016 at 9:00 PM, Ihar Hrachyshka 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. This should be solved either by changing the slot, or by getting a new channel registered for meetings. Using unregistered channels, especially during busy hours, is not effective, and is prone to overlaps for relevant meetings. The meetings will also not get a proper slot at eavesdrop.openstack.org. 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
On Mon, May 16, 2016 at 10:25 PM, Takashi Yamamoto wrote: > hi, > > On Mon, May 16, 2016 at 9:00 PM, Ihar Hrachyshka 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 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, 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 morni
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
hi, On Mon, May 16, 2016 at 9:00 PM, Ihar Hrachyshka 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/ > > Ihar > >> On 10 May 2016, at 20:35, Cathy Zhang 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, 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 o
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
+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 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, 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/s
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
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, 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 ] >> [--protocol ] >> [--ethertype ] >> [--source-port :> source protocol port>] >> [--destination-port > port>:] >> [--source-ip-prefix ] >> [--destination-ip-prefix ] >> [--logical-source-port ] >> [--logical-destination-port ] >> [--l7-parameters ] FLOW-CLASSIFIER-NAME >> >> The corresponding code is here >> https://github.com/openstack/networking-sfc/tree/master/n
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, 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/api.rst, >> the following is the CLI version of the Flow Classifier for your >> reference: >> >> neutron flow-classifier-create [-h] >> [--description ] >> [--protocol ] >> [--ethertype ] >> [--source-port :> protocol port>] >> [--destination-port :> destination protocol port>] >> [--source-ip-prefix ] >> [--destination-ip-prefix ] >> [--logical-source-port ] >> [--logical-destination-port ] >> [--l7-parameters ] 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
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 ? 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/api.rst, the following is the CLI version of the Flow Classifier for your reference: neutron flow-classifier-create [-h] [--description ] [--protocol ] [--ethertype ] [--source-port :] [--destination-port :] [--source-ip-prefix ] [--destination-ip-prefix ] [--logical-source-port ] [--logical-destination-port ] [--l7-parameters ] 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: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 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
Thank you! Cathy -Original Message- From: Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com] Sent: Friday, May 06, 2016 12:42 AM To: OpenStack Development Mailing List (not for usage questions) Cc: Cathy Zhang Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle Sounds good, I started by opening a tiny RFE, that may help in the organization of flows inside OVS agent, for inter operability of features (SFC, TaaS, ovs fw, and even port trunking with just openflow). [1] [2] [1] https://bugs.launchpad.net/neutron/+bug/1577791 [2] http://paste.openstack.org/show/495967/ On Fri, May 6, 2016 at 12:35 AM, Cathy Zhang wrote: > Hi everyone, > > We had a discussion on the two topics during the summit. Here is the etherpad > link for the discussion. > https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit > > We agreed to continue the discussion on Neutron channel on a weekly basis. It > seems UTC 1700 ~ UTC 1800 Tuesday is good for most people. > Another option is UTC 1700 ~ UTC 1800 Friday. > > 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. > > Thanks, > Cathy > > > -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/api > .rst, the following is the CLI version of the Flow Classifier for your > reference: > > neutron flow-classifier-create [-h] > [--description ] > [--protocol ] > [--ethertype ] > [--source-port : protocol port>] > [--destination-port : destination protocol port>] > [--source-ip-prefix ] > [--destination-ip-prefix ] > [--logical-source-port ] > [--logical-destination-port ] > [--l7-parameters ] 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
Sounds good, I started by opening a tiny RFE, that may help in the organization of flows inside OVS agent, for inter operability of features (SFC, TaaS, ovs fw, and even port trunking with just openflow). [1] [2] [1] https://bugs.launchpad.net/neutron/+bug/1577791 [2] http://paste.openstack.org/show/495967/ On Fri, May 6, 2016 at 12:35 AM, Cathy Zhang wrote: > Hi everyone, > > We had a discussion on the two topics during the summit. Here is the etherpad > link for the discussion. > https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit > > We agreed to continue the discussion on Neutron channel on a weekly basis. It > seems UTC 1700 ~ UTC 1800 Tuesday is good for most people. > Another option is UTC 1700 ~ UTC 1800 Friday. > > 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. > > Thanks, > Cathy > > > -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/api.rst, > the following is the CLI version of the Flow Classifier for your reference: > > neutron flow-classifier-create [-h] > [--description ] > [--protocol ] > [--ethertype ] > [--source-port : protocol port>] > [--destination-port : destination protocol port>] > [--source-ip-prefix ] > [--destination-ip-prefix ] > [--logical-source-port ] > [--logical-destination-port ] > [--l7-parameters ] 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. > &
[openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
Hi everyone, We had a discussion on the two topics during the summit. Here is the etherpad link for the discussion. https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit We agreed to continue the discussion on Neutron channel on a weekly basis. It seems UTC 1700 ~ UTC 1800 Tuesday is good for most people. Another option is UTC 1700 ~ UTC 1800 Friday. 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. Thanks, Cathy -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/api.rst, the following is the CLI version of the Flow Classifier for your reference: neutron flow-classifier-create [-h] [--description ] [--protocol ] [--ethertype ] [--source-port :] [--destination-port :] [--source-ip-prefix ] [--destination-ip-prefix ] [--logical-source-port ] [--logical-destination-port ] [--l7-parameters ] 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: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 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, b
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
Hi Miguel, No worry. Today is just a meeting for lunch to get to know each other although we touched some technical points. We will recap and do the technical discussion at Room 400 at 3:10pm Thursday. Cathy From: Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com] Sent: Wednesday, April 27, 2016 10:50 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 Trying to find you folks. I was late El 27/4/2016 12:04, "Paul Carver" mailto:pcar...@paulcarver.us>> escribió: SFC team and anybody else dealing with flow selection/classification (e.g. QoS), I just wanted to confirm that we're planning to meet in salon C today (Wednesday) to get lunch but then possibly move to a quieter location to discuss the common flow classifier ideas. On 4/21/2016 19:42, Cathy Zhang wrote: I like Malini’s suggestion on meeting for a lunch to get to know each other, then continue on Thursday. So let’s meet at "Salon C" for lunch from 12:30pm~1:50pm on Wednesday and then continue the discussion at Room 400 at 3:10pm Thursday. Since Salon C is a big room, I will put a sign “Common Flow Classifier and OVS Agent Extension” on the table. I have created an etherpad for the discussion. https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
Please add me to whatsapp or telegram if you use that : +34636522569 El 27/4/2016 12:50, majop...@redhat.com escribió: > Trying to find you folks. I was late > El 27/4/2016 12:04, "Paul Carver" escribió: > >> SFC team and anybody else dealing with flow selection/classification >> (e.g. QoS), >> >> I just wanted to confirm that we're planning to meet in salon C today >> (Wednesday) to get lunch but then possibly move to a quieter location to >> discuss the common flow classifier ideas. >> >> On 4/21/2016 19:42, Cathy Zhang wrote: >> >>> I like Malini’s suggestion on meeting for a lunch to get to know each >>> other, then continue on Thursday. >>> >>> So let’s meet at "Salon C" for lunch from 12:30pm~1:50pm on Wednesday >>> and then continue the discussion at Room 400 at 3:10pm Thursday. >>> >>> Since Salon C is a big room, I will put a sign “Common Flow Classifier >>> and OVS Agent Extension” on the table. >>> >>> I have created an etherpad for the discussion. >>> https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit >>> >>> >> >> __ >> 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
Trying to find you folks. I was late El 27/4/2016 12:04, "Paul Carver" escribió: > SFC team and anybody else dealing with flow selection/classification (e.g. > QoS), > > I just wanted to confirm that we're planning to meet in salon C today > (Wednesday) to get lunch but then possibly move to a quieter location to > discuss the common flow classifier ideas. > > On 4/21/2016 19:42, Cathy Zhang wrote: > >> I like Malini’s suggestion on meeting for a lunch to get to know each >> other, then continue on Thursday. >> >> So let’s meet at "Salon C" for lunch from 12:30pm~1:50pm on Wednesday >> and then continue the discussion at Room 400 at 3:10pm Thursday. >> >> Since Salon C is a big room, I will put a sign “Common Flow Classifier >> and OVS Agent Extension” on the table. >> >> I have created an etherpad for the discussion. >> https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit >> >> > > __ > 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
SFC team and anybody else dealing with flow selection/classification (e.g. QoS), I just wanted to confirm that we're planning to meet in salon C today (Wednesday) to get lunch but then possibly move to a quieter location to discuss the common flow classifier ideas. On 4/21/2016 19:42, Cathy Zhang wrote: I like Malini’s suggestion on meeting for a lunch to get to know each other, then continue on Thursday. So let’s meet at "Salon C" for lunch from 12:30pm~1:50pm on Wednesday and then continue the discussion at Room 400 at 3:10pm Thursday. Since Salon C is a big room, I will put a sign “Common Flow Classifier and OVS Agent Extension” on the table. I have created an etherpad for the discussion. https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit __ 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
On 04/22/2016 02:42 AM, Cathy Zhang wrote: > So let’s meet at "Salon C" for lunch from 12:30pm~1:50pm on Wednesday > and then continue the discussion at Room 400 at 3:10pm Thursday. > > Since Salon C is a big room, I will put a sign “Common Flow Classifier > and OVS Agent Extension” on the table. > I am also interested in joining the conversation. Wednesday for lunch works for me! __ 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
I like Malini’s suggestion on meeting for a lunch to get to know each other, then continue on Thursday. So let’s meet at "Salon C" for lunch from 12:30pm~1:50pm on Wednesday and then continue the discussion at Room 400 at 3:10pm Thursday. Since Salon C is a big room, I will put a sign “Common Flow Classifier and OVS Agent Extension” on the table. I have created an etherpad for the discussion. https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit Thanks, Cathy From: Stephen Wong [mailto:stephen.kf.w...@gmail.com] Sent: Thursday, April 21, 2016 1:56 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Cathy Zhang; Miguel Angel Ajo; Reedip Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle +1 on Wednesday lunch On Thu, Apr 21, 2016 at 12:02 PM, Ihar Hrachyshka mailto:ihrac...@redhat.com>> wrote: Cathy Zhang mailto:cathy.h.zh...@huawei.com>> wrote: 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. On Monday, I have two talks to do. First one is 2:50-3:30pm, second one is 4:40-5:20pm. But lunch time should probably be fine if it leaves time for the actual lunch... Thursday at 3:10pm also works for me. Ihar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
+1 on Wednesday lunch On Thu, Apr 21, 2016 at 12:02 PM, Ihar Hrachyshka wrote: > Cathy Zhang wrote: > > 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. >> > > On Monday, I have two talks to do. First one is 2:50-3:30pm, second one is > 4:40-5:20pm. But lunch time should probably be fine if it leaves time for > the actual lunch... > > Thursday at 3:10pm also works for me. > > > 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
Cathy Zhang wrote: 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. On Monday, I have two talks to do. First one is 2:50-3:30pm, second one is 4:40-5:20pm. But lunch time should probably be fine if it leaves time for the actual lunch... Thursday at 3:10pm also works for me. 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
I vote for Monday to get the ball rolling, meet the interested parties, and Continue on Thursday at 3:10 in a quieter setting ... so we leave with some consensus. Thanks Cathy! Malini -Original Message- From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com] 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 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/api.rst, the following is the CLI version of the Flow Classifier for your reference: neutron flow-classifier-create [-h] [--description ] [--protocol ] [--ethertype ] [--source-port :] [--destination-port :] [--source-ip-prefix ] [--destination-ip-prefix ] [--logical-source-port ] [--logical-destination-port ] [--l7-parameters ] 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: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 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 modific
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/api.rst, the following is the CLI version of the Flow Classifier for your reference: neutron flow-classifier-create [-h] [--description ] [--protocol ] [--ethertype ] [--source-port :] [--destination-port :] [--source-ip-prefix ] [--destination-ip-prefix ] [--logical-source-port ] [--logical-destination-port ] [--l7-parameters ] 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: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 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 wi
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
On Thu, Apr 21, 2016 at 9:54 AM, Vikram Choudhary wrote: > AFAIK, there is proposal about adding a 'priority' option in the existing > flow classifier rule. This can ensure the rule ordering. > > It's more complicated than that, there you're only considering Flow Classifiers, while we need to make the full pipeline of features (externally pluggable) work together. > On Thu, Apr 21, 2016 at 12:58 PM, IWAMOTO Toshihiro > wrote: >> >> At Wed, 20 Apr 2016 14:12:07 +0200, >> Miguel Angel Ajo Pelayo wrote: >> > >> > I think this is an interesting topic. >> > >> > What do you mean exactly by FC ? (feature chaining?) >> > >> > I believe we have three things to look at: (sorry for the TL) >> > >> > 1) The generalization of traffic filters / traffic classifiers. Having >> > common models, some sort of common API or common API structure >> > available, and translators to convert those filters to iptables, >> > openflow filters, etc.. >> > >> > 2) The enhancement of extensiblity of agents via Extension API. >> > >> > 3) How we chain features in OpenFlow, which current approach of just >> > inserting rules, renders into incompatible extensions. This becomes >> > specially relevant for the new openvswitch firewall. >> > >> > 2 and 3 are interlinked, and a good mechanism to enhance (3) should be >> > provided in (2). >> > >> > We need to resolve: >> > >> > a) The order of tables, and how openflow actions chain the >> > different features in the pipeline. Some naive thinking brings me >> > into the idea that we need to identify different input/output stages >> > of packet processing, and every feature/extension declares the point >> > where it needs to be. And then when we have all features, every >> > feature get's it's own table number, and the "next" action in >> > pipeline. >> >> Can we create an API that allocates flow insertion points and table >> numbers? How can we ensure correct ordering of flows? I believe that just an API to allocate flow insertion points and table numbers wouldn't work, because, you need to get the "next" hop in the table, and the next hop would not be still resolved when you ask for it (may be yes, if we return a mutable object). The idea, is than when all features are declared and inspected, we have the next hops, and table numbers for all features. Also another API for requesting openflow registers would be necessary, as extensions consume registers for different purposes. >> IMHO, it might be a time to collect low-level flow operation functions >> into a single repository and test interoperability there. >> That's may be something we must consider, I don't completely disagree, but if we can find a way to solve the issue dynamically, that would lead to quicker evolution, and easy interoperability with out-of-our-trees solutions, and cross version compatibility. >> > b) We need to have a way to request openflow registers to use in >> > extensions, so one extension doesn't overwrite other's registers >> > >> >c) Those registers need to be given a logical names that other >> > extensions can query for (for example "port_number", "local_zone", >> > etc..) , and those standard registers should be filled in for all >> > extensions at the input stage. >> > >> >and probably c,d,e,f,g,h what I didn't manage to think of. >> > >> > On Fri, Apr 15, 2016 at 11:13 PM, Cathy Zhang >> > wrote: >> > > Hi Reedip, >> > > >> > > >> > > >> > > Sure will include you in the discussion. Let me know if there are >> > > other >> > > Tap-as-a-Service members who would like to join this initiative. >> > > >> > > >> > > >> > > Cathy >> > > >> > > >> > > >> > > From: reedip banerjee [mailto:reedi...@gmail.com] >> > > Sent: Thursday, April 14, 2016 7:03 PM >> > > 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 >> > > >> > > >> > > >> > > Speaking on behalf of Tap-as-a-Service members, we would also be very >> > > much >> > > interested in the following initiative :) >> > >
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
AFAIK, there is proposal about adding a 'priority' option in the existing flow classifier rule. This can ensure the rule ordering. On Thu, Apr 21, 2016 at 12:58 PM, IWAMOTO Toshihiro wrote: > At Wed, 20 Apr 2016 14:12:07 +0200, > Miguel Angel Ajo Pelayo wrote: > > > > I think this is an interesting topic. > > > > What do you mean exactly by FC ? (feature chaining?) > > > > I believe we have three things to look at: (sorry for the TL) > > > > 1) The generalization of traffic filters / traffic classifiers. Having > > common models, some sort of common API or common API structure > > available, and translators to convert those filters to iptables, > > openflow filters, etc.. > > > > 2) The enhancement of extensiblity of agents via Extension API. > > > > 3) How we chain features in OpenFlow, which current approach of just > > inserting rules, renders into incompatible extensions. This becomes > > specially relevant for the new openvswitch firewall. > > > > 2 and 3 are interlinked, and a good mechanism to enhance (3) should be > > provided in (2). > > > > We need to resolve: > > > > a) The order of tables, and how openflow actions chain the > > different features in the pipeline. Some naive thinking brings me > > into the idea that we need to identify different input/output stages > > of packet processing, and every feature/extension declares the point > > where it needs to be. And then when we have all features, every > > feature get's it's own table number, and the "next" action in > > pipeline. > > Can we create an API that allocates flow insertion points and table > numbers? How can we ensure correct ordering of flows? > IMHO, it might be a time to collect low-level flow operation functions > into a single repository and test interoperability there. > > > b) We need to have a way to request openflow registers to use in > > extensions, so one extension doesn't overwrite other's registers > > > >c) Those registers need to be given a logical names that other > > extensions can query for (for example "port_number", "local_zone", > > etc..) , and those standard registers should be filled in for all > > extensions at the input stage. > > > >and probably c,d,e,f,g,h what I didn't manage to think of. > > > > On Fri, Apr 15, 2016 at 11:13 PM, Cathy Zhang > wrote: > > > Hi Reedip, > > > > > > > > > > > > Sure will include you in the discussion. Let me know if there are other > > > Tap-as-a-Service members who would like to join this initiative. > > > > > > > > > > > > Cathy > > > > > > > > > > > > From: reedip banerjee [mailto:reedi...@gmail.com] > > > Sent: Thursday, April 14, 2016 7:03 PM > > > 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 > > > > > > > > > > > > Speaking on behalf of Tap-as-a-Service members, we would also be very > much > > > interested in the following initiative :) > > > > > > > > > > > > On Fri, Apr 15, 2016 at 5:14 AM, Ihar Hrachyshka > > > wrote: > > > > > > Cathy Zhang wrote: > > > > > > > > > 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. > > > > > > > > > Sorry, I probably used misleading wording. I meant, why do we consider > the > > > semantic flow management support in l2 agent extension framework a > > > *prerequisite* for SFC to switch to l2 agent ext
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
At Wed, 20 Apr 2016 14:12:07 +0200, Miguel Angel Ajo Pelayo wrote: > > I think this is an interesting topic. > > What do you mean exactly by FC ? (feature chaining?) > > I believe we have three things to look at: (sorry for the TL) > > 1) The generalization of traffic filters / traffic classifiers. Having > common models, some sort of common API or common API structure > available, and translators to convert those filters to iptables, > openflow filters, etc.. > > 2) The enhancement of extensiblity of agents via Extension API. > > 3) How we chain features in OpenFlow, which current approach of just > inserting rules, renders into incompatible extensions. This becomes > specially relevant for the new openvswitch firewall. > > 2 and 3 are interlinked, and a good mechanism to enhance (3) should be > provided in (2). > > We need to resolve: > > a) The order of tables, and how openflow actions chain the > different features in the pipeline. Some naive thinking brings me > into the idea that we need to identify different input/output stages > of packet processing, and every feature/extension declares the point > where it needs to be. And then when we have all features, every > feature get's it's own table number, and the "next" action in > pipeline. Can we create an API that allocates flow insertion points and table numbers? How can we ensure correct ordering of flows? IMHO, it might be a time to collect low-level flow operation functions into a single repository and test interoperability there. > b) We need to have a way to request openflow registers to use in > extensions, so one extension doesn't overwrite other's registers > >c) Those registers need to be given a logical names that other > extensions can query for (for example "port_number", "local_zone", > etc..) , and those standard registers should be filled in for all > extensions at the input stage. > >and probably c,d,e,f,g,h what I didn't manage to think of. > > On Fri, Apr 15, 2016 at 11:13 PM, Cathy Zhang > wrote: > > Hi Reedip, > > > > > > > > Sure will include you in the discussion. Let me know if there are other > > Tap-as-a-Service members who would like to join this initiative. > > > > > > > > Cathy > > > > > > > > From: reedip banerjee [mailto:reedi...@gmail.com] > > Sent: Thursday, April 14, 2016 7:03 PM > > 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 > > > > > > > > Speaking on behalf of Tap-as-a-Service members, we would also be very much > > interested in the following initiative :) > > > > > > > > On Fri, Apr 15, 2016 at 5:14 AM, Ihar Hrachyshka > > wrote: > > > > Cathy Zhang wrote: > > > > > > 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. > > > > > > Sorry, I probably used misleading wording. I meant, why do we consider the > > semantic flow management support in l2 agent extension framework a > > *prerequisite* for SFC to switch to l2 agent extensions? The existing > > framework should already allow SFC to achieve what you have in the > > subproject tree implemented as a separate agent (essentially a fork of OVS > > agent). It will also set SFC to use standard extension mechanisms instead of > > hacky inheritance from OVS agent classes. So even without the strict > > semantic flow management, there is benefit for the subproject. > > > > With that in mind, I would split this job into 3 pieces: > > * first, adopt l2 agent extension mechanism for SFC functionality (dropping > > custom agent); > > * then, work on semantic flow management support in OVS agent API class [1]; > > * once the feature emerges, s
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
I think this is an interesting topic. What do you mean exactly by FC ? (feature chaining?) I believe we have three things to look at: (sorry for the TL) 1) The generalization of traffic filters / traffic classifiers. Having common models, some sort of common API or common API structure available, and translators to convert those filters to iptables, openflow filters, etc.. 2) The enhancement of extensiblity of agents via Extension API. 3) How we chain features in OpenFlow, which current approach of just inserting rules, renders into incompatible extensions. This becomes specially relevant for the new openvswitch firewall. 2 and 3 are interlinked, and a good mechanism to enhance (3) should be provided in (2). We need to resolve: a) The order of tables, and how openflow actions chain the different features in the pipeline. Some naive thinking brings me into the idea that we need to identify different input/output stages of packet processing, and every feature/extension declares the point where it needs to be. And then when we have all features, every feature get's it's own table number, and the "next" action in pipeline. b) We need to have a way to request openflow registers to use in extensions, so one extension doesn't overwrite other's registers c) Those registers need to be given a logical names that other extensions can query for (for example "port_number", "local_zone", etc..) , and those standard registers should be filled in for all extensions at the input stage. and probably c,d,e,f,g,h what I didn't manage to think of. On Fri, Apr 15, 2016 at 11:13 PM, Cathy Zhang wrote: > Hi Reedip, > > > > Sure will include you in the discussion. Let me know if there are other > Tap-as-a-Service members who would like to join this initiative. > > > > Cathy > > > > From: reedip banerjee [mailto:reedi...@gmail.com] > Sent: Thursday, April 14, 2016 7:03 PM > 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 > > > > Speaking on behalf of Tap-as-a-Service members, we would also be very much > interested in the following initiative :) > > > > On Fri, Apr 15, 2016 at 5:14 AM, Ihar Hrachyshka > wrote: > > Cathy Zhang wrote: > > > 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. > > > Sorry, I probably used misleading wording. I meant, why do we consider the > semantic flow management support in l2 agent extension framework a > *prerequisite* for SFC to switch to l2 agent extensions? The existing > framework should already allow SFC to achieve what you have in the > subproject tree implemented as a separate agent (essentially a fork of OVS > agent). It will also set SFC to use standard extension mechanisms instead of > hacky inheritance from OVS agent classes. So even without the strict > semantic flow management, there is benefit for the subproject. > > With that in mind, I would split this job into 3 pieces: > * first, adopt l2 agent extension mechanism for SFC functionality (dropping > custom agent); > * then, work on semantic flow management support in OVS agent API class [1]; > * once the feature emerges, switch SFC l2 agent extension to the new > framework to manage SFC flows. > > I would at least prioritize the first point and target it to Newton-1. Other > bullet points may take significant time to bake. > > [1] > https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_agent_extension_api.py > > > > 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 > > > > > > -- > > Thanks and Regards, > Reedip Baner
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
Sorry, I just saw, FC = flow classifier :-), I made it a multi purpose abrev. now ;) On Wed, Apr 20, 2016 at 2:12 PM, Miguel Angel Ajo Pelayo wrote: > I think this is an interesting topic. > > What do you mean exactly by FC ? (feature chaining?) > > I believe we have three things to look at: (sorry for the TL) > > 1) The generalization of traffic filters / traffic classifiers. Having > common models, some sort of common API or common API structure > available, and translators to convert those filters to iptables, > openflow filters, etc.. > > 2) The enhancement of extensiblity of agents via Extension API. > > 3) How we chain features in OpenFlow, which current approach of just > inserting rules, renders into incompatible extensions. This becomes > specially relevant for the new openvswitch firewall. > > 2 and 3 are interlinked, and a good mechanism to enhance (3) should be > provided in (2). > > We need to resolve: > > a) The order of tables, and how openflow actions chain the > different features in the pipeline. Some naive thinking brings me > into the idea that we need to identify different input/output stages > of packet processing, and every feature/extension declares the point > where it needs to be. And then when we have all features, every > feature get's it's own table number, and the "next" action in > pipeline. > > b) We need to have a way to request openflow registers to use in > extensions, so one extension doesn't overwrite other's registers > >c) Those registers need to be given a logical names that other > extensions can query for (for example "port_number", "local_zone", > etc..) , and those standard registers should be filled in for all > extensions at the input stage. > >and probably c,d,e,f,g,h what I didn't manage to think of. > > On Fri, Apr 15, 2016 at 11:13 PM, Cathy Zhang > wrote: >> Hi Reedip, >> >> >> >> Sure will include you in the discussion. Let me know if there are other >> Tap-as-a-Service members who would like to join this initiative. >> >> >> >> Cathy >> >> >> >> From: reedip banerjee [mailto:reedi...@gmail.com] >> Sent: Thursday, April 14, 2016 7:03 PM >> 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 >> >> >> >> Speaking on behalf of Tap-as-a-Service members, we would also be very much >> interested in the following initiative :) >> >> >> >> On Fri, Apr 15, 2016 at 5:14 AM, Ihar Hrachyshka >> wrote: >> >> Cathy Zhang wrote: >> >> >> 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. >> >> >> Sorry, I probably used misleading wording. I meant, why do we consider the >> semantic flow management support in l2 agent extension framework a >> *prerequisite* for SFC to switch to l2 agent extensions? The existing >> framework should already allow SFC to achieve what you have in the >> subproject tree implemented as a separate agent (essentially a fork of OVS >> agent). It will also set SFC to use standard extension mechanisms instead of >> hacky inheritance from OVS agent classes. So even without the strict >> semantic flow management, there is benefit for the subproject. >> >> With that in mind, I would split this job into 3 pieces: >> * first, adopt l2 agent extension mechanism for SFC functionality (dropping >> custom agent); >> * then, work on semantic flow management support in OVS agent API class [1]; >> * once the feature emerges, switch SFC l2 agent extension to the new >> framework to manage SFC flows. >> >> I would at least prioritize the first point and target it to Newton-1. Other >> bu
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
Hi Reedip, Sure will include you in the discussion. Let me know if there are other Tap-as-a-Service members who would like to join this initiative. Cathy From: reedip banerjee [mailto:reedi...@gmail.com] Sent: Thursday, April 14, 2016 7:03 PM 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 Speaking on behalf of Tap-as-a-Service members, we would also be very much interested in the following initiative :) On Fri, Apr 15, 2016 at 5:14 AM, Ihar Hrachyshka mailto:ihrac...@redhat.com>> wrote: Cathy Zhang mailto:cathy.h.zh...@huawei.com>> wrote: 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. Sorry, I probably used misleading wording. I meant, why do we consider the semantic flow management support in l2 agent extension framework a *prerequisite* for SFC to switch to l2 agent extensions? The existing framework should already allow SFC to achieve what you have in the subproject tree implemented as a separate agent (essentially a fork of OVS agent). It will also set SFC to use standard extension mechanisms instead of hacky inheritance from OVS agent classes. So even without the strict semantic flow management, there is benefit for the subproject. With that in mind, I would split this job into 3 pieces: * first, adopt l2 agent extension mechanism for SFC functionality (dropping custom agent); * then, work on semantic flow management support in OVS agent API class [1]; * once the feature emerges, switch SFC l2 agent extension to the new framework to manage SFC flows. I would at least prioritize the first point and target it to Newton-1. Other bullet points may take significant time to bake. [1] https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_agent_extension_api.py Ihar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks and Regards, Reedip Banerjee IRC: reedip __ 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
Hi Ihar, My replies are inline. Thanks, Cathy -Original Message- From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] Sent: Thursday, April 14, 2016 4:45 PM To: Cathy Zhang Cc: OpenStack Development Mailing List (not for usage questions); Vikram Choudhary; Sean M. Collins; Haim Daniel; Mathieu Rohon; Shaughnessy, David; Eichberger, German; Henry Fourie; Armando M. Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle Cathy Zhang wrote: > > 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. Sorry, I probably used misleading wording. I meant, why do we consider the semantic flow management support in l2 agent extension framework a *prerequisite* for SFC to switch to l2 agent extensions? The existing framework should already allow SFC to achieve what you have in the subproject tree implemented as a separate agent (essentially a fork of OVS agent). It will also set SFC to use standard extension mechanisms instead of hacky inheritance from OVS agent classes. So even without the strict semantic flow management, there is benefit for the subproject. Cathy> Yes, the existing extension mechanism with Bridge wrapper and cookie is a step forward for subprojects. With that in mind, I would split this job into 3 pieces: * first, adopt l2 agent extension mechanism for SFC functionality (dropping custom agent); * then, work on semantic flow management support in OVS agent API class [1]; * once the feature emerges, switch SFC l2 agent extension to the new framework to manage SFC flows. I would at least prioritize the first point and target it to Newton-1. Other bullet points may take significant time to bake. Cathy> Good suggestion. We can do this in steps. Previously we were thinking about waiting until strict flow management is supported in the extension. Thanks, Cathy [1] https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_agent_extension_api.py 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
Speaking on behalf of Tap-as-a-Service members, we would also be very much interested in the following initiative :) On Fri, Apr 15, 2016 at 5:14 AM, Ihar Hrachyshka wrote: > Cathy Zhang wrote: > > >> 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. >> > > Sorry, I probably used misleading wording. I meant, why do we consider the > semantic flow management support in l2 agent extension framework a > *prerequisite* for SFC to switch to l2 agent extensions? The existing > framework should already allow SFC to achieve what you have in the > subproject tree implemented as a separate agent (essentially a fork of OVS > agent). It will also set SFC to use standard extension mechanisms instead > of hacky inheritance from OVS agent classes. So even without the strict > semantic flow management, there is benefit for the subproject. > > With that in mind, I would split this job into 3 pieces: > * first, adopt l2 agent extension mechanism for SFC functionality > (dropping custom agent); > * then, work on semantic flow management support in OVS agent API class > [1]; > * once the feature emerges, switch SFC l2 agent extension to the new > framework to manage SFC flows. > > I would at least prioritize the first point and target it to Newton-1. > Other bullet points may take significant time to bake. > > [1] > https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_agent_extension_api.py > > > 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 > -- Thanks and Regards, Reedip Banerjee IRC: reedip __ 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
Cathy Zhang wrote: 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. Sorry, I probably used misleading wording. I meant, why do we consider the semantic flow management support in l2 agent extension framework a *prerequisite* for SFC to switch to l2 agent extensions? The existing framework should already allow SFC to achieve what you have in the subproject tree implemented as a separate agent (essentially a fork of OVS agent). It will also set SFC to use standard extension mechanisms instead of hacky inheritance from OVS agent classes. So even without the strict semantic flow management, there is benefit for the subproject. With that in mind, I would split this job into 3 pieces: * first, adopt l2 agent extension mechanism for SFC functionality (dropping custom agent); * then, work on semantic flow management support in OVS agent API class [1]; * once the feature emerges, switch SFC l2 agent extension to the new framework to manage SFC flows. I would at least prioritize the first point and target it to Newton-1. Other bullet points may take significant time to bake. [1] https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_agent_extension_api.py 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
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 ] [--protocol ] [--ethertype ] [--source-port :] [--destination-port :] [--source-ip-prefix ] [--destination-ip-prefix ] [--logical-source-port ] [--logical-destination-port ] [--l7-parameters ] 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: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 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-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...@li
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
Just to echo others: FWaaS would be interested in this as well so please keep us in the loop. Thanks, German On 4/14/16, 7:12 AM, "Sean M. Collins" wrote: >Vikram Choudhary wrote: >> Hi Cathy, >> >> A project called "neutron-classifier [1]" is also there addressing the same >> use case. Let's sync up and avoid work duplicity. >> >> [1] https://github.com/openstack/neutron-classifier > >Agree with Vikram - we have a small git repo that we're using to futz >around with ideas around how to store classifiers in a way that is >re-usable by other projects, and create a decent object model. > >It's very very rough, and the API is ... kind of ugly right now. That's >what you get when I steal like 4 Red Bulls and do an all-night coding >session in Tokyo. > >So, It'd be great to get other people involved, get an API hashed out >that doesn't expose all the nitty gritty DB details (like it currently >is) and move forward. > >-- >Sean M. Collins > >__ >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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
Vikram Choudhary wrote: > Hi Cathy, > > A project called "neutron-classifier [1]" is also there addressing the same > use case. Let's sync up and avoid work duplicity. > > [1] https://github.com/openstack/neutron-classifier Agree with Vikram - we have a small git repo that we're using to futz around with ideas around how to store classifiers in a way that is re-usable by other projects, and create a decent object model. It's very very rough, and the API is ... kind of ugly right now. That's what you get when I steal like 4 Red Bulls and do an all-night coding session in Tokyo. So, It'd be great to get other people involved, get an API hashed out that doesn't expose all the nitty gritty DB details (like it currently is) and move forward. -- Sean M. Collins __ 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
Hi Cathy. I’d be interested in contributing. I think a meet up at the summit would be a good idea as the people I’ve engaged with from the other projects on this topic expressed interest. There was an etherpad for the l2-agent-extensions-api that was merged in Mitaka that listed projects that needed access to the flow table[1]. Hope you find it helpful. Regards. David. [1] https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion From: Mathieu Rohon [mailto:mathieu.ro...@gmail.com] Sent: Thursday, April 14, 2016 10:05 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 Hi cathy, at net-bgpvpn, we're very interested in this effort. Please, keep us in the loop. Mathieu On Thu, Apr 14, 2016 at 8:59 AM, Haim Daniel mailto:hdan...@redhat.com>> wrote: Hi, I'd +1 Vikram's comment on neutron-classifier , RFE [1] contains the original thread about that topic. [1] https://bugs.launchpad.net/neutron/+bug/1527671 On Thu, Apr 14, 2016 at 5:33 AM, Vikram Choudhary mailto:viks...@gmail.com>> wrote: Hi Cathy, A project called "neutron-classifier [1]" is also there addressing the same use case. Let's sync up and avoid work duplicity. [1] https://github.com/openstack/neutron-classifier Thanks Vikram On Apr 14, 2016 6:40 AM, "Cathy Zhang" mailto: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. 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. 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. Thanks, Cathy __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. __ 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
Cathy Zhang 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. 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
Hi cathy, at net-bgpvpn, we're very interested in this effort. Please, keep us in the loop. Mathieu On Thu, Apr 14, 2016 at 8:59 AM, Haim Daniel wrote: > Hi, > > I'd +1 Vikram's comment on neutron-classifier , RFE [1] contains the > original thread about that topic. > > > [1] https://bugs.launchpad.net/neutron/+bug/1527671 > > On Thu, Apr 14, 2016 at 5:33 AM, Vikram Choudhary > wrote: > >> Hi Cathy, >> >> A project called "neutron-classifier [1]" is also there addressing the >> same use case. Let's sync up and avoid work duplicity. >> >> [1] https://github.com/openstack/neutron-classifier >> >> Thanks >> Vikram >> On Apr 14, 2016 6:40 AM, "Cathy Zhang" 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. >> >> 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. >> >> 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. >> >> Thanks, >> >> Cathy >> >> __ >> 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
Hi, I'd +1 Vikram's comment on neutron-classifier , RFE [1] contains the original thread about that topic. [1] https://bugs.launchpad.net/neutron/+bug/1527671 On Thu, Apr 14, 2016 at 5:33 AM, Vikram Choudhary wrote: > Hi Cathy, > > A project called "neutron-classifier [1]" is also there addressing the > same use case. Let's sync up and avoid work duplicity. > > [1] https://github.com/openstack/neutron-classifier > > Thanks > Vikram > On Apr 14, 2016 6:40 AM, "Cathy Zhang" 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. > > 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. > > 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. > > Thanks, > > Cathy > > __ > 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
Hi Cathy, A project called "neutron-classifier [1]" is also there addressing the same use case. Let's sync up and avoid work duplicity. [1] https://github.com/openstack/neutron-classifier Thanks Vikram On Apr 14, 2016 6:40 AM, "Cathy Zhang" 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. 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. 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. Thanks, Cathy __ 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-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
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. 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. 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. Thanks, Cathy __ 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