[controller-dev] Issues when using AbstractDataBrokerTest

[Satish Dutt]

Hi,

I am extending the AbstractDataBrokerTest for writing my unit TCs. As part of 
AbstractDataBrokerTest -> setupWithSchema(), DataBrokerTestCustomizer is 
instantiated where the SchemaContext is being registered with the 
SchemaService. But the SchemaContext is always null. Is there any issues in the 
org.opendaylight.controller.md.sal.binding.test.DataBrokerTestCustomizer ? I am 
using Boron SR3 release


public class AbstractDataBrokerTest extends AbstractSchemaAwareTest {

private DataBrokerTestCustomizer testCustomizer;
private DataBroker dataBroker;
private DOMDataBroker domBroker;


@Override
protected void setupWithSchema(final SchemaContext context) {
testCustomizer = createDataBrokerTestCustomizer();
dataBroker = testCustomizer.createDataBroker();
...
...
...
}
}

public class DataBrokerTestCustomizer {

private DOMDataBroker domDataBroker;
private final DOMNotificationRouter domNotificationRouter;
private final MockSchemaService schemaService;
...


public DataBrokerTestCustomizer() {
schemaService = new MockSchemaService();
final ClassPool pool = ClassPool.getDefault();
final DataObjectSerializerGenerator generator = 
StreamWriterGenerator.create(JavassistUtils.forClassPool(pool));
final BindingNormalizedNodeCodecRegistry codecRegistry = new 
BindingNormalizedNodeCodecRegistry(generator);
final GeneratedClassLoadingStrategy loading = 
GeneratedClassLoadingStrategy.getTCCLClassLoadingStrategy();
bindingToNormalized = new BindingToNormalizedNodeCodec(loading, 
codecRegistry);
schemaService.registerSchemaContextListener(bindingToNormalized);
}

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

Re: [controller-dev] List element cohort validation causes issue

[Satish Dutt]

Thanks Tom

-Satish

From: Tom Pantelis <tompante...@gmail.com>
Sent: Sunday, March 11, 2018 9:09 AM
To: Satish Dutt <sd...@advaoptical.com>
Cc: controller-dev@lists.opendaylight.org
Subject: Re: [controller-dev] List element cohort validation causes issue



On Sat, Mar 10, 2018 at 11:53 AM, Satish Dutt 
<sd...@advaoptical.com<mailto:sd...@advaoptical.com>> wrote:
Hi All,

I have a cohort validation for the list element. If I try to create the entire 
list having multiple items, I am getting the below error. If I try to create a 
single list element, then its successful.  Is there any way I can avoid this 
issue. I am trying this in Boron-SR3


2018-03-07 14:53:01,681 | ERROR | ult-dispatcher-4 | OneForOneStrategy  
  | 153 - com.typesafe.akka.slf4j - 2.4.7 | Unexpected message class 
org.opendaylight.controller.cluster.datastore.DataTreeCohortActor$CanCommit in 
cohort behavior PostCanCommit
java.lang.UnsupportedOperationException: Unexpected message class 
org.opendaylight.controller.cluster.datastore.DataTreeCohortActor$CanCommit in 
cohort behavior PostCanCommit
at 
org.opendaylight.controller.cluster.datastore.DataTreeCohortActor$CohortBehaviour.handle(DataTreeCohortActor.java:152)[170:org.opendaylight.controller.sal-distributed-datastore:1.4.3.Boron-SR3]
at 
org.opendaylight.controller.cluster.datastore.DataTreeCohortActor.handleReceive(DataTreeCohortActor.java:45)[170:org.opendaylight.controller.sal-distributed-datastore:1.4.3.Boron-SR3]
at 
org.opendaylight.controller.cluster.common.actor.AbstractUntypedActor.onReceive(AbstractUntypedActor.java:26)[164:org.opendaylight.controller.sal-clustering-commons:1.4.3.Boron-SR3]
at 
akka.actor.UntypedActor$$anonfun$receive$1.applyOrElse(UntypedActor.scala:165)[152:com.typesafe.akka.actor:2.4.7]
at 
akka.actor.Actor$class.aroundReceive(Actor.scala:484)[152:com.typesafe.akka.actor:2.4.7]
at 
akka.actor.UntypedActor.aroundReceive(UntypedActor.scala:95)[152:com.typesafe.akka.actor:2.4.7]
at 
akka.actor.ActorCell.receiveMessage(ActorCell.scala:526)[152:com.typesafe.akka.actor:2.4.7]
at 
akka.actor.ActorCell.invoke(ActorCell.scala:495)[152:com.typesafe.akka.actor:2.4.7]
at 
akka.dispatch.Mailbox.processMailbox(Mailbox.scala:257)[152:com.typesafe.akka.actor:2.4.7]
at 
akka.dispatch.Mailbox.run(Mailbox.scala:224)[152:com.typesafe.akka.actor:2.4.7]
at 
akka.dispatch.Mailbox.exec(Mailbox.scala:234)[152:com.typesafe.akka.actor:2.4.7]
at 
scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)[148:org.scala-lang.scala-library:2.11.8.v20160304-115712-1706a37eb8]
at 
scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)[148:org.scala-lang.scala-library:2.11.8.v20160304-115712-1706a37eb8]
at 
scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)[148:org.scala-lang.scala-library:2.11.8.v20160304-115712-1706a37eb8]
at 
scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)[148:org.scala-lang.scala-library:2.11.8.v20160304-115712-1706a37eb8]


