I am developing an application which takes in some inputs, runs some algorithm and based on the result, a connecttion is established to a Netconf server using Opendaylight. I am following the ODL Netconf User Guide and everything is working well.
The following is one of my yang modules:
module openroadm-config {
namespace "urn:opendaylight:openroadm-config";
prefix "openroadm-config";
import device-cluster { prefix device-cluster; revision-date 2017-01-08; }
import ietf-yang-types { prefix ietf-yang-types; revision-date 2013-07-15; }
import ietf-inet-types { prefix ietf-inet-types; revision-date 2013-07-15; }
import ietf-netconf { prefix ietf-nc; revision-date 2011-06-01; }
import org-openroadm-common-types { prefix org-openroadm-common-types; revision-date 2017-09-29; }
import org-openroadm-resource-types { prefix org-openroadm-resource-types; revision-date 2017-09-29; }
import org-openroadm-physical-types { prefix org-openroadm-physical-types; revision-date 2017-09-29; }
import org-openroadm-user-mgmt { prefix org-openroadm-user-mgmt; revision-date 2017-09-29; }
import org-openroadm-port-types { prefix org-openroadm-port-types; revision-date 2017-09-29; }
import org-openroadm-interfaces { prefix org-openroadm-interfaces; revision-date 2017-06-26; }
import org-openroadm-swdl { prefix org-openroadm-swdl; revision-date 2017-09-29; }
import org-openroadm-equipment-states-types { prefix org-openroadm-equipment-states-types; revision-date 2017-06-26; }
import org-openroadm-device { prefix org-openroadm-device; revision-date 2017-09-29; }
revision 2018-04-12 {
description "Initial revision";
}
grouping openroadm-device-common-details {
uses org-openroadm-device:device-common;
leaf max-degrees {
config false;
type uint16;
description
"Max. number of degrees supported by device";
}
leaf max-srgs {
config false;
type uint16;
description
"Max. number of SRGs in an add/drop group";
}
leaf max-num-bin-15min-historical-pm {
config false;
type uint16;
description
"Max. number of bin the NE support for 15min historical PM";
}
leaf max-num-bin-24hour-historical-pm {
config false;
type uint16;
description
"Max. number of bin the NE support for 24hour historical PM";
}
}
grouping openroadm-list {
list openroadm-device-list {
key node-id;
uses openroadm-device-common-details;
}
}
container openroadm-device-list-container {
uses openroadm-list;
}
container openroadm-data {
uses openroadm-device-common-details;
}
rpc openroadm-set {
input {
uses openroadm-list;
}
output {
uses device-cluster:rpc-response-status;
}
}
rpc openroadm-get {
input {
list openroadm-ids {
key openroadm-device-id;
leaf openroadm-device-id {
description "The openroadm device id";
type string;
}
}
}
output {
uses openroadm-list;
}
}
}
By default, there are 4 shards in opendaylight- default, toaster, inventory and topology, and 2 datastores- operational and configuration. All the topology related information such as Netconf connector credentials are stored in the topology shard (I assume).
My question is, in which shard are the data that is defined in my application stored? Is it possible to control the shard into which my data goes? If yes, how can it be done? Is it related to the namespace defined in my yang file?
Your data is stored in the default shard. The sharding is controlled by yang module namespace - see the configuration/initial/modules.conf and configuration/initial/module-shards.conf files. Any yang module not specifically placed in its own shard gets put into the default shard.