On 08/31/2016 04:51 PM, Sela, Guy wrote: > Thanks, > Inline > > On 08/31/2016 01:09 PM, Sela, Guy wrote: >> Hi, >> >> I've being reading this document: >> >> https://github.com/opendaylight/mdsal/blob/master/src/site/asciidoc/co >> nceptual-data-tree.adoc >> >> >> >> I have a few questions. >> >> >> >> 1) >> >> Very general question: >> >> Is the Conceptual Data Tree something new that is planned to get into >> ODL, or is it just an explanation of how the Data Stores are currently >> implemented? >> >> If it's new, when is it expected to get in? > > It is an evolution of how individual data stores are integrated into the > system, rather than having each data store expose a DataBroker, the concept > of sharding is integrated and data store implementations contribute shards. > > The timeframe is Boron, with IMDS already integrated and CDS expected to be > integrated in SR1. > > <GS> Just to make sure I understand: > IMDS means In-Memory Data Store, and this is relevant only if there is one > instance of ODL (i.e., no cluster). > CDS means Clustered Data Store, and when running in a cluster, this store > must be used, so state can be shared within the members of the cluster. > ?
Yes, to some extent. IMDS (where S really is starting to mean 'Shard') is still useful to hold data which is purely node-local and transient -- local stats, etc. > Are there any sample projects that use the API of the IMDS? Jan is preparing examples for the summit :) > >> In the end of the document there is a description of >> DOMDataTreeProducer/Listener. Are these alternatives to the current >> DataTreeChangeListener? Or do they solve a different problem domain? > > They are an evolution of TransactionChain and DataTreeChangeListener. > <GS> Will the old ones be deprecated? Or is it an alternative? Right now they are an alternative and if they can really cover all the use cases, then we would be deprecating the old ones. Unfortunately this needs quite a bit of dev-power to analyze all the users. > <GS> > Okay, now I understand that there is a separation between the backend and > frontend here. > I still don't understand why or when data won't be consistent. > Let's say I query YangInstanceIdentifier X from member A in a cluster, at > what circumstances for example would the same query return a different result > if I would execute it on member E? If it's node-local statistics, node-local configuration and similar. There are cases where we do not want to replicate things across nodes, as that incurs prohibitive overhead. BGP would be one example -- it is much simpler and performant to have peering from each node and not replicate the data using CDS -- that invariably means that such data is not point-in-time consistent, but in some use cases it does not matter. Bye, Robert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev