Re: [sfc-dev] [OpenDaylight TSC] [release] TSC Vote for moving SFC to a self managed project

[Anil Vishnoi]

I believe it's not a matter of few test failing. It's pretty much dead code
in my opinion and i have a doubt that even it's basic usecase is working
anymore.
Now do we want to keep shipping this dead code and support it for next 1
year (6 month stable support, 6 month security support)? I am not sure if
there is anyone to support this code even in self-managed mode. If removing
this code from managed project delays the relase by a week (nothing new in
ODL history, we did it many times, many reasons ), in my person opinion, we
should just do it.

On Mon, Sep 16, 2019 at 6:42 AM Thanh ha  wrote:

> I agree here. It seems wrong to me to remove it from Sodium this late into
> the release cycle unless we really want to delay the release some more. In
> the initial email thread this list Stephen's patch
> https://git.opendaylight.org/gerrit/c/netvirt/+/84369 will remove it from
> netvirt but this would require that to be merged and then we need to respin
> everything.
>
> Could we maybe release note the SFC test failure for Sodium and mention
> that it is marked for removal as a managed project in Magnesium?
>
> That would at least flag to the users that SFC has known issues and we can
> likely proceed with the release.
>
> Regards,
> Thanh
>
> On Mon, 16 Sep 2019 at 07:40, Abhijit Kumbhare 
> wrote:
>
>> Thanks for the feedback Robert and Daniel. We do need to disable SFC from
>> NetVirt, right? Isn't there an engineering effort required for that? Or is
>> it OK to ship with those tests failing?
>>
>> On Sun, Sep 15, 2019 at 10:41 PM Daniel De La Rosa <
>> ddelar...@luminanetworks.com> wrote:
>>
>>>
>>>
>>> On Sun, Sep 15, 2019 at 10:28 PM Robert Varga  wrote:
>>>
 On 16/09/2019 06:34, Abhijit Kumbhare wrote:
 > Hello TSC,
 >
 > There was a discussion in the TSC meeting to move SFC project to be a
 > self managed project for Sodium as SFC members have mostly moved on
 and
 > have also not attended any TSC meetings. Subsequently we also sent an
 > email to the SFC project titled "SFC and Sodium". Since there was no
 > response, it is time for the TSC to vote on whether SFC should be
 > removed from the Sodium release.
 >
 > *Hence please vote either -1, 0 or +1 for the following question:*
 > *
 > *
 > *Shall SFC be removed from Sodium as a managed project and be
 considered
 > as a self managed project? Note - this will likely need us to remove
 it
 > from the Sodium distribution.*

 -1.

 The release is ready, this would require a re-spin and re-signoff for a
 release that is already 11 days late.

 What is the (very strong) reason to even be considering this?

>>>
>>> I don't think there is one and I thought that we talked about doing this
>>> ( and other) projects to self managed for magnesium in the TSC meeting. I
>>> think is better to keep Sodium release date on time but start working on
>>> this ASAP for Magnesium
>>>
>>> my two pesos
>>>
>>>

 FTR: I strongly believe this pruning should have happened at the Final
 Checkpoint at the latest -- i.e. a month ago.

 Regards,
 Robert

 -=-=-=-=-=-=-=-=-=-=-=-
 Links: You receive all messages sent to this group.

 View/Reply Online (#18011):
 https://lists.opendaylight.org/g/release/message/18011
 Mute This Topic: https://lists.opendaylight.org/mt/34161125/1964961
 Group Owner: release+ow...@lists.opendaylight.org
 Unsubscribe: https://lists.opendaylight.org/g/release/unsub  [
 ddelar...@luminanetworks.com]
 -=-=-=-=-=-=-=-=-=-=-=-

>>>
>>>
>>> --
>>> Daniel de la Rosa
>>> Customer Support Manager
>>> Lumina Networks Inc.
>>> e: ddelar...@luminanetworks.com
>>> m:  +1 408 7728120
>>>
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>>
>> View/Reply Online (#11900):
>> https://lists.opendaylight.org/g/TSC/message/11900
>> Mute This Topic: https://lists.opendaylight.org/mt/34161393/1869318
>> Group Owner: tsc+ow...@lists.opendaylight.org
>> Unsubscribe: https://lists.opendaylight.org/g/TSC/unsub  [
>> zxi...@gmail.com]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#18017):
> https://lists.opendaylight.org/g/release/message/18017
> Mute This Topic: https://lists.opendaylight.org/mt/34164484/1199232
> Group Owner: release+ow...@lists.opendaylight.org
> Unsubscribe: https://lists.opendaylight.org/g/release/unsub  [
> vishnoia...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>


-- 
Thanks
Anil
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4777): https://lists.opendaylight.org/g/sfc-dev/message/4777
Mute This Topic: https://lists.opendaylight.org/mt/34176435/21656
Group Owner: sfc-dev+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/sfc-dev/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [sfc-dev] [release] TSC Vote for moving SFC to a self managed project

[Anil Vishnoi]

+1

Thanks / Anil

