Re: [controller-dev] SingleFeatureTest (SFT) failure on odl-integration-compatible-with-all due to ConflictingModificationAppliedException: Node was created by other transaction.

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)]

Previous story: [2].

> who would have to do what

Ideally, Netconf developers would unify their features,
which does not seem to get done anytime soon [3].

There is a workaround in Int/Dist [4] prepared,
but it keeps SFT unstable, this time due to
(lack of) Karaf 4 memory efficiency [5].

Current road to stability seem to be
fixing various ODL project features (like [6])
to be less taxing on Karaf 4 bundle resolver,
and then merging [4].

> It would be nice if the exception included some context like the path.

I have rebased my old [7].
In this case, it is multiple netconf features trying to update
operational topology status for "controller-config" device.

> How does SFT even pick this up to fail the test?

In general, a "caused by" thrown by featuresService.installFeature.
In this case there was an ISE (visible in surefire report [8]
at 12:27:25,742) coming from here [9] (at least in Nitrogen),
not sure which component gets to throw it.

Vratko.

[2] https://lists.opendaylight.org/pipermail/release/2017-October/012728.html
[3] https://jira.opendaylight.org/browse/NETCONF-479
[4] https://git.opendaylight.org/gerrit/64410
[5] https://jira.opendaylight.org/browse/ODLPARENT-125
[6] https://jira.opendaylight.org/browse/INTDIST-92
[7] https://git.opendaylight.org/gerrit/48118
[8] 
https://logs.opendaylight.org/releng/jenkins092/infrautils-distribution-check-oxygen/144/distribution/features/singles/odl-integration-compatible-with-all/target/surefire-reports/org.opendaylight.odlparent.featuretest.SingleFeatureTest-output.txt.gz
[9] 
https://github.com/opendaylight/netconf/blob/release/nitrogen/netconf/sal-netconf-connector/src/main/java/org/opendaylight/netconf/sal/connect/netconf/sal/NetconfDeviceTopologyAdapter.java#L243

From: controller-dev-boun...@lists.opendaylight.org 
[mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Tom Pantelis
Sent: 23 October, 2017 15:24
To: Michael Vorburger 
Cc: controller-dev 
Subject: Re: [controller-dev] SingleFeatureTest (SFT) failure on 
odl-integration-compatible-with-all due to 
ConflictingModificationAppliedException: Node was created by other transaction.



On Mon, Oct 23, 2017 at 8:41 AM, Michael Vorburger 
> wrote:
Hello,

Any idea who would have to do what to precent SFT from (only occassionally?!) 
failing on odl-integration-compatible-with-all due to 
ConflictingModificationAppliedException: Node was created by other transaction, 
as seen on 
https://logs.opendaylight.org/releng/jenkins092/infrautils-distribution-check-oxygen/144/console.log.gz
 for https://git.opendaylight.org/gerrit/#/c/63466/ ?

It would be nice if the exception included some context like the path. Does 
this test install all netconf features? I've seen such sporadic issues with the 
callhome feature when it's installed with all the other netconf features.

How does SFT even pick this up to fail the test? Log scraping?  Or was it a 
"caused by" thrown on blueprint startup?


Tx,
M.
--
Michael Vorburger, Red Hat
vorbur...@redhat.com | IRC: vorburger @freenode | 
~ = http://vorburger.ch

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

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

[controller-dev] [int/test] 401 from isolated cluster member?

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)]

Hello AAA devs.

I have a question, originally mentioned as a comment
in a Bug ... I am unable to locate right now.

Anyway, it is related to various bugs
such as 7792 [1] and 8209 [2].
As more specific symptoms (8214 [3], 8062 [4])
are fixed now, I begin to suspect the 401 status
is actually expected from an isolated cluster member.

I think AAA is storing some data to mdsal datastore,
which is of course inaccessible on minority partition.

Now, other http status codes (503) might be better,
but 401 is fine as long as it gets documented.

