Operating System: Mac OS
Platform: PC

Schema for data you are trying to write is not loaded at time you are writing it.

On recovery we try to read from the disk and apply the modification that we have recorded to the state which is in InMemoryDataStore. We start recovery only after the first SchemaContext update is received. It looks like if the schema context with the appropriate schema is not present when we are recovering this failure can occur. How do we get around this?

Naive approach (not knowing what is in datastore):

You need to store also list of YANG modules (namespaces) from schema context when snapshot was stored to disk and you could do full recovery (using inmemory data store) only when schema context contains all modules.

More advanced approach is to know all used namespaces (stored data) and do recovery after all modules are present, but this requires bit more logic on
writeout path and needs to store all used namespaces (even ones used in identities and instance identifiers stored in leaves).

For persistence/recovery we are using akka-persistence. If we had to store schema related info using akka-persistence then we would need to recover first to get to the schema, which would also recover the data.

To recover conditionally based on the presence of all required schema elements would therefore require us to go outside the bounds of akka-persistence.

One possible solution I can think of is if schemaContext itself was serializable. If so that could be one proper alternative that we could use for recovery. Essentially it would work like this, when we receive a schemaContext during a normal run we would persist it to disk (using akka-persistence). On recovery we would load the schemaContext from disk and apply it to the in-memory store and then subsequently load the data. This seems like the most straightforward approach (if schemaContext was serializable that is)

Let's say I had some data in the datastore for some module and later on I set a schema context on the datastore which did not contain a definition for that module. What would happen? Would it not be possible to retrieve that data from the datastore?

I think the way SchemaContext works is problematic. At my previous company, we had a similar issue with failures caused by data model schemas not being present yet on restart so I preloaded all data model schemas from all bundles on restart by having a component that started first and scraped the schema-related files from all RESOLVED bundles. I think, longer term, we should do a similar thing with the SchemaContext so we don't have to keep putting in hacks like this.

Tom, I agree in principle with your point - but for Helium we do need to hack this.

Yeah I know - this should be investigated post-Helium.

GlobalBundleScanningSchemaServiceImpl is one which exactly does that - gets schema sources from all resolved bundles.

If I understand you correctly, what you are proposing is having component,
which behaves as GlobalBundleScanningSchemaServiceImpl, but also caches schemas, so on subsequent restart (if nothing changed) it has all schemas
ready at start?

Actually this "hack" what I am proposing is also correct one, image some model bundles were unistalled, so still comparing schema context capabilities is still required (basicly because of restart and reinstall capabilities of your system changed).

So yes, we need better heuristics how to recover datastore in various scenarios, which should be part of Lithium and also maybe Helium Service Release.

Moiz's hack should work fine for now except if a module bundle is removed from the installation. On restart, the persisted modules set would contain a stale module and the modules in the new SchemaContext wouldn't "containAll" persisted modules so we wouldn't start the shards. But that would be uncommon so maybe we can live with it for now.

It looks like it's the ModuleInfoBundleTracker that backs the SchemaContext. Currently it tracks ACTIVE bundles. I think if we changed it to track RESOLVED bundles, like GlobalBundleScanningSchemaServiceImpl does, it might fix this problem w/o having to do the hack. I wouldn't think there would be any adverse ramifications to this.

What do you guys think?

(In reply to Tony Tkacik from comment #9)
> GlobalBundleScanningSchemaServiceImpl is one which exactly does that - gets
> schema sources from all resolved bundles.
>
> If I understand you correctly, what you are proposing is having component,
> which behaves as GlobalBundleScanningSchemaServiceImpl, but also caches
> schemas, so on subsequent restart (if nothing changed) it has all schemas
> ready at start?
>
> Actually this "hack" what I am proposing is also correct one, image some
> model bundles were unistalled, so still comparing schema context
> capabilities is still required (basicly because of restart and reinstall
> capabilities of your system changed).
>
> So yes, we need better heuristics how to recover datastore in various
> scenarios, which should be part of Lithium and also maybe Helium Service
> Release.

Tom, I'm not sure what would be the impact of that change - I wouldn't want to introduce it in Helium.

From observation it does NOT seem that on startup schemaContext gets injected more than once most of the times. At exit however I see it being injected several times - I haven't investigated why yet.

The config system starts modules async so many if not all bundles will have transitioned to ACTIVE at that point. But, of course, it depends on timing and is unpredictable. On shutdown, as module bundles are stopped, I believed they're removed from the SchemaContext - that would explain why you see updates. If so, that shouldn't screw up your changes because newModules wouldn't "containAll" knownModules so we wouldn't update the persistence.

I understand your reservations about changing the module schema loading at this point. But it seems like it would be a benign change - I'd be interested in Tony's opinion. We can always change it post-Helium when there's more time to let it bake. Removing your "hack" should be simple.

(In reply to Moiz Raja from comment #11)
> Tom, I'm not sure what would be the impact of that change - I wouldn't want
> to introduce it in Helium.
>
> From observation it does NOT seem that on startup schemaContext gets
> injected more than once most of the times. At exit however I see it being
> injected several times - I haven't investigated why yet.

https://git.opendaylight.org/gerrit/#/c/11346/