> On Sep 15, 2019, at 9:34 PM, Abhijit Kumbhare  wrote:
> 
> Hello TSC,
> 
> There was a discussion in the TSC meeting to move SFC project to be a self 
> managed project for Sodium as SFC members have mostly moved on and have also 
> not attended any TSC meetings. Subsequently we also sent an email to the SFC 
> project titled "SFC and Sodium". Since there was no response, it is time for 
> the TSC to vote on whether SFC should be removed from the Sodium release.
> 
> Hence please vote either -1, 0 or +1 for the following question:
> 
> Shall SFC be removed from Sodium as a managed project and be considered as a 
> self managed project? Note - this will likely need us to remove it from the 
> Sodium distribution.
> 
> My vote: +1 (i.e. SFC should be removed as a managed project and be 
> considered as a self managed project).
> 
> Thanks,
> Abhijit
> 
> 
> Stephen KittFri, Sep 13, 2019 at 12:45 AM
> To: JamO Luhrsen 
> Cc: Abhijit Kumbhare , 
> "sfc-dev@lists.opendaylight.org" , 
> "netvirt-...@lists.opendaylight.org" , 
> Srinivas Rachakonda , Jaya 
> Priyadarshini , Abhishek Nagori 
> , "integration-...@lists.opendaylight.org" 
> , Daniel De La Rosa 
> , Faseela K , Anil 
> Belur 
> I added a kill-switch for the SFC dependency in NetVirt the last time
> we ran into similar issues, so disabling SFC is straightforward:
> https://git.opendaylight.org/gerrit/c/netvirt/+/84369
> 
> Regards,
> 
> Stephen
> 
> 
> On Thu, Sep 12, 2019 at 10:27:28PM -0700, JamO Luhrsen wrote:
> > I think it's time to get SFC out of our managed projects list. It really
> > only remained all this time because of netvirt's dependency on it.
> > 
> > However, I don't know if we want to try to do this for Sodium, do we?
> > Or is it already decoupled from netvirt?
> > 
> > JamO
> > 
> > On 9/12/19 3:39 PM, Abhijit Kumbhare wrote:
> > > Hi SFC team,
> > > 
> > > During the TSC meeting today we discussed this issue as well as SFC in
> > > general. We decided to remove the SFC dependency and SFC tests from the
> > > NetVirt project. However, I would like to ask a broader question. Given
> > > that most of you are not full time on the project, do you folks want to
> > > remove SFC from being a managed project from Sodium? In that case you
> > > can turn it into a self managed project - and can be included if you
> > > desire using the lightweight self managed process. Alternatively as a
> > > self managed project you can also remove it from Sodium altogether. You
> > > do not have to do the SRs if you are a self managed project, but if
> > > support is unlikely to happen, then it will be cleaner to not have SFC
> > > in the release in the first place.
> > > 
> > > In either case, in case you want to move SFC to self managed, we will
> > > need to move fast as the release is already due. Please let us know
> > > right away.
> > > 
> > > Thanks,
> > > Abhijit
> > > 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#18007): 
> https://lists.opendaylight.org/g/release/message/18007
> Mute This Topic: https://lists.opendaylight.org/mt/34161125/1199232
> Group Owner: release+ow...@lists.opendaylight.org
> Unsubscribe: https://lists.opendaylight.org/g/release/unsub  
> [vishnoia...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4775): https://lists.opendaylight.org/g/sfc-dev/message/4775
Mute This Topic: https://lists.opendaylight.org/mt/34176436/21656
Group Owner: sfc-dev+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/sfc-dev/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [sfc-dev] [netvirt-dev] Enabling netvirt karaf4 and dependencies in integration/distribution

[Anil Vishnoi]

Option 2 might be quicker than option 1, but probably it's good to consult
integration team for their opinion.

On Mon, Jun 26, 2017 at 10:25 PM, Vishal Thapar 
wrote:

> Hi all,
>
>
>
> Thanks for the efforts to get karaf4 patches for Netvirt and all its
> dependencies merged, esp the ones who stretched over weekend. Next step is
> now to enable it in nitration/distribution so we can have regular CSIT back
> on track. As per discussions in yesterday’s Nitrogen sync [0], Offset0
> projects will be enabled around 9am PST Tuesday [06/27]. Once they’re in
> individual projects will have to add themselves back in. This means we will
> once again start long wait for dependencies to come in one by one.
>
>
>
> The order would be something like this:
>
>
>
>1. OFJava, OVSDB
>2. OFPlugin
>3. Genius
>4. SFC [not aware of any other SFC dependencies, Dlux?]
>5. Netvirt
>
>
>
> To expedite this I propose two options:
>
>
>
> Option1: Have patches for each of these projects up and ready to merge so
> they can go in quick succession. Since these would be in
> integration/distribution we don’t really need individual projects’
> committers to +2.
>
>
>
> Option2: Once offset0 are all in, create a single patch enabling all these
> together in one shot.
>
>
>
> Thoughts/Suggestions?
>
>
>
> Regards,
>
> Vishal.
>
>
>
> [0] https://meetings.opendaylight.org/opendaylight-meeting/2017/
> nitrogen_release_sync/opendaylight-meeting-nitrogen_
> release_sync.2017-06-26-15.00.html
>
> ___
> netvirt-dev mailing list
> netvirt-...@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/netvirt-dev
>
>


-- 
Thanks
Anil
___
sfc-dev mailing list
sfc-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

Re: [sfc-dev] [openflowplugin-dev] br-sfc become slave and disconnect from ODL

[Anil Vishnoi]

Hi Mohamed,

Looks like plugin is sending the role request to the switch (br-sfc) but
switch is not accepting it and then plugin give up after 10 seconds or so.
Can you capture the wireshark trace where your switch is running? This will
give us some insight on what request controller is sending and why switch
is not responding properly. Also please fire ovsdb-client dump command on
the machine where OVS is running and provide the output.

If the switch won't accept the master role, plugin can't configure any
flow/group/meter on that switch, so we need to see why switch is acting
this way.

On Thu, Mar 9, 2017 at 2:21 PM, Mohamed ElSerngawy 
wrote:

> Hi Jamo,
>
> I confirm it also happen with ODL Carbon distribution (the one u sent
> above) . I created a bug at [0] for it.
>
> [0] https://bugs.opendaylight.org/show_bug.cgi?id=7948
>
> Thanks
>
> On Thu, Mar 9, 2017 at 3:50 PM, Jamo Luhrsen  wrote:
>
>> Mohamed,
>>
>> would you have time for two things?
>>
>> a) could you try your test with a recent Carbon distribution? here's one
>> [0]
>>
>> b) could you open a bug in openflowplugin?
>>
>>
>> for a) if we can show that it's happening in Carbon, easily with your
>> steps,
>> and in addition to the fact that we saw it in our upstream CSIT which is
>> doing
>> pretty normal user facing tests, we can potentially push harder for a fix
>> on b)
>>
>> Thanks,
>> JamO
>>
>> [0]
>> https://nexus.opendaylight.org/content/repositories/opendayl
>> ight.snapshot/org/opendaylight/integration/distribution-
>> karaf/0.6.0-SNAPSHOT/distribution-karaf-0.6.0-20170309.102115-4296.zip
>>
>>
>> On 03/09/2017 09:37 AM, Abhijit Kumbhare wrote:
>> > Thanks for your instructions on how to replicate the issue. We
>> discussed this in the meeting today - however there are
>> > several clustering related issues - so Jozef & Tomas will look at this
>> the next week. In the meantime - if there is any other
>> > volunteer who wants to help out on these OpenFlow clustering related
>> issues - you are always welcome :)
>> >
>> >
>> >
>> > On Thu, Mar 9, 2017 at 9:15 AM, Mohamed ElSerngawy <
>> melserng...@inocybe.ca > wrote:
>> >
>> > Hi Brady,
>> >
>> > Thanks for your response, I agree it is OpenflowPlugin issue. In
>> fact, I tried to reproduced it with only Openflowplugin
>> > feature installed but it didn't come up from the first time, but
>> now I tried again with
>> > only odl-openflowplugin-flow-services-ui installed in ODL and it
>> show up every time.
>> >
>> > Hi Openflowplugin Team,
>> >
>> > Can anyone advice on the issue we mentioned above, I can reproduce
>> it every time I go through same procedures.
>> >
>> > Thanks
>> >
>> >
>> >
>> >
>> > On Thu, Mar 9, 2017 at 8:19 AM, Brady Allen Johnson <
>> brady.allen.john...@ericsson.com
>> > > wrote:
>> >
>> >
>> > Mohamed,
>> >
>> > Sorry to hear the demo isnt working well for you in Boron. I
>> havent tried it in Boron lately, but have used it
>> > successfully recently in master (Carbon). Do you have to use
>> Boron, or can you switch to Carbon?
>> >
>> > I'll try running it from Boron now. I'll let you know how it
>> goes for me in Boron. Either way, it looks like the
>> > problem is in the OpenflowPlugin, and Im not sure we'll be able
>> to do much from SFC.
>> >
>> > Regards,
>> >
>> > Brady
>> >
>> > -Original Message-
>> > *From*: Mohamed ElSerngawy > maiyouhrsen%20%3cjluhr...@gmail.com%3e>>,
>> > sfc-dev@lists.opendaylight.org > ight.org> > > > lists.opendaylight.org%3e>>
>> > *Cc*: Openflowplugin-dev > daylight.org
>> > > opendaylight.org%3e>>
>> > *Subject*: Re: [openflowplugin-dev] br-sfc become slave and
>> disconnect from ODL
>> > *Date*: Wed, 8 Mar 2017 15:51:29 -0500
>> >
>> > Hi, following up on this thread
>> >
>> > In order to reproduce it, I attached with the email a vagrant
>> file that will spawn 5 VMs: odl, classifier1/2 and sff1/2.
>> > After spawn all the VMs:
>> >
>> > 1- In the odl VM start odl and install the following features:
>> > vagrant@odl:~/$ distribution-karaf-0.5.2-Boron-SR2/bin/karaf
>> > opendaylight-user@root>feature:install odl-sfc-ui odl-sfclisp
>> odl-sfc-scf-openflow odl-sfc-sb-rest odl-sfc-ovs
>> > odl-sfc-netconf odl-sfcofl2*
>> > *
>> >
>> > 2- in the other VMs classifier1/2 and sff1/2 set the OVS
>> instance manager and create br-sfc:
>> > vagrant@classifier1:~$ sudo ovs-vsctl set-manager tcp:
>> 10.10.1.5:6640 
>> >

Re: [sfc-dev] [netvirt-dev] Networking SFC convertor in ODL

[Anil Vishnoi]

On Wed, Oct 5, 2016 at 12:16 AM, Brady Allen Johnson <
brady.allen.john...@ericsson.com> wrote:

>
> This discussion isnt really going anywhere.
>
> As you can imagine, its not feasible for us to follow the Netvirt Gerrits.
> Even thought the patch [0] was indeed available for everyone to see, we had
> no idea it was there. Even if we had realized it was there, it was
> self-merged 9 hours after it was posted, and it had no gerrit comments
> stating it was experimental.
>
> All Im asking here is that you please inform us about future gerrit
> patches related to this before self-merging them. If the patch isnt
> important, note it as so in the gerrit comment.
>
​Sure​


> Anil, you ask how we do this in SFC, well, we do it like most of the rest
> of the healthy ODL projects: write meaningful gerrit comments and let other
> people review the patch before merging them.
>
​Glad to hear that.

>
> If you with to turn this into a competition to see who gets the last word,
> go ahead, Ive said my peace.
>
​No more words. It's understood.​


>
>
> Regards,
>
> Brady
>
> [0] https://git.opendaylight.org/gerrit/#/c/43305/
>
>
> On 05/10/16 00:32, Sam Hague wrote:
>
>
>
> On Tue, Oct 4, 2016 at 5:38 PM, Anil Vishnoi <vishnoia...@gmail.com>
> wrote:
>
>> Hi Brady,
>>
>> Please see inline..
>>
>> On Tue, Oct 4, 2016 at 12:47 PM, Brady Johnson <
>> bradyallenjohn...@gmail.com> wrote:
>>
>>>
>>> Anil,
>>>
>>> We're talking about 2 different patches here.
>>>
>>> I remember patch [0] well, and the discussions around it, which you
>>> quoted above. Im not that old yet ;) This patch is the Neutron Northbound
>>> API.
>>>
>>> I dont remember ever hearing anything about patch [1] though. This patch
>>> is the *implementation* of the Northbound API from patch [0]. I was
>>> under the impression that the implementation was going to be put in ODL SFC.
>>>
>>
>> ​Not sure how you got this impression, given that the only response we
>> got was pretty strong against this idea :-).
>>
> Agreed, though I recall something along the lines of "as long as the odl
> sfc models are left alone do whatever". We didn't have any other feedback
> and Anil needed to make progress so we did what we could to move forward.
>
>>
>> "
>> >* This ISN’T you exercising the right to do your own implementation of
>> Neutron SFC, this is introducing an unwanted API dependency on ODL-SFC.*
>>
>> >>* So now if ODL SFC needs/wants to change its YANG models due to say IETF 
>> >>/ sanity, and those don’t magically line up with neutron-sfc’s bizarre 
>> >>view of the world, or at least one beyond 1999-2001 when this sort of 
>> >>approach to SFC was first proposed, we get blocked from doing so because 
>> >>it will break this “translation layer” that now has welded an unwanted 
>> >>dependency on the project. *
>>
>> >"​
>>
>>
>>> Considering the patch is experimental as you mentioned, I can see why
>>> you didnt publish it.
>>>
>>
>> ​This patch was out there in the open for everyone to review in NetVirt
>> master branch, so anyone can review these patch. Going forward we will add
>> all the sfc committers as a reviewer in the NetVirt patches that is related
>> to SFC work, so that they can easily monitor those patches. Hopefully that
>> won't create much spam for them.
>>
> Agreed here also. The patches sat around for a while and were in the open.
> It was an oversight that more reviewers were not included - that is
> something we need to be better about.
>
>>
>>
>>> Can you please mark experimental patches as such in the future to avoid
>>> confusion.
>>>
>>
>> ​Yup, i think that's useful to have.​
>>
>>
>>> Also, It wouldnt hurt to mention why its being self-merged.
>>>
>> ​Agree, what standard practice SFC project use?, we can probably follow
>> the same in net-virt project ?​
>>
> To be fair, I reviewed the patch but didn't have substantial comments.
> Anil and I talked about it and I said it was OK to merge.
>
>>
>>
>> These additional comments would have probably saved some work for Alexis
>>> too.
>>>
>> ​I think alexis comments were very valid comments, so i think his time
>> was well spent :).
>>
>>>
>>> As you can imagine, the ODL SFC community is very interested to see how
>>> the implementation of patch 

