Re: [openflowplugin-dev] PortReason Flag not set properly during port deletes

2018-04-10 Thread D Arunprakash 
Patch merged in master, please run csit on the genius patch and let us know the 
results.

Regards,
Arun

From: Faseela K
Sent: Tuesday, April 10, 2018 2:07 PM
To: D Arunprakash ; Suja T ; 
openflowplugin-dev 
Cc: genius-...@lists.opendaylight.org; odl netvirt dev 

Subject: RE: PortReason Flag not set properly during port deletes

Hi Arun,
  Any update on this? :)
Thanks,
Faseela

From: D Arunprakash
Sent: Monday, April 02, 2018 3:03 PM
To: Faseela K >; Suja T 
>; openflowplugin-dev 
>
Cc: 
genius-...@lists.opendaylight.org; 
odl netvirt dev 
>
Subject: RE: PortReason Flag not set properly during port deletes

Hi Faseela,
Waiting for openflowplugin committers to review and merge.

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

Will discuss in today's community meeting and close.

Regards,
Arun

From: Faseela K
Sent: Monday, April 02, 2018 12:52 PM
To: D Arunprakash 
>; Suja T 
>; openflowplugin-dev 
>
Cc: 
genius-...@lists.opendaylight.org; 
odl netvirt dev 
>
Subject: RE: PortReason Flag not set properly during port deletes

Arun,
  Can we get the patch merged, and then get cherry-picked to Oxygen?
  We are waiting for this, to get the dependent patches in genius to be merged.
Thanks,
Faseela

From: D Arunprakash
Sent: Thursday, March 15, 2018 5:05 PM
To: Faseela K >; Suja T 
>; openflowplugin-dev 
>
Cc: 
genius-...@lists.opendaylight.org; 
odl netvirt dev 
>
Subject: RE: PortReason Flag not set properly during port deletes

Hi Faseela,
Have raised a tentative patch for the issue, could you please check and let us 
know if it's working as expected.
https://git.opendaylight.org/gerrit/#/c/69422/

Regards,
Arun

From: Faseela K
Sent: Thursday, March 15, 2018 4:51 PM
To: Suja T >; D Arunprakash 
>; 
openflowplugin-dev 
>
Cc: 
genius-...@lists.opendaylight.org; 
odl netvirt dev 
>
Subject: RE: PortReason Flag not set properly during port deletes

Hi,
   I have raised the below JIRA to track the issue :
  https://jira.opendaylight.org/browse/OPNFLWPLUG-987

Thanks,
Faseela

From: Faseela K
Sent: Tuesday, March 13, 2018 7:56 AM
To: Suja T >; D Arunprakash 
>; 
'openflowplugin-dev' 
>
Cc: 'genius-...@lists.opendaylight.org' 
>; 
'odl netvirt dev' 
>
Subject: RE: PortReason Flag not set properly during port deletes

Suja,
   We have reverted the changes to use PortReason flag in master as well, as 
the current implementation is buggy and we have tests failing because of that.
Thanks,
Faseela

From: Faseela K
Sent: Saturday, March 10, 2018 1:31 AM
To: Suja T >; D Arunprakash 
>; 
'openflowplugin-dev' 
>
Cc: 'genius-...@lists.opendaylight.org' 
>; 
'odl netvirt dev' 
>
Subject: RE: PortReason Flag not set properly during port deletes

Just an FYI.
Suja was later on able to reproduce the issue, with some openflowplugin logs 
enabled.
@Suja : Please update if you have some conclusion on the root cause.

Thanks,
Faseela

From: Faseela K

Re: [openflowplugin-dev] Doubt on openflow reconciliation logic

2018-04-10 Thread D Arunprakash 
If you enable bundle reconciliation, then all the groups and flows will be 
deleted before pushing the new flows and groups. Otherwise, normal 
reconciliation will just replace the old flows and groups and won’t do any 
cleanup.

There is no table specific flow deletion in resync.

Regards,
Arun

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Josh 
Hershberg
Sent: Tuesday, April 10, 2018 1:12 PM
To: Faseela K 
Cc: coe-...@lists.opendaylight.org; openflowplugin-dev 

Subject: Re: [openflowplugin-dev] Doubt on openflow reconciliation logic

As far as I can tell from 
...openflowplugin.applications.frm.impl.FlowNodeReconciliationImpl#createMessages
 the first thing done during reconciliation is that all flows and groups are 
deleted. Although bundles are not yet implemented for upgrade, the plan is to 
also remove all flows and groups as the first action in the bundle. :-(

On Tue, Apr 10, 2018 at 10:29 AM, Faseela K 
> wrote:
Hi openflowplugin-devs,
In COE, we have a usecases where we need to manage one flow table on a 
bridge, outside ODL.
However there are several other flow tables on the same bridge which is 
managed by ODL as well.
1.  What will be the behavior of resync in such a case? Will ODL wipe off 
all the flows in the bridge, or will it delete only tables owned by ODL?
2.  What will happen in case of ODL upgrade?
Thanks,
Faseela

___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] PortReason Flag not set properly during port deletes

