[CONTROLLER-1245] Clustering : Make blocking datastore startup on the basis of valid SchemaContext smarter

Sat, 13 Jun 2015 00:24:24 +0000

If you try to add some data into InMemoryDataStore it must match the schema of that the InMemoryDataStore is aware of. If it does not then an exception may be thrown by IMDS. To ensure that we do not get into this situation on startup ShardManager waits to receive a schemaContext that is a superset of it's last known schemaContext and only when it receives such a schemaContext does it proceed with the creation of Shards.

This poses a couple of problems,

a. What if we never get a schema context which is a superset of the last known data. In this situation we will not load the Shards and we will have failures down the road.
b. If a yang module was removed and we tried to restart the controller then that module will be missing in the schemaContext and so ShardManager will never create the Shards.

There are two potential fixes for this problem,

a. IMDS allows us to store data without checking the schemaContext. If a method was provided on IMDS to turn of this checking that would do the trick.
b. Store the SchemaContext into the persistent journal everytime a SchemaContext update is received. On recovery set the IMDS schemaContext based on what we read from the journal.

While (b) seems like the right thing to do there are a couple of problems with doing it,

a. SchemaContext is not Serializable/Externalizable and it seems like it will take significant effort to make it so.
b. During a normal controller run schemaContext gets update numerous times and also when it is being shutdown. I am afraid that this will add significant overhead to the datastore.

OpenDaylight JIRA

[CONTROLLER-1245] Clustering : Make blocking datastore startup on the basis of valid SchemaContext smarter