Re: [sfc-dev] Networking SFC convertor in ODL

[Anil Vishnoi]

Hi Brady,

Please see inline..

On Tue, Oct 4, 2016 at 12:47 PM, Brady Johnson <bradyallenjohn...@gmail.com>
wrote:

>
> Anil,
>
> We're talking about 2 different patches here.
>
> I remember patch [0] well, and the discussions around it, which you quoted
> above. Im not that old yet ;) This patch is the Neutron Northbound API.
>
> I dont remember ever hearing anything about patch [1] though. This patch
> is the *implementation* of the Northbound API from patch [0]. I was under
> the impression that the implementation was going to be put in ODL SFC.
>

​Not sure how you got this impression, given that the only response we got
was pretty strong against this idea :-).

"
>* This ISN’T you exercising the right to do your own implementation of
Neutron SFC, this is introducing an unwanted API dependency on ODL-SFC.*

>>* So now if ODL SFC needs/wants to change its YANG models due to say IETF / 
>>sanity, and those don’t magically line up with neutron-sfc’s bizarre view of 
>>the world, or at least one beyond 1999-2001 when this sort of approach to SFC 
>>was first proposed, we get blocked from doing so because it will break this 
>>“translation layer” that now has welded an unwanted dependency on the 
>>project. *

>"​


> Considering the patch is experimental as you mentioned, I can see why you
> didnt publish it.
>

​This patch was out there in the open for everyone to review in NetVirt
master branch, so anyone can review these patch. Going forward we will add
all the sfc committers as a reviewer in the NetVirt patches that is related
to SFC work, so that they can easily monitor those patches. Hopefully that
won't create much spam for them.


> Can you please mark experimental patches as such in the future to avoid
> confusion.
>

​Yup, i think that's useful to have.​


> Also, It wouldnt hurt to mention why its being self-merged.
>
​Agree, what standard practice SFC project use?, we can probably follow the
same in net-virt project ?​


These additional comments would have probably saved some work for Alexis
> too.
>
​I think alexis comments were very valid comments, so i think his time was
well spent :).

>
> As you can imagine, the ODL SFC community is very interested to see how
> the implementation of patch [0] works out. I was hoping it would be
> possible to wait until Networking SFC aligned with either IETF SFC or ETSI
> VNFFG, else we risk not being able to completely leverage ODL SFC, since
> the Networking SFC API is very basic and lacking to say the least.
>
​I think it's a longer discussion that need to be done across
openstack/opendaylight/opnfv. I am not sure what are the concrete steps are
taken by networking-sfc project to move toward this direction. I saw one
blueprint in this direction, but it was abandoned later on. I think there
is a long way ahead to get to those final api we are expecting, and i think
this requires some effort from teh provider side to implement the available
API's and provide the feedback to the networking-sfc. I think that way we
can make faster progress.

>
> In the future, could you please inform us of any additional work in this
> area so we can help and advise if needed.
>
​Sure will do, please keep watching the sfc-dev mailing list ;).​


>
> Thanks,
>
> Brady
>
> [0] https://git.opendaylight.org/gerrit/#/c/38748/
> [1] https://git.opendaylight.org/gerrit/#/c/43305/
>
>
> On Tue, Oct 4, 2016 at 8:05 PM, Anil Vishnoi <vishnoia...@gmail.com>
> wrote:
>
>> Hi Brady,
>>
>> Sorry to say, but most of the questions that you asked below is really a
>> surprise to me as well, given that you were well aware of the overall
>> networking-sfc integration work and translation layer work that i was doing
>> and *it was discussed on sfc-dev mailing list. *Even you were reviewer
>> of the first ever patch that I pushed in ODL to start this work.
>>
>> https://git.opendaylight.org/gerrit/#/c/38748/
>>
>> Please see inline...
>>
>> On Tue, Oct 4, 2016 at 12:30 AM, Brady Allen Johnson <
>> brady.allen.john...@ericsson.com> wrote:
>>
>>>
>>> I just noticed a *merged* Gerrit patch in Netvirt [0] to do the
>>> Networking SFC to ODL SFC conversion.
>>>
>>> I have to say that I was quite surprised to see that this patch was
>>> merged without ever consulting the ODL SFC community. I have a few
>>> questions regarding this patch:
>>>
>>>
>>>1. Why is this code in Netvirt and not in SFC where it belongs?
>>>
>>> Following thread ​actually discuss about why we implemented this
>> translation layer it in netvirt and not in sfc project. To explictly
>> mention here, I came to SFC pr

Re: [sfc-dev] Networking SFC convertor in ODL

[Anil Vishnoi]

Hi Brady,

Sorry to say, but most of the questions that you asked below is really a
surprise to me as well, given that you were well aware of the overall
networking-sfc integration work and translation layer work that i was doing
and *it was discussed on sfc-dev mailing list. *Even you were reviewer of
the first ever patch that I pushed in ODL to start this work.

https://git.opendaylight.org/gerrit/#/c/38748/

Please see inline...

On Tue, Oct 4, 2016 at 12:30 AM, Brady Allen Johnson <
brady.allen.john...@ericsson.com> wrote:

>
> I just noticed a *merged* Gerrit patch in Netvirt [0] to do the
> Networking SFC to ODL SFC conversion.
>
> I have to say that I was quite surprised to see that this patch was merged
> without ever consulting the ODL SFC community. I have a few questions
> regarding this patch:
>
>
>1. Why is this code in Netvirt and not in SFC where it belongs?
>
> Following thread ​actually discuss about why we implemented this
translation layer it in netvirt and not in sfc project. To explictly
mention here, I came to SFC project with the intent of implementing this
layer in ODL SFC project as one of your response says in the mail thread

*"As for implementations of the "translation layer", I think Anil *

*envisioned this to live in ODL SFC, and in any other projects that
wanted to implement their own form of SFC.

Regards,

Brady​"*

​Thread:*https://lists.opendaylight.org/pipermail/sfc-dev/2016-May/002998.html
*​

If you read through this mail thread, keith was the only sfc committer
who provided his feedback and he was not in favor of implementing this
layer in the sfc project. We did not get any vote/opinion from you on
this subject, and the only feedback we got was not in favor of the
idea, so that's the reason we decided to implement it in netvirt and
you were very well aware of that as well.

​


>1. Why wasnt the SFC community ever informed about these changes?
>
> ​I think this is not correct, I notified opendaylight sfc community even
when I pushed blueprint for networking-sfc driver to openstack
networking-sfc project. Here is the mail thread

https://lists.opendaylight.org/pipermail/sfc-dev/2016-April/002833.html

Apart from that you were reviewer on the gerrit i mentioned above, and that
was the first patch on the ODL side that I pushed for networking-sfc
support.

>
>1.
>2. Why was the patch +2'd and merged by the author? Unless things have
>changed drastically lately, self-merging is frowned upon, and in most
>projects its simply *not allowed*.
>
> ​This is the first experimental version that we added for networking-sfc
API support. Nature of this work was a experimental moreover to analyze the
gap between networking-sfc and odl SFC API's and provide more feedback to
networking-sfc project to improve their APIs. And Sam and I agreed on this
that we can self merge this patch, given that it's totally isolated piece
of work and don't interfere with netvirt project's functionality or ODL SFC
project. Apart from that, sam did review initial patches with me before i
merge these patches.

>
>1. There are some code review comments on the patch that were never
>addressed, will these ever be addressed?
>
> ​As alexis mentioned in his comment below, he posted this comment recently
(Sep 17)​

​and patches were merged on Aug 8 (before M5). I generally don't ​revisit
my merged patches for comments, and likely most of the developers too, and
that's the reason i probably have missed it. Alexis comment is already
partially addressed in other patches.

>
>1.
>
>
> Needless to say, this has left a nasty taste in my mouth. Hopefully we can
> set this straight and start collaborating between projects in the future.
>
Definitely, ​That was my primary intend, but unfortunately we didn't get
much enthusiastic ​response from sfc committers. Looking forward to a
better collaboration in future.
I am assuming that you are totally swamped with the mails and probably
missed some of the mail thread i mentioned above, let me know if i can
communicate with you by some other means that works better for you.

>
> Regards,
>
> Brady
>
> [0] https://git.opendaylight.org/gerrit/#/c/43305/
>
>


-- 
Thanks
Anil
___
sfc-dev mailing list
sfc-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

Re: [sfc-dev] [openflowplugin-dev] [release] Merge a large Openflow plugin patch to master and stable/boron today

[Anil Vishnoi]

Netvirt distribution is failing because of this error

Could not start bundle
mvn:org.opendaylight.groupbasedpolicy/ofoverlay-renderer/0.5.0-SNAPSHOT
in feature(s) *odl-groupbasedpolicy-ofoverlay-0.5.0-SNAPSHO*T: The
bundle "org.opendaylight.groupbasedpolicy.ofoverlay-renderer_0.5.0.SNAPSHOT
[529]" could not be resolved. Reason: Missing Constraint:
Import-Package:
org.opendaylight.yang.gen.v1.urn.opendaylight.openflowplugin.extension.nicira.action.rev140714.nx.action.set.nshc._1.grouping;
version="[0.4.0,1.0.0)"
at 
org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:403)
at Proxy18e377b3_b7c4_4d5b_b905_3ccb6d7fc89e.installFeature(Unknown 
Source)
at 
org.opendaylight.odlparent.featuretest.SingleFeatureTest.installFeature(SingleFeatureTest.java:308)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
at 
org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.lang.Thread.run(Thread.java:745)



So looks like we are kind of in dependency cycle, gbp distribution
probably will fail because of netvirt and netvirt is failing because
of gbp, so we need to override the jenkins verify and merge one of the
patch.


I am merging netvirt patch (carbon), so hopefully gbp patch will get verified.



On Thu, Aug 11, 2016 at 5:59 PM, Brady Johnson 
wrote:

> I was away from the PC for a few hours, and am back now. I'll fix this
> patch now and get it merged.
>
> Thanks for you patience. I'll let you know when its merged.
>
> Brady
>
>
> On Fri, Aug 12, 2016 at 2:04 AM, Sam Hague  wrote:
>
>> The verify job was failing because of a couple test in sfc failing. I
>> pushed [1] to comment out the two failing tests. That isn't the right fix
>> but it should let the job verify if those were the only two problems.
>>
>> Once that gets in can we get the other patches in that should go with the
>> openflow changes? And other patches that have been failing to verify?
>>
>> [1] https://git.opendaylight.org/gerrit/43763
>>
>> On Thu, Aug 11, 2016 at 6:44 PM, Brady Johnson <
>> bradyallenjohn...@gmail.com> wrote:
>>
>>> An,
>>>
>>> The SFC verify job is failing. I'm away from the pc now and am not sure
>>> what the problem is. Seems like it's not related to sfc nor the open flow
>>> patch.
>>>
>>> https://git.opendaylight.org/gerrit/#/c/43698/
>>>
>>> Any ideas anyone?
>>>
>>> Brady
>>>
>>> On Aug 12, 2016 00:39, "An Ho"  wrote:
>>>
 Hi,



 Any update on the status of this?  It may be holding up netvirt at the 
 moment [1] since sfc needs to go in and then netvirt and gbp.



 Best Regards,

 An Ho



 [1] https://lists.opendaylight.org/pipermail/release/2016-August
 /007851.html



 *From:* release-boun...@lists.opendaylight.org [mailto:
 release-boun...@lists.opendaylight.org] *On Behalf Of *Brady Allen
 Johnson
 *Sent:* Thursday, August 11, 2016 3:48 AM
 *To:* rele...@lists.opendaylight.org; sfc-dev@lists.opendaylight.org;
 openflowplugin-...@lists.opendaylight.org;
 netvirt-...@lists.opendaylight.org; groupbasedpolicy-...@lists.ope
 ndaylight.org; Manuel Buil
 *Subject:* [release] Merge a large Openflow plugin patch to master and
 stable/boron today




 Hello all,

 According to this API freeze waiver [0], I have reached agreement with
 the Netvirt, SFC, Group Based Policy (GBP) and Openflow plugin (OFP)
 projects to merge the following patches on master (Carbon) and to
 stable/boron:

 Patches on master (Carbon)

 OFP: https://git.opendaylight.org/gerrit/#/c/37937
 SFC: https://git.opendaylight.org/gerrit/#/c/37944
 Netvirt: https://git.opendaylight.org/gerrit/#/c/40942
 GBP: https://git.opendaylight.org/gerrit/#/c/40945


 Cherry picked patches on stable/boron:

 OFP:  https://git.opendaylight.org/gerrit/#/c/43697
 SFC:  https://git.opendaylight.org/gerrit/#/c/43698
 Netvirt:  