2018-04-10 Thread Faseela K 
Hi Arun,
  Any update on this? :)
Thanks,
Faseela

From: D Arunprakash
Sent: Monday, April 02, 2018 3:03 PM
To: Faseela K ; Suja T ; 
openflowplugin-dev 
Cc: genius-...@lists.opendaylight.org; odl netvirt dev 

Subject: RE: PortReason Flag not set properly during port deletes

Hi Faseela,
Waiting for openflowplugin committers to review and merge.

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

Will discuss in today's community meeting and close.

Regards,
Arun

From: Faseela K
Sent: Monday, April 02, 2018 12:52 PM
To: D Arunprakash 
>; Suja T 
>; openflowplugin-dev 
>
Cc: 
genius-...@lists.opendaylight.org; 
odl netvirt dev 
>
Subject: RE: PortReason Flag not set properly during port deletes

Arun,
  Can we get the patch merged, and then get cherry-picked to Oxygen?
  We are waiting for this, to get the dependent patches in genius to be merged.
Thanks,
Faseela

From: D Arunprakash
Sent: Thursday, March 15, 2018 5:05 PM
To: Faseela K >; Suja T 
>; openflowplugin-dev 
>
Cc: 
genius-...@lists.opendaylight.org; 
odl netvirt dev 
>
Subject: RE: PortReason Flag not set properly during port deletes

Hi Faseela,
Have raised a tentative patch for the issue, could you please check and let us 
know if it's working as expected.
https://git.opendaylight.org/gerrit/#/c/69422/

Regards,
Arun

From: Faseela K
Sent: Thursday, March 15, 2018 4:51 PM
To: Suja T >; D Arunprakash 
>; 
openflowplugin-dev 
>
Cc: 
genius-...@lists.opendaylight.org; 
odl netvirt dev 
>
Subject: RE: PortReason Flag not set properly during port deletes

Hi,
   I have raised the below JIRA to track the issue :
  https://jira.opendaylight.org/browse/OPNFLWPLUG-987

Thanks,
Faseela

From: Faseela K
Sent: Tuesday, March 13, 2018 7:56 AM
To: Suja T >; D Arunprakash 
>; 
'openflowplugin-dev' 
>
Cc: 'genius-...@lists.opendaylight.org' 
>; 
'odl netvirt dev' 
>
Subject: RE: PortReason Flag not set properly during port deletes

Suja,
   We have reverted the changes to use PortReason flag in master as well, as 
the current implementation is buggy and we have tests failing because of that.
Thanks,
Faseela

From: Faseela K
Sent: Saturday, March 10, 2018 1:31 AM
To: Suja T >; D Arunprakash 
>; 
'openflowplugin-dev' 
>
Cc: 'genius-...@lists.opendaylight.org' 
>; 
'odl netvirt dev' 
>
Subject: RE: PortReason Flag not set properly during port deletes

Just an FYI.
Suja was later on able to reproduce the issue, with some openflowplugin logs 
enabled.
@Suja : Please update if you have some conclusion on the root cause.

Thanks,
Faseela

From: Faseela K
Sent: Friday, March 09, 2018 12:31 PM
To: Suja T >; D Arunprakash 
>; 
openflowplugin-dev 
>
Cc: 
genius-...@lists.opendaylight.org; 
odl netvirt dev 
>
Subject: RE: PortReason Flag not set properly during port deletes

Suja,

   The logs which you have referred somehow gets these test cases passing, and 
that is when Reason flag is

[openflowplugin-dev] Doubt on openflow reconciliation logic

2018-04-10 Thread Faseela K 
Hi openflowplugin-devs,
In COE, we have a usecases where we need to manage one flow table on a 
bridge, outside ODL.
However there are several other flow tables on the same bridge which is 
managed by ODL as well.

  1.  What will be the behavior of resync in such a case? Will ODL wipe off all 
the flows in the bridge, or will it delete only tables owned by ODL?
  2.  What will happen in case of ODL upgrade?
Thanks,
Faseela
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] Doubt on openflow reconciliation logic

2018-04-10 Thread Josh Hershberg 
As far as I can tell
from 
...openflowplugin.applications.frm.impl.FlowNodeReconciliationImpl#createMessages
the first thing done during reconciliation is that all flows and groups are
deleted. Although bundles are not yet implemented for upgrade, the plan is
to also remove all flows and groups as the first action in the bundle. :-(

On Tue, Apr 10, 2018 at 10:29 AM, Faseela K  wrote:

> Hi openflowplugin-devs,
>
> In COE, we have a usecases where we need to manage one flow table on a
> bridge, outside ODL.
>
> However there are several other flow tables on the same bridge which
> is managed by ODL as well.
>
>1. What will be the behavior of resync in such a case? Will ODL wipe
>off all the flows in the bridge, or will it delete only tables owned by 
> ODL?
>2. What will happen in case of ODL upgrade?
>
> Thanks,
>
> Faseela
>
> ___
> openflowplugin-dev mailing list
> openflowplugin-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
>
>
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] [genius-dev] Move datastoreutils and other infra utilities outside mdsalutil?