This was fixed by https://git.opendaylight.org/gerrit/#/c/51584/ which is in 
Nitrogen.


Regards
-Satish

___
controller-dev mailing list
controller-dev@lists.opendaylight.org<mailto: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] List element cohort validation causes issue

[Satish Dutt]

Hi All,

I have a cohort validation for the list element. If I try to create the entire 
list having multiple items, I am getting the below error. If I try to create a 
single list element, then its successful.  Is there any way I can avoid this 
issue. I am trying this in Boron-SR3


2018-03-07 14:53:01,681 | ERROR | ult-dispatcher-4 | OneForOneStrategy  
  | 153 - com.typesafe.akka.slf4j - 2.4.7 | Unexpected message class 
org.opendaylight.controller.cluster.datastore.DataTreeCohortActor$CanCommit in 
cohort behavior PostCanCommit
java.lang.UnsupportedOperationException: Unexpected message class 
org.opendaylight.controller.cluster.datastore.DataTreeCohortActor$CanCommit in 
cohort behavior PostCanCommit
at 
org.opendaylight.controller.cluster.datastore.DataTreeCohortActor$CohortBehaviour.handle(DataTreeCohortActor.java:152)[170:org.opendaylight.controller.sal-distributed-datastore:1.4.3.Boron-SR3]
at 
org.opendaylight.controller.cluster.datastore.DataTreeCohortActor.handleReceive(DataTreeCohortActor.java:45)[170:org.opendaylight.controller.sal-distributed-datastore:1.4.3.Boron-SR3]
at 
org.opendaylight.controller.cluster.common.actor.AbstractUntypedActor.onReceive(AbstractUntypedActor.java:26)[164:org.opendaylight.controller.sal-clustering-commons:1.4.3.Boron-SR3]
at 
akka.actor.UntypedActor$$anonfun$receive$1.applyOrElse(UntypedActor.scala:165)[152:com.typesafe.akka.actor:2.4.7]
at 
akka.actor.Actor$class.aroundReceive(Actor.scala:484)[152:com.typesafe.akka.actor:2.4.7]
at 
akka.actor.UntypedActor.aroundReceive(UntypedActor.scala:95)[152:com.typesafe.akka.actor:2.4.7]
at 
akka.actor.ActorCell.receiveMessage(ActorCell.scala:526)[152:com.typesafe.akka.actor:2.4.7]
at 
akka.actor.ActorCell.invoke(ActorCell.scala:495)[152:com.typesafe.akka.actor:2.4.7]
at 
akka.dispatch.Mailbox.processMailbox(Mailbox.scala:257)[152:com.typesafe.akka.actor:2.4.7]
at 
akka.dispatch.Mailbox.run(Mailbox.scala:224)[152:com.typesafe.akka.actor:2.4.7]
at 
akka.dispatch.Mailbox.exec(Mailbox.scala:234)[152:com.typesafe.akka.actor:2.4.7]
at 
scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)[148:org.scala-lang.scala-library:2.11.8.v20160304-115712-1706a37eb8]
at 
scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)[148:org.scala-lang.scala-library:2.11.8.v20160304-115712-1706a37eb8]
at 
scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)[148:org.scala-lang.scala-library:2.11.8.v20160304-115712-1706a37eb8]
at 
scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)[148:org.scala-lang.scala-library:2.11.8.v20160304-115712-1706a37eb8]


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

[controller-dev] How to get HTTP request details ?

[Satish Dutt]

Hi All,

Is there any way to know the HTTP request details in any of User-defined Cohort 
class which extends the DomDataTreeCohort of the package 
org.opendaylight.mdsal.dom.api package ?

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

Re: [controller-dev] [mdsal-dev] How to increase the timeout value for a commit operation to the data store ?

[Satish Dutt]

Hi Anil,

I completely agree with your comments. It would be great if the cohort timeout 
value is configurable as per the UCs requisites.

Regards
-Satish