Re: [sfc-dev] [nic-dev] [OpenDaylight TSC] [SEEK AGREEMENT ON API FREEZE WAIVER] Openflow plugin TCP Flags API change

[Anil Vishnoi]

Hi Yrineu,

Please reach out to me, if you face any issue because of this patch.

Thanks
Anil

On Wed, Aug 3, 2016 at 3:08 PM, Yrineu Rodrigues <yfrfel...@gmail.com>
wrote:

> This does not causes big impacts on NIC project, but I'm looking to ensure
> that all tests will work properly after merge it.
>
> Thanks,
>
> On Wed, Aug 3, 2016 at 6:47 PM, Anil Vishnoi <vishnoia...@gmail.com>
> wrote:
>
>> No, it's not how it is supposed to work.
>>
>> Existing tcp_flag api's in openflowplugin had no implementation in
>> openflowplugin project ( although there are models defined for it in
>> plugin), so i was under impression that no project should be using it,
>> because it's not going to work for them. Probably i should have check'ed it
>> rather than assuming it. So under that assumption, i thought we don't
>> really need a waiver for this change.
>>
>> Given that TCP Flags is now approved ONF extension for OpenFlow 1.3, I
>> added the support for the API's. OpenFlowplugin patch that I pushed was
>> dependent on the OpenFlow java patch. Michal reviewed and merged
>> openflowjava patch, so i merged the openflowplugin patch as well, otherwise
>> openflowplugin build is going to break. That will eventual break all the
>> dependent projects as well.
>>
>> I merged my own patch, because there was no committer available to review
>> this patch at 2 AM PST, so rather than putting projects on the risk of
>> build failure, I merged it. This is something which we have done in the
>> past as well to avoid similar situations.
>>
>> I don't see groupbasedpolicy project is impacted by this change. Verify
>> build of groupbasedpolicy is fine (#7, #8 were triggered after the
>> openflowplugin patch merge)
>>
>>
>> https://jenkins.opendaylight.org/releng/view/groupbasedpolicy/job/groupbasedpolicy-verify-boron-mvn33-openjdk8/
>>
>> Hope it answer some of your questions.
>>
>> Thanks
>> Anil
>>
>> On Wed, Aug 3, 2016 at 2:10 PM, Brady Allen Johnson <
>> brady.allen.john...@ericsson.com> wrote:
>>
>>>
>>> There is something I dont understand here: You're looking for an
>>> agreement, but you authored the patch, and you merged it yourself. We didnt
>>> get any chance to agree or disagree.
>>>
>>> Is this how API Freeze Waivers are supposed to work?
>>>
>>> BTW, Im adding GBP, since they are affected too.
>>>
>>> Brady
>>>
>>> On 03/08/16 22:43, Anil Vishnoi wrote:
>>>
>>> + release
>>>
>>> On Wed, Aug 3, 2016 at 1:40 PM, Anil Vishnoi <vishnoia...@gmail.com>
>>> wrote:
>>>
>>>> ​Note: This email is to seek agreement on a waiver of API FREEZE.
>>>>
>>>> The patch for wich a waiver of API FREEZE is being sought is:
>>>>
>>>> https://git.opendaylight.org/gerrit/42630
>>>>
>>>> and it is contributed to:
>>>> OpenFlow Plugin project
>>>>
>>>> The following projects have been determined to be impacted:
>>>>
>>>> genius Consumer
>>>> netvirt Consumer
>>>> vtn Consumer
>>>> nic Consumer
>>>> sfc Consumer
>>>> didm Consumer
>>>>
>>>> Agreement to waive API FREEZE for
>>>> https://git.opendaylight.org/gerrit/42630
>>>>
>>>> will be indicated by +1 from each project representative on the Gerrit
>>>> itself.
>>>>
>>>> There is no agreement to waive API FREEZE until all project
>>>> representatives have +1ed the Gerrit.
>>>>
>>>> This email is *only* about waiving of API FREEZE, normal code review
>>>> will proceed in the normal fashion
>>>>
>>>> -
>>>> This patch is  already merged and respective fixes are pushed to the
>>>> impacted projects:
>>>>
>>>> genius : https://git.opendaylight.org/gerrit/43047  (merged)
>>>> netvirt https://git.opendaylight.org/gerrit/43049 (merged)
>>>> vtn https://git.opendaylight.org/gerrit/43038 (merged)
>>>> nic https://git.opendaylight.org/gerrit/43077 (waiting for review)
>>>> sfc https://git.opendaylight.org/gerrit/43082 (waiting for review)
>>>> didm https://git.opendaylight.org/gerrit/43086 (waiting for review)
>>>> Thanks
>>>> Anil
>>>>
>>>
>>>
>>>
>>> --
>>> Thanks
>>> Anil
>>>
>>>
>>> ___
>>> TSC mailing 
>>> listTSC@lists.opendaylight.orghttps://lists.opendaylight.org/mailman/listinfo/tsc
>>>
>>>
>>>
>>
>>
>> --
>> Thanks
>> Anil
>>
>> ___
>> nic-dev mailing list
>> nic-...@lists.opendaylight.org
>> https://lists.opendaylight.org/mailman/listinfo/nic-dev
>>
>>
>
>
> --
> *Yrineu Rodrigues*
> *OpendayLight NIC PTL/committer*
> --
>
> *Linkedin <http://www.linkedin.com/in/yrineu>*
> *NIC wiki page*
> <https://wiki.opendaylight.org/view/Network_Intent_Composition:Main>
>
>