2018-04-10 Thread Faseela K 
Just an FYI.

We have added a new feature called “odl-genius-tools”, and have started 
migrating some of the datastore related utils to a new module called 
genius/tools [0].
This is just to make a light weight feature for use by applications who 
just need datastore related utils. Please use this new feature, so that you 
won’t have to add dependency on a heavier genius feature, just to use datastore 
related utilities.
Also make sure to use the utils from the new module for any of the upcoming 
patches, as the older ones are deprecated and the migration to the new utils in 
the existing code is in progress.

Thanks,
Faseela

[0] https://git.opendaylight.org/gerrit/#/c/69755/

From: Michael Vorburger [mailto:vorbur...@redhat.com]
Sent: Thursday, March 15, 2018 3:14 PM
To: Faseela K 
Cc: genius-...@lists.opendaylight.org
Subject: Re: [genius-dev] Move datastoreutils and other infra utilities outside 
mdsalutil?

Hello,

On Thu, Mar 15, 2018 at 8:24 AM, Faseela K 
> wrote:
Hi,
  Recently there was a requirement from openflowplugin, that they need an “srm” 
only feature.
  And they don’t want any dependency on mdsalutil as mdsalutil inturn depends 
on openflowplugin.
  Currently srm depends on mdsalutil, as some of the utilities(like 
AbstractClusteredSyncDataTreeChangeListener, FutureRpcResults etc) are within 
mdsautil-api.
  Was wondering whether we should have a separate module (“genius-infra” ??) so 
that we can separate out the openflow utilities and other infra utilities?

mdsalutil-api truly has grown into a bit of too much, and the package names in 
it are a mess, so I'm totally in favour of doing such a split. In addition to 
resolving your specific short term problem re. genius' SRM use by 
openflowplugin, I think by clearly separating and offering a few of the general 
purpose utilities which have grown in genius in a separate bundle and Karaf 
feature, we can perhaps make them more of interest to other projects than just 
genius itself and netvirt as well; I'm specifically thinking e.g. 
openflowplugin perhaps having an interest to later use some of them even 
directly, not indirectly via SRM, or e.g. for upcoming work in neutron.

The "scope" of this new bundle IMHO should include MD SAL DataBroker related 
utilities (which we cannot host in the only lower-level infrautils; where they 
should continue to go if appropriate), but without any YANG models (just 
because those are typically always already "higher-level functionalities" which 
should better be placed elsewhere). For example, a specific functionality such 
as SRM should remain in its own bundle, that's just fine, and lets us have good 
modularity boundaries. As such, I would expect this new bundle to only ever 
have dependencies to infrautils, controller & mdsal but never to 
openflowplugin, ovsdb or any other genius bundles, nor the binding-parent. 
Makes sense?

Specifically which existing classes shall we start that bundle with? Here's my 
initial proposal, for discussion:

* org.opendaylight.genius.datastoreutils.listeners (incl. the 
AbstractClusteredSyncDataTreeChangeListener)
* org.opendaylight.genius.infra (incl. the FutureRpcResults you need; also 
ManagedNewTransactionRunner stuff)
* org.opendaylight.genius.mdsalutil.cache
* org.opendaylight.genius.utils.metrics.DataStoreMetrics only as a non-public 
package local class in the new listeners package
* NOT the SingleTransactionDataBroker - I think we should discourage its use, 
in favour of the ManagedNewTransactionRunner
* NOT org.opendaylight.genius.datastoreutils's @Deprecated Listener helpers, 
BUT MAYBE the Chainable* stuff, IFF (when) we make the new 
genius.datastoreutils.listeners use them for testability
* NOT IMdsalApiManager and org.opendaylight.genius.mdsalutil, 
mdsalutil.actions, mdsalutil.instructions, mdsalutil.[nx]matches (obviously)
* NOT org.opendaylight.genius.mdsalutil.packet
* NOT org.opendaylight.genius.utils.batching (at least not in its current form)
* NOT org.opendaylight.genius.utils
* NOT anything Hwvtep related

We can do this with a few steps, of course; don't have to move everything in 
one big Gerrit change. And we obviously need to keep backwards compatibility at 
least for a while. This should be possible by making mdsalutil-api dependant on 
this new bundle, and delegating. We should very much avoid to simply copy/paste 
ANY code, IMHO.

Could I suggest that we use the opportunity of a new bundle as the occassion to 
set a high bar for code quality? Beyond CS (that's old news), and FB (that's so 
2017), we should mandate also that all code in this new bundle complies with 
findbugs-slf4j (which we're just about to enforce accross all of genius 
anyway), Google's Error-Prone, enforces no copy/paste, has a 100% clean 
classpath without duplicates? This is easy by using the infrautils:parent for 
this new bundle, see