From: controller-dev-boun...@lists.opendaylight.org 
[mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Anil Vishnoi
Sent: Wednesday, May 17, 2017 5:32 AM
To: Robert Varga 
Cc: controller-dev@lists.opendaylight.org; mdsal-...@lists.opendaylight.org
Subject: Re: [controller-dev] [mdsal-dev] How to increase the timeout value for 
a commit operation to the data store ?



On Tue, May 16, 2017 at 3:05 PM, Robert Varga > 
wrote:
On 16/05/17 20:40, Anil Vishnoi wrote:
> Tom,
>
> I think it depends on the use case for which user is using cohort. For
> example If user have a use case where it sends very few rest request to
> the controller from northbound side but want to make sure it runs all
> the possible checks against that data to make sure that it can avoid any
> wrong configuration (according to the use case and not really as per
> yang schema). In general i agree with you that anything that takes more
> then 5 second, it's better to probably write that logic in the
> application rather than in the cohort, but we don't know all the use
> cases people use it for. So i think having a config knob (with default
> value to 5 second or lower) will give user an option to change it
> (increase or decrease) as per their usecase.

Note that this fires for any change in the registered subtree and no
other transactions involving that shard can make forward progress until
the cohort finishes preCommit().

This API is very strict and should be used only as a last resort at this
point. As the associated documentation states very explictly, any bugs
in a user of the API has cluster-wide consequences which manifest as
'CDS is broken'.
​I think it's pretty clear from the documentation.​

That implies you should not be talking to the data store and expect it
to respond in the cohort -- which begs the question: what sort of
validation takes more than 5 seconds?
​I think given the context API sets, even 1 second is a high value, so what 
kind of transaction can even take 5 seconds, let aside more than 5 second ? For 
example for my application I might even prefer to use 1 second, but there is no 
way to configure it as of now. So rather than assuming that no cohort will take 
more then 5 second, let user decide what value they want to use based on their 
use case.

Bye,
Robert



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

Re: [controller-dev] [mdsal-dev] How to increase the timeout value for a commit operation to the data store ?

[Satish Dutt]

Thanks Anil. I was able to change the timeout value through the code and its 
working fine.

Regards
-Satish

From: Anil Vishnoi [mailto:vishnoia...@gmail.com]
Sent: Tuesday, May 16, 2017 7:50 AM
To: Michael Vorburger <vorbur...@redhat.com>
Cc: Satish Dutt <sd...@advaoptical.com>; controller-dev@lists.opendaylight.org; 
mdsal-...@lists.opendaylight.org
Subject: Re: [controller-dev] [mdsal-dev] How to increase the timeout value for 
a commit operation to the data store ?

I believe this is where it is set

https://github.com/opendaylight/controller/blob/master/opendaylight/md-sal/sal-distributed-datastore/src/main/java/org/opendaylight/controller/cluster/datastore/ShardDataTree.java#L106

Not sure if there is any way to configure it though any akka/cluster config 
knob.

On Mon, May 15, 2017 at 8:23 AM, Michael Vorburger 
<vorbur...@redhat.com<mailto:vorbur...@redhat.com>> wrote:
On Mon, May 15, 2017 at 5:06 PM, Satish Dutt 
<sd...@advaoptical.com<mailto:sd...@advaoptical.com>> wrote:
Hi Michael,

Thanks for your response. I am writing a custom cohort class for some 
validation purpose, which extends the DOMDataTreeCommitCohort of the 
mdsal.dom.api package and overrides the canCommit(). canCommit() in my cohort 
does some validations and just return a Future object indicating success or 
failure. I am NOT actually timing out the Future . Sometimes my cohort class 
takes more than 5 seconds to execute and the MDSAL commit times-out.

Oh you didn't specify that in your first email... sorry, I don't know anything 
more about this; maybe others will chime in.

I  suspect  that some classes in MDSAL are probably timing out the commit, 
since it is exceeding the default timeout value of 5 seconds. But in my 
application, I can wait for more than 5 seconds possibly around 20 seconds for 
doing the validation. For this I want to know the code of the MDSAL which I can 
tweak for setting a higher timeout value and use that code locally in my 
application.

  "errors": {
"error": [
  {
"error-type": "application",
"error-tag": "operation-failed",
"error-message": "canCommit encountered an unexpected failure",
"error-info": "java.util.concurrent.TimeoutException: Futures timed out 
after [5 seconds]\n\tat 
scala.concurrent.impl.Promise$DefaultPromise.ready(Promise.scala:219)\n\tat 
scala.concurrent.impl.Promise$DefaultPromise.result(Promise.scala:223)\n\tat 
scala.concurrent.Await$$anonfun$result$1.apply(package.scala:190)\n\tat 
akka.dispatch.MonitorableThreadFactory$AkkaForkJoinWorkerThread$$anon$3.block(ThreadPoolBuilder.scala:167)\n\tat
 
scala.concurrent.forkjoin.ForkJoinPool.managedBlock(ForkJoinPool.java:3640)\n\tat
 
akka.dispatch.MonitorableThreadFactory$AkkaForkJoinWorkerThread.blockOn(ThreadPoolBuilder.scala:165)\n\tat
 scala.concurrent.Await$.result(package.scala:190)\n\tat 
scala.concurrent.Await.result(package.scala)\n\tat 
org.opendaylight.controller.cl<http://org.opendaylight.controller.cl>uster.datastore.CompositeDataTreeCohort.processResponses(CompositeDataTreeCohort.java:162)\n\tat
 
org.opendaylight.controller.cl<http://org.opendaylight.controller.cl>uster.datastore.CompositeDataTreeCohort.canCommit(CompositeDataTreeCohort.java:122)\n\tat
 
org.opendaylight.controller.cl<http://org.opendaylight.controller.cl>uster.datastore.SimpleShardDataTreeCohort.userPreCommit(SimpleShardDataTreeCohort.java:162)\n\tat
 
org.opendaylight.controller.cl<http://org.opendaylight.controller.cl>uster.datastore.ShardDataTree.startPreCommit(ShardDataTree.java:584)\n\tat
 
org.opendaylight.controller.cl<http://org.opendaylight.controller.cl>uster.datastore.SimpleShardDataTreeCohort.preCommit(SimpleShardDataTreeCohort.java:91)\n\tat
 
org.opendaylight.controller.cl<http://org.opendaylight.controller.cl>uster.datastore.CohortEntry.pr<http://uster.datastore.CohortEntry.pr>eCommit(CohortEntry.java:102)\n\tat
 
org.opendaylight.controller.cl<http://org.opendaylight.controller.cl>uster.datastore.ShardCommitCoordinator.doCommit(ShardCommitCoordinator.java:296)\n\tat
 
org.opendaylight.controller.cl<http://org.opendaylight.controller.cl>uster.datastore.ShardCommitCoordinator.access$200(ShardCommitCoordinator.java:49)\n\tat
 
org.opendaylight.controller.cl<http://org.opendaylight.controller.cl>uster.datastore.ShardCommitCoordinator$2.onSuccess(ShardCommitCoordinator.java:243)\n\tat
 
org.opendaylight.controller.cl<http://org.opendaylight.controller.cl>uster.datastore.ShardCommitCoordinator$2.onSuccess(ShardCommitCoordinator.java:237)\n\tat
 
org.opendaylight.controller.cl<http://org.opendaylight.controller.cl>uster.datastore.SimpleShardDataTreeCohort.successfulCanCommit(SimpleShardDataTreeCohort.java:145)\n\tat
 
org.opendaylight.controller.cl<http://org.opendaylight.contro

[controller-dev] How to increase the timeout value for a commit operation to the data store ?

[Satish Dutt]

Hi,

Is there any way to increase the timeout value for a commit operation to the 
datastore ? Sometimes I get timeout value during the commit operation

{
  "errors": {
"error": [
  {
"error-type": "application",
"error-tag": "operation-failed",
"error-message": "canCommit encountered an unexpected failure",
"error-info": "java.util.concurrent.TimeoutException: Futures timed out 
after [5 seconds]\n\tat

scala.concurrent.impl.Promise$DefaultPromise.ready(Promise.scala:219)\n\tat
 ...
 ...
 ...

akka.dispatch.Mailbox.exec(Mailbox.scala:234)\n\tat 
scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)\n\tat 
scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)\n\tat

scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)\n\tat 
scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)\n"
  }
]
  }
}