We will update suites to expect the agreed upon response.

Vratko.

[1] https://bugs.opendaylight.org/show_bug.cgi?id=7792
[2] https://bugs.opendaylight.org/show_bug.cgi?id=8209
[3] https://bugs.opendaylight.org/show_bug.cgi?id=8214
[4] https://bugs.opendaylight.org/show_bug.cgi?id=8062

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

Re: [controller-dev] How to set the execute permission for a shell script

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)]

>  



At least that is the only difference
from what we do in Odlparent [0] I see.
Of course that depends on the plugin version used.

Vratko.

[0] 
https://git.opendaylight.org/gerrit/gitweb?p=odlparent.git;a=blob;f=karaf/karaf-parent/pom.xml;h=f9e2ecb728fa5c53c62b2f811076703898d418ab;hb=refs/heads/master#l349

From: controller-dev-boun...@lists.opendaylight.org 
[mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Satish Dutt
Sent: 10 February, 2017 08:33
To: controller-us...@lists.opendaylight.org; 
controller-dev@lists.opendaylight.org
Subject: [controller-dev] How to set the execute permission for a shell script

Hi All,

I am trying to set the execute permission for one of the script using the maven 
directive in my project specific pom file like below :

  
org.apache.maven.plugins
maven-antrun-plugin


prepare-package

run


  


  


  



  


After the maven build is completed, I untarred the gz file. But in the scripts 
folder the test script is still no having the execute permission. Any ideas of 
how to make the script executable ?

Regards
-Satish
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [integration-dev] Clustering acceptance tests

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)]

Two more questions.

> https://jenkins.opendaylight.org/releng/view/CSIT-3node/job/openflowplugin-csit-3node-clustering-only-boron/
> Cluster non HA test

I just realized 1) and 2) are the same job.
I am not sure which of the six suites [1]
are you referring to.

>> but other tests are not, I will have to investigate this.
>
> Keep us informed.

Do you have an ETA?

Vratko.

[1] 
https://logs.opendaylight.org/releng/jenkins092/openflowplugin-csit-3node-clustering-only-carbon/470/archives/log.html.gz

From: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)
Sent: 7 February, 2017 15:05
To: 'Luis Gomez' <ece...@gmail.com>
Cc: integration-...@lists.opendaylight.org; 
controller-dev@lists.opendaylight.org; openflowplugin-dev 
<openflowplugin-...@lists.opendaylight.org>
Subject: RE: [integration-dev] Clustering acceptance tests

Thanks Luis.

> but other tests are not, I will have to investigate this.

Keep us informed.

> 3) & 4) is probably controller cluster limitation.

Both jobs occasionally pass,
and I have opened a Bug [0] for exceptions in karaf log.
To me, it looks like an error in OpenflowPlugin
(as opposed to Controller) code.

> writing very fast (REST or internal app) on a shard follower DS, and reading 
> on the other follower.

We plan to expand controller-csit-3node-rest-clust-cars-perf-only-carbon,
not sure yet whether this scenario will be included.

Vratko.

[0] https://bugs.opendaylight.org/show_bug.cgi?id=7750

From: Luis Gomez [mailto:ece...@gmail.com]
Sent: 7 February, 2017 08:35
To: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) 
<vrpo...@cisco.com<mailto:vrpo...@cisco.com>>
Cc: 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>;
 openflowplugin-dev 
<openflowplugin-...@lists.opendaylight.org<mailto:openflowplugin-...@lists.opendaylight.org>>
Subject: Re: [integration-dev] Clustering acceptance tests

Here is what I know from OpenFlow plugin (cc-ing ofplugin devs):

* Does your project have a test plan mentioning specific cluster scenarios?

Not written test plan but we are running a bunch of cluster tests.

* Do you have any of such scenarios implemented as Robot suites?