-- 
Thanks
Anil
___
sfc-dev mailing list
sfc-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

Re: [sfc-dev] [OpenDaylight TSC] [SEEK AGREEMENT ON API FREEZE WAIVER] Openflow plugin TCP Flags API change

[Anil Vishnoi]

Forgot to answer, why am i sending the API waiver, given that patch is
merged?, this is to record the change on the opendaylight wiki so that we
can make sure that these API changes been released note for the external
projects.

On Wed, Aug 3, 2016 at 2:47 PM, Anil Vishnoi <vishnoia...@gmail.com> wrote:

> No, it's not how it is supposed to work.
>
> Existing tcp_flag api's in openflowplugin had no implementation in
> openflowplugin project ( although there are models defined for it in
> plugin), so i was under impression that no project should be using it,
> because it's not going to work for them. Probably i should have check'ed it
> rather than assuming it. So under that assumption, i thought we don't
> really need a waiver for this change.
>
> Given that TCP Flags is now approved ONF extension for OpenFlow 1.3, I
> added the support for the API's. OpenFlowplugin patch that I pushed was
> dependent on the OpenFlow java patch. Michal reviewed and merged
> openflowjava patch, so i merged the openflowplugin patch as well, otherwise
> openflowplugin build is going to break. That will eventual break all the
> dependent projects as well.
>
> I merged my own patch, because there was no committer available to review
> this patch at 2 AM PST, so rather than putting projects on the risk of
> build failure, I merged it. This is something which we have done in the
> past as well to avoid similar situations.
>
> I don't see groupbasedpolicy project is impacted by this change. Verify
> build of groupbasedpolicy is fine (#7, #8 were triggered after the
> openflowplugin patch merge)
>
>
> https://jenkins.opendaylight.org/releng/view/groupbasedpolicy/job/groupbasedpolicy-verify-boron-mvn33-openjdk8/
>
> Hope it answer some of your questions.
>
> Thanks
> Anil
>
> On Wed, Aug 3, 2016 at 2:10 PM, Brady Allen Johnson <
> brady.allen.john...@ericsson.com> wrote:
>
>>
>> There is something I dont understand here: You're looking for an
>> agreement, but you authored the patch, and you merged it yourself. We didnt
>> get any chance to agree or disagree.
>>
>> Is this how API Freeze Waivers are supposed to work?
>>
>> BTW, Im adding GBP, since they are affected too.
>>
>> Brady
>>
>> On 03/08/16 22:43, Anil Vishnoi wrote:
>>
>> + release
>>
>> On Wed, Aug 3, 2016 at 1:40 PM, Anil Vishnoi <vishnoia...@gmail.com>
>> wrote:
>>
>>> ​Note: This email is to seek agreement on a waiver of API FREEZE.
>>>
>>> The patch for wich a waiver of API FREEZE is being sought is:
>>>
>>> https://git.opendaylight.org/gerrit/42630
>>>
>>> and it is contributed to:
>>> OpenFlow Plugin project
>>>
>>> The following projects have been determined to be impacted:
>>>
>>> genius Consumer
>>> netvirt Consumer
>>> vtn Consumer
>>> nic Consumer
>>> sfc Consumer
>>> didm Consumer
>>>
>>> Agreement to waive API FREEZE for
>>> https://git.opendaylight.org/gerrit/42630
>>>
>>> will be indicated by +1 from each project representative on the Gerrit
>>> itself.
>>>
>>> There is no agreement to waive API FREEZE until all project
>>> representatives have +1ed the Gerrit.
>>>
>>> This email is *only* about waiving of API FREEZE, normal code review
>>> will proceed in the normal fashion
>>>
>>> -
>>> This patch is  already merged and respective fixes are pushed to the
>>> impacted projects:
>>>
>>> genius : https://git.opendaylight.org/gerrit/43047  (merged)
>>> netvirt https://git.opendaylight.org/gerrit/43049 (merged)
>>> vtn https://git.opendaylight.org/gerrit/43038 (merged)
>>> nic https://git.opendaylight.org/gerrit/43077 (waiting for review)
>>> sfc https://git.opendaylight.org/gerrit/43082 (waiting for review)
>>> didm https://git.opendaylight.org/gerrit/43086 (waiting for review)
>>> Thanks
>>> Anil
>>>
>>
>>
>>
>> --
>> Thanks
>> Anil
>>
>>
>> ___
>> TSC mailing 
>> listTSC@lists.opendaylight.orghttps://lists.opendaylight.org/mailman/listinfo/tsc
>>
>>
>>
>
>
> --
> Thanks
> Anil
>



-- 
Thanks
Anil
___
sfc-dev mailing list
sfc-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

Re: [sfc-dev] [OpenDaylight TSC] [SEEK AGREEMENT ON API FREEZE WAIVER] Openflow plugin TCP Flags API change

[Anil Vishnoi]

No, it's not how it is supposed to work.

Existing tcp_flag api's in openflowplugin had no implementation in
openflowplugin project ( although there are models defined for it in
plugin), so i was under impression that no project should be using it,
because it's not going to work for them. Probably i should have check'ed it
rather than assuming it. So under that assumption, i thought we don't
really need a waiver for this change.

Given that TCP Flags is now approved ONF extension for OpenFlow 1.3, I
added the support for the API's. OpenFlowplugin patch that I pushed was
dependent on the OpenFlow java patch. Michal reviewed and merged
openflowjava patch, so i merged the openflowplugin patch as well, otherwise
openflowplugin build is going to break. That will eventual break all the
dependent projects as well.

I merged my own patch, because there was no committer available to review
this patch at 2 AM PST, so rather than putting projects on the risk of
build failure, I merged it. This is something which we have done in the
past as well to avoid similar situations.

I don't see groupbasedpolicy project is impacted by this change. Verify
build of groupbasedpolicy is fine (#7, #8 were triggered after the
openflowplugin patch merge)