Regards
-Satish

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

[controller-dev] PATCH response not having the error details

[Satish Dutt]

Hi,

I am using yang-patch to modify some of the leaf node values. But whenever the 
PATCH request fails, it is not giving the cause of the failure unlike the POST 
or PUT methods, but just gives an one-liner error that "canCommit encountered 
an unexpected failure". Is there any way in which the PATCH response can give 
the details regarding the failure ?

In the below example I am trying to modify one of the attribute leaf node 
'hostname' value of a non-existing list node "12' . Ideally it is expected that 
it PATCH should report the data does not exist for the node 12, but it is 
reporting "canCommit encountered an unexpected failure". How to make the PATCH 
response to have more details in the error message ?

GET : http://{{ipaddr}}:8181/restconf/config/connector-config:connectors
{
  "connectors": {
"connector": [
  {
"uid": "7",
"mgmt-ip": "1.1.1.1",
"hostname": "onus.org"
  }
]
  }
}


PATCH request : 
http://{{ipaddr}}:8181/restconf/config/connector-config:connectors
{"ietf-restconf:yang-patch" : {
"patch-id" : "0",
"edit" :[
  {
"edit-id" : "edit1",
"operation" : "merge",
"target" : "/connector-config:connector[connector-config:uid ='12']",
"value":  {
   "connector" : {
   "uid":"12",
   "hostname": "opendaylight.org"
   }
}
  }
]
  }
}


PATCH response :
{
  "ietf-yang-patch:yang-patch-status": {
"patch-id": "0",
"errors": {
  "error": [
{
  "error-type": "application",
  "error-tag": "operation-failed",
  "error-message": "canCommit encountered an unexpected failure"
}
  ]
},
"edit-status": {
  "edit": [
{
  "edit-id": "edit1",
  "ok": [
null
  ]
}
  ]
}
  }
}

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

[controller-dev] Timeout value of Cohert methods

[Satish Dutt]

Hi Tomas,

Currently the canCommit() of DomDataTreeCohert will timeout in 5 seconds. How 
can this timeout value be increased ?

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

[controller-dev] Cohert not getting triggered for augmented nodes

[Satish Dutt]

Hi Tomas,

I am writing a Cohert trying to validate a subtree data, which is augmented to 
a target node in the same module. For registering the cohert, I am creating an 
instance of the same and also the DomDataTreeIdentifier by using the 
YangInstanceIdentifier instance having the sub-tree path. Registration does not 
throw any exception, but the canCommit() of my cohert is not triggered whenever 
I push the JSON data to the sub-tree. I have put below the yang and the code 
snippets. Is the way of registering the subtree for the the Cohert validations 
wrong in my case ? Please advise.

container controller {
}

module connector-config {
...
...

container controller {
}

/*
* Augumented -> controllerconfig management model
*/
augment "/controller" {
ext:augment-identifier ControllerMgmtAugmentation;
container controller-common-mgmt {
config true;
list tenant {
key id;
leaf id {
type string;
description "ID of tenant";
mandatory true;
}

Description "Tenant details";
uses controller-common-group;
 }
}
}
...
...
}

@Override
public synchronized Future registerCommitCohort() {
...
...
  final YangInstanceIdentifier connectorConfigPath = 
YangInstanceIdentifier.builder(

YangInstanceIdentifier.of(Controller.QNAME)).node(ControllerCommonMgmt.QNAME).
node(Tenant.QNAME).node(Tenant.QNAME).build();


commitCohortReg.set(commitCohortRegistry.registerCommitCohort(
new org.opendaylight.mdsal.dom.api.DOMDataTreeIdentifier(

org.opendaylight.mdsal.common.api.LogicalDatastoreType.CONFIGURATION,
connectorConfigPath), new 
ConnectorDataTreeCommitCohort(domDataBroker, dataProvider)));

return RpcResultBuilder.success().buildFuture();
}

Regards,
-Satish

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

[controller-dev] IncorrectNestingException when writing to an augmented data-tree

[Satish Dutt]

Hi,