1) 
https://jenkins.opendaylight.org/releng/view/CSIT-3node/job/openflowplugin-csit-3node-clustering-only-boron/
 ->  Cluster HA test (DPN connect to all nodes), it used to pass except for 1 
test (member isolation with iptables), now I see this test is stable but other 
tests are not, I will have to investigate this.

2) 
https://jenkins.opendaylight.org/releng/view/CSIT-3node/job/openflowplugin-csit-3node-clustering-only-boron/
 -> Cluster non HA test (DPN connect to 1 node), failing because this old bug: 
https://bugs.opendaylight.org/show_bug.cgi?id=6459.

3) 
https://jenkins.opendaylight.org/releng/view/CSIT-3node/job/openflowplugin-csit-3node-periodic-bulkomatic-clustering-perf-daily-only-boron/
 -> Max flows/sec using bulk-o-matic DS on cluster setup. Not fully working 
because some cluster backend limitation 
https://bugs.opendaylight.org/show_bug.cgi?id=6755

4) 
https://jenkins.opendaylight.org/releng/view/CSIT-3node/job/openflowplugin-csit-3node-periodic-restconf-clustering-perf-daily-only-boron/
 -> Max flows/sec using NB REST on cluster setup, this never worked very good 
because previous bug.

* Do the robot suites have failures, suspected to be caused by clustering
  (as opposed to application logic, or mistakes in Robot code)?

So far I think issue in 2) is OpenFlow cluster implementation and issue in 3) & 
4) is probably controller cluster limitation.

* Are there open Bugs corresponding to the clustering failures?

Yes, except for 1) that will require some analysis on the unstable tests.

* Are you planning to implement more Robot 3node suites until Carbon release?

I will probably replace 1 of the performance suites (no point to run 2 if they 
do not work) by a cluster switch scalability test.

* Are there scenarios you would like Controller team to cover using mock apps?

I think issue in 3) & 4) could be reproduced in controller project by just 
writing very fast (REST or internal app) on a shard follower DS, and reading on 
the other follower.

On Feb 6, 2017, at 5:31 AM, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at 
Cisco) <vrpo...@cisco.com<mailto:vrpo...@cisco.com>> wrote:

Hello Test Contacts.

In Controller project, our highest priority
for Carbon release is to make sure ODL clustering
is usable and stable.

We are in the phase of formulating explicit acceptance criteria,
so we can create execution plan for turning them into Robot suites.

Of course, clustering is not very useful just by itself,
it is used as a tool applications can use to reach their goals.
So real acceptance criteria for clustering should also
take into account w

Re: [controller-dev] [integration-dev] Clustering acceptance tests

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)]

Thanks Luis.

> but other tests are not, I will have to investigate this.

Keep us informed.

> 3) & 4) is probably controller cluster limitation.

Both jobs occasionally pass,
and I have opened a Bug [0] for exceptions in karaf log.
To me, it looks like an error in OpenflowPlugin
(as opposed to Controller) code.

> writing very fast (REST or internal app) on a shard follower DS, and reading 
> on the other follower.

We plan to expand controller-csit-3node-rest-clust-cars-perf-only-carbon,
not sure yet whether this scenario will be included.

Vratko.

[0] https://bugs.opendaylight.org/show_bug.cgi?id=7750

From: Luis Gomez [mailto:ece...@gmail.com]
Sent: 7 February, 2017 08:35
To: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) 
<vrpo...@cisco.com>
Cc: integration-...@lists.opendaylight.org; 
controller-dev@lists.opendaylight.org; openflowplugin-dev 
<openflowplugin-...@lists.opendaylight.org>
Subject: Re: [integration-dev] Clustering acceptance tests

Here is what I know from OpenFlow plugin (cc-ing ofplugin devs):

* Does your project have a test plan mentioning specific cluster scenarios?

Not written test plan but we are running a bunch of cluster tests.


* Do you have any of such scenarios implemented as Robot suites?