https://jenkins.opendaylight.org/releng/view/groupbasedpolicy/job/groupbasedpolicy-verify-boron-mvn33-openjdk8/

Hope it answer some of your questions.

Thanks
Anil

On Wed, Aug 3, 2016 at 2:10 PM, Brady Allen Johnson <
brady.allen.john...@ericsson.com> wrote:

>
> There is something I dont understand here: You're looking for an
> agreement, but you authored the patch, and you merged it yourself. We didnt
> get any chance to agree or disagree.
>
> Is this how API Freeze Waivers are supposed to work?
>
> BTW, Im adding GBP, since they are affected too.
>
> Brady
>
> On 03/08/16 22:43, Anil Vishnoi wrote:
>
> + release
>
> On Wed, Aug 3, 2016 at 1:40 PM, Anil Vishnoi <vishnoia...@gmail.com>
> wrote:
>
>> ​Note: This email is to seek agreement on a waiver of API FREEZE.
>>
>> The patch for wich a waiver of API FREEZE is being sought is:
>>
>> https://git.opendaylight.org/gerrit/42630
>>
>> and it is contributed to:
>> OpenFlow Plugin project
>>
>> The following projects have been determined to be impacted:
>>
>> genius Consumer
>> netvirt Consumer
>> vtn Consumer
>> nic Consumer
>> sfc Consumer
>> didm Consumer
>>
>> Agreement to waive API FREEZE for
>> https://git.opendaylight.org/gerrit/42630
>>
>> will be indicated by +1 from each project representative on the Gerrit
>> itself.
>>
>> There is no agreement to waive API FREEZE until all project
>> representatives have +1ed the Gerrit.
>>
>> This email is *only* about waiving of API FREEZE, normal code review will
>> proceed in the normal fashion
>>
>> -
>> This patch is  already merged and respective fixes are pushed to the
>> impacted projects:
>>
>> genius : https://git.opendaylight.org/gerrit/43047  (merged)
>> netvirt https://git.opendaylight.org/gerrit/43049 (merged)
>> vtn https://git.opendaylight.org/gerrit/43038 (merged)
>> nic https://git.opendaylight.org/gerrit/43077 (waiting for review)
>> sfc https://git.opendaylight.org/gerrit/43082 (waiting for review)
>> didm https://git.opendaylight.org/gerrit/43086 (waiting for review)
>> Thanks
>> Anil
>>
>
>
>
> --
> Thanks
> Anil
>
>
> ___
> TSC mailing 
> listTSC@lists.opendaylight.orghttps://lists.opendaylight.org/mailman/listinfo/tsc
>
>
>


-- 
Thanks
Anil
___
sfc-dev mailing list
sfc-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

Re: [sfc-dev] [SEEK AGREEMENT ON API FREEZE WAIVER] Openflow plugin TCP Flags API change

[Anil Vishnoi]

+ release

On Wed, Aug 3, 2016 at 1:40 PM, Anil Vishnoi <vishnoia...@gmail.com> wrote:

> ​Note: This email is to seek agreement on a waiver of API FREEZE.
>
> The patch for wich a waiver of API FREEZE is being sought is:
>
> https://git.opendaylight.org/gerrit/42630
>
> and it is contributed to:
> OpenFlow Plugin project
>
> The following projects have been determined to be impacted:
>
> genius Consumer
> netvirt Consumer
> vtn Consumer
> nic Consumer
> sfc Consumer
> didm Consumer
>
> Agreement to waive API FREEZE for
> https://git.opendaylight.org/gerrit/42630
>
> will be indicated by +1 from each project representative on the Gerrit
> itself.
>
> There is no agreement to waive API FREEZE until all project
> representatives have +1ed the Gerrit.
>
> This email is *only* about waiving of API FREEZE, normal code review will
> proceed in the normal fashion
>
> -
> This patch is  already merged and respective fixes are pushed to the
> impacted projects:
>
> genius : https://git.opendaylight.org/gerrit/43047  (merged)
> netvirt https://git.opendaylight.org/gerrit/43049 (merged)
> vtn https://git.opendaylight.org/gerrit/43038 (merged)
> nic https://git.opendaylight.org/gerrit/43077 (waiting for review)
> sfc https://git.opendaylight.org/gerrit/43082 (waiting for review)
> didm https://git.opendaylight.org/gerrit/43086 (waiting for review)
>
> Thanks
> Anil
>
>


-- 
Thanks
Anil
___
sfc-dev mailing list
sfc-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

[sfc-dev] [SEEK AGREEMENT ON API FREEZE WAIVER] Openflow plugin TCP Flags API change

[Anil Vishnoi]

​Note: This email is to seek agreement on a waiver of API FREEZE.

The patch for wich a waiver of API FREEZE is being sought is:

https://git.opendaylight.org/gerrit/42630

and it is contributed to:
OpenFlow Plugin project

The following projects have been determined to be impacted:

genius Consumer
netvirt Consumer
vtn Consumer
nic Consumer
sfc Consumer
didm Consumer

Agreement to waive API FREEZE for
https://git.opendaylight.org/gerrit/42630

will be indicated by +1 from each project representative on the Gerrit
itself.

There is no agreement to waive API FREEZE until all project representatives
have +1ed the Gerrit.

This email is *only* about waiving of API FREEZE, normal code review will
proceed in the normal fashion

-
This patch is  already merged and respective fixes are pushed to the
impacted projects:

genius : https://git.opendaylight.org/gerrit/43047  (merged)
netvirt https://git.opendaylight.org/gerrit/43049 (merged)
vtn https://git.opendaylight.org/gerrit/43038 (merged)
nic https://git.opendaylight.org/gerrit/43077 (waiting for review)
sfc https://git.opendaylight.org/gerrit/43082 (waiting for review)
didm https://git.opendaylight.org/gerrit/43086 (waiting for review)

Thanks
Anil
___
sfc-dev mailing list
sfc-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

[sfc-dev] Fix for build failure.

[Anil Vishnoi]

Hi Sfc-dev,

We recently merged a patch[1] in openflowplugin that caused the build
failure in SFC project.

I pushed following patch to fix it, please review and merge the patch.

https://git.opendaylight.org/gerrit/#/c/43082/


[1]https://git.opendaylight.org/gerrit/#/c/42630/

-- 
Thanks
Anil
___
sfc-dev mailing list
sfc-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/sfc-dev