I have created a project using boron-SR3 archetype. In one of the yang I have 
augmented a container. In the code (File3.java) I am trying to write the data 
to that container to the DataStore, but I am getting IncorrectNestingException 
exception.  The same code is working fine in the boron stable project. Below 
are the yang and code snippets. So is this a bug in the boron-SR3 ?

File1.yang :
module test-controller {
yang-version 1;
namespace "http://www.test.com/controllerconfiguration/core;;
prefix "testconfig";
description "";

revision "2016-09-22" {
description "Initial revision of model";
}

container controller {
}
}

File2.yang :
module device-config {
yang-version 1;

namespace 
"urn:opendaylight:params:xml:ns:yang:controller:config:sal-clustering-it:device-config";

prefix "deviceconfig";

import test-controller { prefix testconfig; revision-date 2016-09-22; }

import yang-ext { prefix ext; }
import ietf-inet-types { prefix "inet-types"; revision-date 2013-07-15; }

revision "2016-09-28" {
description "Initial revision of connector configuration model";
}

grouping controller-common-group {
container version-info {
leaf version {
type string;
mandatory true;
description
"Controller version.";
}
}

}

/*
* Augumented
*/
augment "/testconfig:controller" {
ext:augment-identifier ControllerMgmtAugmentation;
container controller-common-mgmt {
config false;
description
   "Controller version";
uses controller-common-group;
}
}

}


File3.java :

VersionInfoBuilder versionInfoBuilder = new VersionInfoBuilder();
versionInfoBuilder.setVersion("17.1.1.1");
InstanceIdentifier in = 
InstanceIdentifier.create(Controller.class)

.augmentation(ControllerMgmtAugmentation.class).child(ControllerCommonMgmt.class)
.child(VersionInfo.class);
WriteTransaction writeTranaction = dataBroker.newWriteOnlyTransaction();
writeTranaction.merge(LogicalDatastoreType.OPERATIONAL, in, 
versionInfoBuilder.build(), true);
writeTranaction.submit();


File4.java :


public interface ControllerMgmtAugmentation
extends
DataObject,
Augmentation
{




/**
 * Controller version and backup details.
 *
 *
 *
 * @return 
org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.controller.config.sal.clustering.it.device.config.rev160928.controller.ControllerCommonMgmt
 controllerCommonMgmt, or null if not present
 */
ControllerCommonMgmt getControllerCommonMgmt();

}

LOG Traces :
2017-04-14 17:33:17,565 | ERROR | on-dispatcher-34 | 
DataTreeChangeListenerActor  | 176 - 
org.opendaylight.controller.sal-distributed-datastore - 1.4.3.Boron-SR3 | Error 
notify
ing listener 
org.opendaylight.controller.md.sal.binding.impl.BindingDOMDataTreeChangeListenerAdapter@85aac52
org.opendaylight.yangtools.binding.data.codec.impl.IncorrectNestingException: 
Class interface 
org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.controller.config.sal
.clustering.it.device.config.rev160928.ControllerMgmtAugmentation is not valid 
child of interface 
org.opendaylight.yang.gen.v1.http.www.test.com.controllerconfiguration.core.rev160
922.Controller
at 
org.opendaylight.yangtools.binding.data.codec.impl.IncorrectNestingException.create(IncorrectNestingException.java:28)[74:org.opendaylight.mdsal.binding-dom-codec:0.9.3.
Boron-SR3]
at 
org.opendaylight.yangtools.binding.data.codec.impl.DataContainerCodecContext.childNonNull(DataContainerCodecContext.java:180)[74:org.opendaylight.mdsal.binding-dom-codec
:0.9.3.Boron-SR3]
at 
org.opendaylight.yangtools.binding.data.codec.impl.DataObjectCodecContext.bindingPathArgumentChild(DataObjectCodecContext.java:184)[74:org.opendaylight.mdsal.binding-dom
-codec:0.9.3.Boron-SR3]
at 
org.opendaylight.yangtools.binding.data.codec.impl.BindingCodecContext.getCodecContextNode(BindingCodecContext.java:127)[74:org.opendaylight.mdsal.binding-dom-codec:0.9.
3.Boron-SR3]
at 
org.opendaylight.yangtools.binding.data.codec.impl.BindingCodecContext.newWriter(BindingCodecContext.java:104)[74:org.opendaylight.mdsal.binding-dom-codec:0.9.3.Boron-SR
3]
at 
org.opendaylight.yangtools.binding.data.codec.impl.BindingNormalizedNodeCodecRegistry.toNormalizedNode(BindingNormalizedNodeCodecRegistry.java:102)[74:org.opendaylight.m
dsal.binding-dom-codec:0.9.3.Boron-SR3]
at 
org.opendaylight.controller.md.sal.binding.impl.BindingToNormalizedNodeCodec.toNormalizedNode(BindingToNormalizedNodeCodec.java:135)[146:org.opendaylight.controller.sal-
binding-broker-impl:1.4.3.Boron-SR3]
at 

Re: [controller-dev] Getting RPC error when registering my cohert

[Satish Dutt]

Thanks for the clarification. Is there any way we can set the response code in 
the canCommit() method of the cohert in case of failure ?

Regards,
-Satish

From: Tom Pantelis [mailto:tompante...@gmail.com]
Sent: Monday, April 03, 2017 7:34 PM
To: Satish Dutt <sd...@advaoptical.com>
Cc: tpant...@brocade.com; controller-dev@lists.opendaylight.org; 
controller-us...@lists.opendaylight.org
Subject: Re: Getting RPC error when registering my cohert