1) 
https://jenkins.opendaylight.org/releng/view/CSIT-3node/job/openflowplugin-csit-3node-clustering-only-boron/
 ->  Cluster HA test (DPN connect to all nodes), it used to pass except for 1 
test (member isolation with iptables), now I see this test is stable but other 
tests are not, I will have to investigate this.

2) 
https://jenkins.opendaylight.org/releng/view/CSIT-3node/job/openflowplugin-csit-3node-clustering-only-boron/
 -> Cluster non HA test (DPN connect to 1 node), failing because this old bug: 
https://bugs.opendaylight.org/show_bug.cgi?id=6459.

3) 
https://jenkins.opendaylight.org/releng/view/CSIT-3node/job/openflowplugin-csit-3node-periodic-bulkomatic-clustering-perf-daily-only-boron/
 -> Max flows/sec using bulk-o-matic DS on cluster setup. Not fully working 
because some cluster backend limitation 
https://bugs.opendaylight.org/show_bug.cgi?id=6755

4) 
https://jenkins.opendaylight.org/releng/view/CSIT-3node/job/openflowplugin-csit-3node-periodic-restconf-clustering-perf-daily-only-boron/
 -> Max flows/sec using NB REST on cluster setup, this never worked very good 
because previous bug.

* Do the robot suites have failures, suspected to be caused by clustering
  (as opposed to application logic, or mistakes in Robot code)?

So far I think issue in 2) is OpenFlow cluster implementation and issue in 3) & 
4) is probably controller cluster limitation.


* Are there open Bugs corresponding to the clustering failures?

Yes, except for 1) that will require some analysis on the unstable tests.


* Are you planning to implement more Robot 3node suites until Carbon release?

I will probably replace 1 of the performance suites (no point to run 2 if they 
do not work) by a cluster switch scalability test.


* Are there scenarios you would like Controller team to cover using mock apps?

I think issue in 3) & 4) could be reproduced in controller project by just 
writing very fast (REST or internal app) on a shard follower DS, and reading on 
the other follower.

On Feb 6, 2017, at 5:31 AM, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at 
Cisco) <vrpo...@cisco.com<mailto:vrpo...@cisco.com>> wrote:

Hello Test Contacts.

In Controller project, our highest priority
for Carbon release is to make sure ODL clustering
is usable and stable.

We are in the phase of formulating explicit acceptance criteria,
so we can create execution plan for turning them into Robot suites.

Of course, clustering is not very useful just by itself,
it is used as a tool applications can use to reach their goals.
So real acceptance criteria for clustering should also
take into account whether ODL applications can work in cluster.

Many projects are already running their 3node CSIT tests,
but on one hand, some important scenarios might be not covered yet,
and some suites might be too unstable to serve as acceptance tests.

Controller team is small and busy, so we are asking for help.
Here is a set of quick questions for test contacts:
* Does your project have a test plan mentioning specific cluster scenarios?
* Do you have any of such scenarios implemented as Robot suites?
* Do the robot suites have failures, suspected to be caused by clustering
  (as opposed to application logic, or mistakes in Robot code)?
* Are there open Bugs corresponding to the clustering failures?
* Are you planning to implement more Robot 3node suites until Carbon release?
* Are there scenarios you would like Controller team to cover using mock apps?

Vratko (as a Controller test contact).
___
integration-dev mailing list
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org&g

[controller-dev] [int/test] [int/dist] Official clustering configuration

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)]

It seems some Bug reports are hard to reproduce
because reporters (sometimes even developers)
use different cluster configuration than CSIT tests.

Possible sources of this situation are outdated wiki pages,
outdated parts of User Guide and other ReadTheDocs documentation,
outdated templates and scripts laying around in Integration/Test repository,
and perhaps even Youtube videos, testing VMs and similar.

We should actively search for such sources of outdated information
and delete them, or at least attach a big warning.

The only recommended way to configure cluster (Beryllium, Boron, Carbon)
is configure-cluster.sh script (to be moved to Controller [0] soon).

Of course, some alternative configurations should work as well,
but some are actively discouraged, as they lead to known failure modes;
due to Akka limitations or Controller requirements.
Typical example is auto-down. Do not use it unless you are willing
to deal with cluster splitting to parts (in some isolation scenarios).

So please, if you encounter such an outdated source,
reply to this thread (possibly after fixing the source right away).

Vratko.

P.S.: Similar care should be taken when describing test scenarios.
Isolating all traffic is different from isolating all TCP traffic,
which is different from isolating only ports 2550 and 2551.
Killing Karaf is not the same as stopping Karaf.
Restarted Karaf can have persisted data wiped, or not.

[0] https://bugs.opendaylight.org/show_bug.cgi?id=7569
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] Benchmarking ODL - which repo holds the code?

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)]

Hi Richard.

As Coretutorials dropped from release,
the relevant code was migrated to Controller, tracked as [0].
It is possible that since then,
one copy has different improvements that the other one.

Basically, Coretutorials frequently contain code
which is not stable enough for Controller.
For example here is one improvement still under review [1].

There is also a Python utility for launching the test,
once again two copies (Coretutorials and Integration/Test).

In CSIT we only test released code,
that means the Java part from Controller.
The Python part from Integration/Test as that is easier to maintain.
An example of CSIT job is here [2].
(Click Plot to see the measured data.)

Vratko.

[0] https://bugs.opendaylight.org/show_bug.cgi?id=4519
[1] https://git.opendaylight.org/gerrit/49565
[2] 
https://jenkins.opendaylight.org/releng/view/controller/job/controller-csit-1node-periodic-benchmark-only-carbon

From: controller-dev-boun...@lists.opendaylight.org 
[mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of 
ricjh...@gmail.com
Sent: 6 January, 2017 02:41
To: controller-dev@lists.opendaylight.org
Subject: [controller-dev] Benchmarking ODL - which repo holds the code?


Hi folks

I want to benchmark ODL. So would like to know what is the relationship between 
the benchmark scripts and java code  in these two  repos.
-  https://github.com/opendaylight/coretutorials/tree/master/benchmark
- https://github.com/opendaylight/controller/tree/master/benchmark
Looking for a suggested starting point.  I have found the wiki here
https://wiki.opendaylight.org/view/Controller_Core_Functionality_Tutorials:Tutorials:Data_Store_Benchmarking_and_Data_Access_Patterns#The_Benchmark_Application
 and can extract a step by step guide if I know which of the two repos 
(controller, core-tutotials)  stores the relevant artifacts.

Sent from Mail for Windows 10

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

Re: [controller-dev] [int/dist] configure-cluster.sh and Controller project

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)]

Bug opened to track this:
https://bugs.opendaylight.org/show_bug.cgi?id=7569
Vratko.

From: controller-dev-boun...@lists.opendaylight.org 
[mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Vratko 
Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)
Sent: 10 January, 2017 18:26
To: controller-dev@lists.opendaylight.org
Cc: integration-...@lists.opendaylight.org
Subject: [controller-dev] [int/dist] configure-cluster.sh and Controller project

configure-cluster.sh is a script, currently maintained in 
Integration/Distribution.
It started as an improvement to the previous releng/builder scripts
which were exclusively used in CSIT 3node test jobs.

Instead of remaining a private utility for testing,
it got documented in Boron [0] making it an official deliverable.

The script is quite tightly coupled to current akka.conf
present in Controller project, any mismatch may lead to a Bug such as [1].

Controller project was never informed about this specific dependency.

Currently it is not clear whether the script should be an official deliverable
downstream users are encouraged to use.
If yes, what its API contract is, and who should maintain it?
If no, how much should Controller project care about it
when making changes to akka.conf?

Vratko.

[0] 
http://docs.opendaylight.org/en/stable-boron/getting-started-guide/common-features/clustering.html?highlight=configure-cluster#configure-cluster-script
[1] https://bugs.opendaylight.org/show_bug.cgi?id=7493
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

[controller-dev] [int/dist] configure-cluster.sh and Controller project

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)]

configure-cluster.sh is a script, currently maintained in 
Integration/Distribution.
It started as an improvement to the previous releng/builder scripts
which were exclusively used in CSIT 3node test jobs.

Instead of remaining a private utility for testing,
it got documented in Boron [0] making it an official deliverable.

The script is quite tightly coupled to current akka.conf
present in Controller project, any mismatch may lead to a Bug such as [1].

Controller project was never informed about this specific dependency.

Currently it is not clear whether the script should be an official deliverable
downstream users are encouraged to use.
If yes, what its API contract is, and who should maintain it?
If no, how much should Controller project care about it
when making changes to akka.conf?

Vratko.

[0] 
http://docs.opendaylight.org/en/stable-boron/getting-started-guide/common-features/clustering.html?highlight=configure-cluster#configure-cluster-script
[1] https://bugs.opendaylight.org/show_bug.cgi?id=7493
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [mdsal-dev] 3node cluster regression in Carbon - since Jan 5th

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)]

When you have a tight coupling like this,
general terms such as "controller people" or "the community"
rarely achieve the desired focus.

I prefer such notes to be as close to the code as possible.
https://git.opendaylight.org/gerrit/#/c/50140/1/opendaylight/md-sal/sal-clustering-config/src/main/resources/initial/akka.conf

Vratko.