You need Boron SR3. The DOMDataTreeCommitCohortRegistry wasn't advertised prior 
to that.

On Sun, Apr 2, 2017 at 8:01 AM, Satish Dutt 
<sd...@advaoptical.com<mailto:sd...@advaoptical.com>> wrote:
Hi Thomas,

I have taken the example code provided in the CarProvider for registering my 
cohert in my provider class. But whenever I am trying to register my  cohert, I 
am always getting the ” RPC error DOMDataTreeCommitCohortRegistry not found “ . 
 Below is my code snippet :

@Override
public synchronized Future<RpcResult> registerCommitCohort() {
if (commitCohortReg.get() != null) {
return RpcResultBuilder.success().buildFuture();
}

final DOMDataTreeCommitCohortRegistry commitCohortRegistry = 
(DOMDataTreeCommitCohortRegistry)

domDataBroker.getSupportedExtensions().get(DOMDataTreeCommitCohortRegistry.class);

if (commitCohortRegistry == null) {
// Shouldn't happen
return RpcResultBuilder.failed().withError(ErrorType.APPLICATION,
"DOMDataTreeCommitCohortRegistry not found").buildFuture();
}

…
…
}

I am using the mdsal-dom-api-2.1.0-Boron.jar . Is the issue related to the 
older jar version being used ?

Regards
-Satish



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

[controller-dev] Getting RPC error when registering my cohert

[Satish Dutt]

Hi Thomas,

I have taken the example code provided in the CarProvider for registering my 
cohert in my provider class. But whenever I am trying to register my  cohert, I 
am always getting the " RPC error DOMDataTreeCommitCohortRegistry not found " . 
 Below is my code snippet :

@Override
public synchronized Future registerCommitCohort() {
if (commitCohortReg.get() != null) {
return RpcResultBuilder.success().buildFuture();
}

final DOMDataTreeCommitCohortRegistry commitCohortRegistry = 
(DOMDataTreeCommitCohortRegistry)

domDataBroker.getSupportedExtensions().get(DOMDataTreeCommitCohortRegistry.class);

if (commitCohortRegistry == null) {
// Shouldn't happen
return RpcResultBuilder.failed().withError(ErrorType.APPLICATION,
"DOMDataTreeCommitCohortRegistry not found").buildFuture();
}

...
...
}

I am using the mdsal-dom-api-2.1.0-Boron.jar . Is the issue related to the 
older jar version being used ?

Regards
-Satish


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

Re: [controller-dev] [netconf-dev] Validation hooks when using restconf

[Satish Dutt]

Thanks Tomas

From: Tomas Cere -X (tcere - PANTHEON TECHNOLOGIES at Cisco) 
[mailto:tc...@cisco.com]
Sent: Monday, March 20, 2017 8:58 PM
To: Satish Dutt <sd...@advaoptical.com>; controller-dev@lists.opendaylight.org; 
controller-us...@lists.opendaylight.org; netconf-...@lists.opendaylight.org
Subject: RE: [netconf-dev] Validation hooks when using restconf

This should be possible by leveraging the DOMDataTreeCommitCohort api's.

https://github.com/opendaylight/mdsal/blob/454903c516e9405ff4a1af6392a31b00c04852fa/dom/mdsal-dom-api/src/main/java/org/opendaylight/mdsal/dom/api/DOMDataTreeCommitCohort.java

https://github.com/opendaylight/mdsal/blob/596b89ec503f56c87d066c00d6550e675eb7cf0c/dom/mdsal-dom-api/src/main/java/org/opendaylight/mdsal/dom/api/DOMDataTreeCommitCohortRegistry.java

Tomas

From: 
netconf-dev-boun...@lists.opendaylight.org<mailto:netconf-dev-boun...@lists.opendaylight.org>
 [mailto:netconf-dev-boun...@lists.opendaylight.org] On Behalf Of Satish Dutt
Sent: Sunday, March 19, 2017 16:07
To: 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>;
 
controller-us...@lists.opendaylight.org<mailto:controller-us...@lists.opendaylight.org>;
 netconf-...@lists.opendaylight.org<mailto:netconf-...@lists.opendaylight.org>
Subject: [netconf-dev] Validation hooks when using restconf

Hi,

>From the northbound applications we are using the restconf APIs to push the 
>JSON data to the ODL controller. Is there any programming hooks through which 
>the JSON data can be validated in the controller before allowing the data to 
>be stored in the configuration datastore ?

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

Re: [controller-dev] Getting exception when using Transaction Chain

[Satish Dutt]

Yes Tom, we are accessing a chain concurrently. Is there any waiting mechanism 
provided by the transaction chain such that the transaction chain waits for 
allocating a new one till the previous write transaction is submitted ?

Regards
-Satish

From: Tom Pantelis [mailto:tompante...@gmail.com]
Sent: Tuesday, March 07, 2017 2:38 AM
To: Satish Dutt <sd...@advaoptical.com>
Cc: Robert Varga <n...@hq.sk>; controller-us...@lists.opendaylight.org; 
controller-dev@lists.opendaylight.org
Subject: Re: [controller-dev] Getting exception when using Transaction Chain

It seems you're trying to access a chain concurrently? If so, this is not 
supported. You must coordinate access to the chain such that the previous write 
transaction is submitted before you allocate a new one.

Tom

On Mon, Mar 6, 2017 at 7:05 AM, Satish Dutt 
<sd...@advaoptical.com<mailto:sd...@advaoptical.com>> wrote:
Thanks Robert for the clarification. So to solve the issue, can I handle this 
IllegalStateException and retry the read or write operations for a finite 
number of times, which makes the best effort of previous write-capable 
transactions to get completed. Or is there a more elegant way of solving this 
issue ?

Regards
-Satish

-Original Message-
From: Robert Varga [mailto:n...@hq.sk<mailto:n...@hq.sk>]
Sent: Monday, March 06, 2017 5:23 PM
To: Satish Dutt <sd...@advaoptical.com<mailto:sd...@advaoptical.com>>; 
controller-us...@lists.opendaylight.org<mailto:controller-us...@lists.opendaylight.org>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>
Subject: Re: [controller-dev] Getting exception when using Transaction Chain

On 03/06/2017 12:39 PM, Satish Dutt wrote:
> When multiple requests are sent concurrently, IllegalStateException is
> thrown. Is there any way to solve this issue, apart from synchronizing
> the method which does the above operations ?

This is actually part of the API contract:

https://github.com/opendaylight/controller/blob/a81d98f692b80c45bce3fe6a87e731abfb012a9f/opendaylight/md-sal/sal-common-api/src/main/java/org/opendaylight/controller/md/sal/common/api/data/TransactionChain.java#L59

The reason is very simple: if there is a write-capable transaction open and it 
has seen some modifications, does the second transaction observe those 
modifications as applied or as unapplied?

Bye,
Robert
___
controller-dev mailing list
controller-dev@lists.opendaylight.org<mailto: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

Re: [controller-dev] Getting exception when using Transaction Chain

[Satish Dutt]

Thanks Robert for the clarification. So to solve the issue, can I handle this 
IllegalStateException and retry the read or write operations for a finite 
number of times, which makes the best effort of previous write-capable 
transactions to get completed. Or is there a more elegant way of solving this 
issue ?

Regards
-Satish

-Original Message-
From: Robert Varga [mailto:n...@hq.sk] 
Sent: Monday, March 06, 2017 5:23 PM
To: Satish Dutt <sd...@advaoptical.com>; 
controller-us...@lists.opendaylight.org; controller-dev@lists.opendaylight.org
Subject: Re: [controller-dev] Getting exception when using Transaction Chain

On 03/06/2017 12:39 PM, Satish Dutt wrote:
> When multiple requests are sent concurrently, IllegalStateException is 
> thrown. Is there any way to solve this issue, apart from synchronizing 
> the method which does the above operations ?

This is actually part of the API contract:

https://github.com/opendaylight/controller/blob/a81d98f692b80c45bce3fe6a87e731abfb012a9f/opendaylight/md-sal/sal-common-api/src/main/java/org/opendaylight/controller/md/sal/common/api/data/TransactionChain.java#L59

The reason is very simple: if there is a write-capable transaction open and it 
has seen some modifications, does the second transaction observe those 
modifications as applied or as unapplied?

Bye,
Robert

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

[controller-dev] Getting exception when using Transaction Chain

[Satish Dutt]

Hi,

In a method we are creating a new instance of ReadOnlyTransaction and 
WriteTransaction from the transaction chain and subsequently doing the read and 
write operations on the datastore. When multiple requests are sent 
concurrently, IllegalStateException is thrown. Is there any way to solve this 
issue, apart from synchronizing the method which does the above operations ?

Method pseudocode :

doSomeTask(BindingTransactionChain txnChain) {
1) final WriteTransaction writeTxn = 
txnChain.newWriteOnlyTransaction();
2) final ReadOnlyTransaction readTxn = 
txnChain.newReadOnlyTransaction();
3) Read the data and close the transaction readTxn.close()
4) Write the data.
}


Exception trace :

java.lang.IllegalStateException: Previous transaction 
member-1-datastore-operational-fe-0-chn-3-txn-1018 is not ready yet
at 
org.opendaylight.controller.cluster.datastore.TransactionChainProxy$Allocated.checkReady(TransactionChainProxy.java:85)
at 
org.opendaylight.controller.cluster.datastore.TransactionChainProxy.allocateWriteTransaction(TransactionChainProxy.java:190)
at 
org.opendaylight.controller.cluster.datastore.TransactionChainProxy.newWriteOnlyTransaction(TransactionChainProxy.java:171)
at 
org.opendaylight.controller.cluster.databroker.DOMBrokerWriteOnlyTransaction.createTransaction(DOMBrokerWriteOnlyTransaction.java:32)
at 
org.opendaylight.controller.cluster.databroker.DOMBrokerWriteOnlyTransaction.createTransaction(DOMBrokerWriteOnlyTransaction.java:16)
at 
org.opendaylight.controller.cluster.databroker.AbstractDOMBrokerTransaction.getSubtransaction(AbstractDOMBrokerTransaction.java:57)
at 
org.opendaylight.controller.cluster.databroker.AbstractDOMBrokerWriteTransaction.merge(AbstractDOMBrokerWriteTransaction.java:97)
at 
org.opendaylight.controller.md.sal.binding.impl.BindingDOMWriteTransactionAdapter.ensureParentsByMerge(BindingDOMWriteTransactionAdapter.java:67)
at 
org.opendaylight.controller.md.sal.binding.impl.AbstractWriteTransaction.merge(AbstractWriteTransaction.java:55)
at 
com.adva.ensemble.controller.controllerconfiguration.util.NetworkAssignmentHelper.updateManagementIpAddress(NetworkAssignmentHelper.java:234)
at 
com.adva.ensemble.controller.controllerconfiguration.util.NetworkResourcePool.offerMgmtIp(NetworkResourcePool.java:79)
at 
com.adva.ensemble.controller.controllerconfiguration.util.ControllerConfigurationUtil.setMgmtIp(ControllerConfigurationUtil.java:936)
at 
com.adva.ensemble.controller.controllerconfiguration.util.ControllerConfigurationUtil.setManagementIp(ControllerConfigurationUtil.java:1343)
at 
com.adva.ensemble.controller.controllerconfiguration.util.ControllerConfigurationUtil.processCreateOrUpdate(ControllerConfigurationUtil.java:798)
at 
com.adva.ensemble.controller.controllerconfiguration.impl.ConnectorConfigRpcServiceImpl.createConnectorConfig(ConnectorConfigRpcServiceImpl.java:177)
at 
org.opendaylight.yangtools.yang.binding.util.RpcMethodInvokerWithInput.invokeOn(RpcMethodInvokerWithInput.java:30)
at 
org.opendaylight.yangtools.yang.binding.util.AbstractMappedRpcInvoker.invokeRpc(AbstractMappedRpcInvoker.java:52)
at 
org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invoke(BindingDOMRpcImplementationAdapter.java:85)
at 
org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invokeRpc(BindingDOMRpcImplementationAdapter.java:72)
at 
org.opendaylight.controller.md.sal.dom.broker.impl.GlobalDOMRpcRoutingTableEntry.invokeRpc(GlobalDOMRpcRoutingTableEntry.java:39)
at 
org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRoutingTable.invokeRpc(DOMRpcRoutingTable.java:186)
at 
org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRouter.invokeRpc(DOMRpcRouter.java:131)
at Proxycf92d5e4_0a26_40ab_b779_fd8b6d8a16b2.invokeRpc(Unknown Source)
at 
org.opendaylight.netconf.sal.restconf.impl.BrokerFacade.invokeRpc(BrokerFacade.java:350)[274:org.opendaylight.netconf.sal-rest-connector:1.4.0.Boron]
at 
org.opendaylight.netconf.sal.restconf.impl.RestconfImpl.invokeRpc(RestconfImpl.java:443)[274:org.opendaylight.netconf.sal-rest-connector:1.4.0.Boron]
at 
org.opendaylight.netconf.sal.restconf.impl.StatisticsRestconfServiceWrapper.invokeRpc(StatisticsRestconfServiceWrapper.java:82)[274:org.opendaylight.netconf.sal-rest-connector:1.4.0.Boron]
at 
org.opendaylight.netconf.sal.rest.impl.RestconfCompositeWrapper.invokeRpc(RestconfCompositeWrapper.java:64)[274:org.opendaylight.netconf.sal-rest-connector:1.4.0.Boron]
at sun.reflect.GeneratedMethodAccessor63.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.8.0_102]
at java.lang.reflect.Method.invoke(Method.java:498)[:1.8.0_102]
at 

Re: [controller-dev] Shard leader down scenario

[Satish Dutt]

Hi Tom,

Please correct me if am wrong in understanding the below statement.

The CheckedFuture will produce a derived TransactionCommitFailedException 
indicating there's no leader or it timed out. You have to wait for the 
CheckedFuture to be completed one way or another.  It may take some number of 
seconds for it to time out (there are retries to wait for a new shard leader) 
so it's best not to block on the future.

 : If we introduce a wait mechanism for the CheckedFuture to be 
completed, how will this be different than using the 
CheckedFuture.checkedGet(). In either of these cases the caller (main) thread 
gets blocked. So are any other ways for the main thread to wait for the 
CheckedFuture to get completed ?

Regards,
-Satish

From: Tom Pantelis [mailto:tompante...@gmail.com]
Sent: Thursday, February 23, 2017 12:27 AM
To: Satish Dutt <sd...@advaoptical.com>
Cc: controller-dev@lists.opendaylight.org
Subject: Re: [controller-dev] Shard leader down scenario



On Wed, Feb 22, 2017 at 1:36 PM, Satish Dutt 
<sd...@advaoptical.com<mailto:sd...@advaoptical.com>> wrote:
Hi All,

We have a 3-node clustered deployment.

Code extract :

WriteTransaction writeTxn = dataBroker.newWriteOnlyTransaction();
writeTxn.put()
CheckedFuture<> checkedFuture = writeTxn.submit()


Scenario :

1) Three nodes in the setup N1, N2, N3
2) N3 is the shard leader.
3) All RPC requests from the NBI are sent to N2.
4)  First two requests are successful.
5)  Before the third request, N3 goes down and there is NO SHARD LEADER
6)  Third RPC request is sent to N2


Now will the checkedFuture value be null or error since there is no 
shard-leader ? Are there any ways to know the shard-leader is down without 
blocking on the checkedFuture  and send an error in the RPC response to the NBI 
user  ?


The CheckedFuture will produce a derived TransactionCommitFailedException 
indicating there's no leader or it timed out. You have to wait for the 
CheckedFuture to be completed one way or another.  It may take some number of 
seconds for it to time out (there are retries to wait for a new shard leader) 
so it's best not to block on the future.

We are basically hitting this issue while scaling the requests.

Regards
-Satish

___
controller-dev mailing list
controller-dev@lists.opendaylight.org<mailto: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] How to set the execute permission for a shell script

[Satish Dutt]

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