-Original Message-
From: controller-dev-boun...@lists.opendaylight.org 
[mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Luis Gomez
Sent: 9 January, 2017 18:13
To: controller-dev@lists.opendaylight.org
Cc: netvirt-...@lists.opendaylight.org; genius-...@lists.opendaylight.org; 
Kochba, Alon ; mdsal-...@lists.opendaylight.org; 
integration-...@lists.opendaylight.org; Peretz, Ravit ; 
Aizer, Koby 
Subject: Re: [controller-dev] [mdsal-dev] 3node cluster regression in Carbon - 
since Jan 5th

Patch looks good but in future I would ask controller people to inform broadly 
the community when you do these changes specially if they impact the cluster 
configuration.

BR/Luis


> On Jan 9, 2017, at 5:28 AM, Peretz, Ravit  wrote:
> 
> CSIT uses configure_cluster.sh to configure 3node jobs which creates 
> akka.conf with akka.tcp instead of akka.
> 
> Please review my fix patch:
> https://git.opendaylight.org/gerrit/50129
> 
> Thanks,
> Ravit.
> 
> -Original Message-
> From: Tomas Cere -X (tcere - PANTHEON TECHNOLOGIES at Cisco) 
> [mailto:tc...@cisco.com]
> Sent: יום ב 09 ינואר 2017 15:00
> To: Robert Varga ; Peretz, Ravit ; 
> integration-...@lists.opendaylight.org; 
> netvirt-...@lists.opendaylight.org; genius-...@lists.opendaylight.org; 
> controller-dev@lists.opendaylight.org; 
> mdsal-...@lists.opendaylight.org
> Cc: Aizer, Koby ; Kochba, Alon 
> Subject: RE: [controller-dev] [mdsal-dev] 3node cluster regression in 
> Carbon - since Jan 5th
> 
> It's already tracked by : 
> https://bugs.opendaylight.org/show_bug.cgi?id=7493
> I suspect it's the tests providing their own akka.conf which does not have 
> the artery setup included.
> 
> Tomas
> 
> -Original Message-
> From: controller-dev-boun...@lists.opendaylight.org 
> [mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of 
> Robert Varga
> Sent: Monday, January 09, 2017 13:59
> To: Peretz, Ravit ; 
> integration-...@lists.opendaylight.org; 
> netvirt-...@lists.opendaylight.org; genius-...@lists.opendaylight.org; 
> controller-dev@lists.opendaylight.org; 
> mdsal-...@lists.opendaylight.org
> Cc: Aizer, Koby ; Kochba, Alon 
> Subject: Re: [controller-dev] [mdsal-dev] 3node cluster regression in 
> Carbon - since Jan 5th
> 
> 
> 
> On 01/09/2017 01:53 PM, Peretz, Ravit wrote:
>> Hi all,
>> 
>> 
>> 
>> It seems like there is a massive 3node cluster regression in carbon, 
>> since approximately 21:0PM January 5^th .
>> 
>> We can see that many 3node CSIT fails across projects.
>> 
>> 
>> 
>> After a quick look Koby and I have found what we assume is the faulty 
>> zip.  We looked at the last successful openflowplugin-3 node run:
>> 
>> https://logs.opendaylight.org/releng/jenkins092/openflowplugin-csit-3
>> n ode-clustering-only-carbon/379/console.log.gz
>> 
>> which used distribution: 0.6.0-20170105.205720-2879.zip
>> 
>> 
>> 
>> the next run failed, with the same error we are seeing now in all 
>> runs (at least the few we checked):
>> 
>> https://logs.opendaylight.org/releng/jenkins092/openflowplugin-csit-3
>> n ode-clustering-only-carbon/380/console.log.gz
>> 
>> which used distribution: 0.6.0-20170105.235121-2883.zip
>> 
>> 
>> 
>> 
>> 
>> we were able to narrow it down to a single distribution that was the 
>> first to fail:
>> 
>> https://logs.opendaylight.org/releng/jenkins092/netvirt-legacy-csit-3
>> n ode-clustering-only-carbon/144/console.log.gz
>> 
>> 0.6.0-20170105.222635-2880.zip
>> 
>> 
>> 
>> *We would appreciate your help with narrowing down the faulty 
>> commit/s triggering the 0.6.0-20170105.222635-2880.zip distribution.*
>> 
>> 
>> 
>> 
>> 
>> The first error we saw in the logs is :
>> 2017-01-06 05:25:30,158 | ERROR | lt-dispatcher-12 |
>> ClusterActorRefProvider  | 199 - com.typesafe.akka.slf4j -
>> 2.4.16 | No root guardian at
>> [akka.tcp://opendaylight-cluster-data@10.29.13.119:2550]
>> 
>> java.lang.IllegalArgumentException: Wrong protocol of 
>> [akka.tcp://opendaylight-cluster-data@10.29.13.119:2550/], expected 
>> [akka]
> 
> Looks like mismatch in setup, this is related to akka artery -- the protocol 
> should be akka, not akka.tcp. Where is this configuration coming from?
> 
> Regards,
> Robert
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
> ___
> 

Re: [controller-dev] Controller to controller communication!

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)]

My first idea would be to use netconf.
Feature odl-netconf-mdsal enables ODL netconf server
allowing access to mdsal datastore.
Feature odl-netconf-clustered-topology enables ODL
to connect to other netconf devices,
their data appear as yang-ext:mount in restconf
(not sure which API gives best performance from within Java).

> Please guide me through this.

Netconf user guide has some basic intro.
It mentions netconf connector feature,
which is not recommended in Carbon as it is not cluster compatible,
but it should work for single ODL nodes.

Vratko.

From: controller-dev-boun...@lists.opendaylight.org 
[mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Pragati 
Shrivastava
Sent: 25 November, 2016 12:16
To: Muthukumaran K 
Cc: controller-dev 
Subject: Re: [controller-dev] Controller to controller communication!

Hi Muthukumaran,
Thank you,
My use case is not clustering, I want to deploy independent ODL controllers and 
establish communication between them.
Horizontal implementation of controllers.
Please guide me through this.

On Fri, Nov 25, 2016 at 4:00 PM, Muthukumaran K 
> wrote:
Hi Pragati,

Are you looking for clustering of ODL ? If so, you may want to have a look at a 
good introduction here - https://www.youtube.com/watch?v=A9wAAbvliR0
Also, there are presentations on ODL wiki on clustering.

ODL clustering internally uses inter-node (controller instances) communication 
using messaging and provide higher level abstractions like 
clusterwide-data-change-notifications (or in other words, you can setup 
listeners clusterwide and receive notifications whenever MD-SAL datastore data 
is changed).

I am not sure if that is something which suits your usecase. But, if you could 
explain your specific usecase, it would be easier to see if any existing 
mechanisms can be used

Regards
Muthu



From: 
controller-dev-boun...@lists.opendaylight.org
 
[mailto:controller-dev-boun...@lists.opendaylight.org]
 On Behalf Of Pragati Shrivastava
Sent: Friday, November 25, 2016 3:29 PM
To: controller-dev 
>
Subject: [controller-dev] Controller to controller communication!

Hi all,
I want to exchange messages between two open-daylight controllers.
How is it possible? Is there any API which is helpful to establish 
communication between two different open-daylight controllers.
Please guide me through this.
Thank you.
--
Pragati Shrivastava
Phd Scholar,
Dept. of Computer Science & Engineering,
Indian Institute of Technology Hyderabad,
Email: cs14resch11...@iith.ac.in
pragatipr...@gmail.com
Cell: 09966154652



--
Pragati Shrivastava
Phd Scholar,
Dept. of Computer Science & Engineering,
Indian Institute of Technology Hyderabad,
Email: cs14resch11...@iith.ac.in
pragatipr...@gmail.com
Cell: 09966154652
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [controller-users] About "packages use conflict"

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)]

+controller-dev may be more suitable for such technical discussion.

> Package uses conflict: Import-Package: 
> org.opendaylight.yangtools.yang.common; version="[1.0.0,2.0.0)"

I would guess your bundle depends on that,
but your feature descriptor does not list
odl-yangtools-common feature dependency.
There may be other reasons.

> The bundle could successfully run “mvn clean install”

I recommend using inheriting from features-parent (odlparent project).
It allows you to use {{VERSION}} placeholder to simplify things,
and it runs SingleFeatureTest, catching errors like these during build.

Vratko.

-Original Message-
From: controller-users-boun...@lists.opendaylight.org 
[mailto:controller-users-boun...@lists.opendaylight.org] On Behalf Of ???
Sent: 21 November, 2016 09:48
To: controller-us...@lists.opendaylight.org
Subject: [controller-users] About "packages use conflict"

Hi there, 

I work on my own app (ODL plugin), and I got packages use conflict problem.

The bundle could successfully run “mvn clean install”, however during 
“feature:install” it gave me something like this:

opendaylight-user@root>feature:install algoblu-topology-manager

Error executing command: Can't install feature algoblu-topology-manager/0.0.0:

Could not start bundle mvn:com.algoblu.networkManager/topologyImpl/1.0.0 in 
feature(s) algoblu-topology-impl-1.0.0, algoblu-topology-manager-1.0.0: The 
bundle "com.algoblu.networkManager.topologyImpl_1.0.0 [328]" could not be 
resolved.

Reason: 
Package uses conflict: Import-Package: 
org.opendaylight.controller.config.yang.md.sal.binding; 
version="[1.4.0,2.0.0)”, 

Package uses conflict: Import-Package: 
org.opendaylight.controller.md.sal.binding.api; version="[1.4.0,2.0.0)”, 

Package uses conflict: Import-Package: org.opendaylight.yangtools.yang.common; 
version="[1.0.0,2.0.0)"

opendaylight-user@root>   

Might I ask how should I solve this? Or where should I start to look into?

Best Regards,

Irving

___
controller-users mailing list
controller-us...@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-users
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev