Alex, On Fri, Sep 26, 2014 at 12:57:20AM +0000, Alexander Clemm (alex) wrote: > The complexity here comes from the fact that there are dependencies between > different data stores, and some objects that are part of one data store need > to be reflected in a different data store. > > It would seem this can be addressed with two fairly simple principles: > > (a) A datastore needs to have a clear way to reference objects in a > different datastore, really have them incorporated into the same namespace.
This was discussed in my draft for the netmod interim. Right now, that is an issue if we have them in a different datastore and not in the same namespace. The "option 4" is really to have a unified schema across the datastores and thus we no longer have issues for how to do references. > (b) It needs to be clear who owns the "golden copy" of an object. I needs > to be clear which objects are "authoritatively owned" by a datastore vs which > ones are reference. This is the datastore where the object is maintained, > updated, created; this is where conditions and constraints are evaluated, etc. This seems obvious, but there are a few potentially conflicting scenarios. If objects that are always intended to be ephemeral are never going to conflict (but may lie on top of) local config, there is never a conflict. There is simply referential integrity issues if the underlying local config is deleted and ephemeral config remains. If the objects are always disjoint, there is never a conflict. But if you permit an ephemeral object to override a local config one within the schema, we have this issue. Our options would appear to be: - Do not permit such overrides. Design your models so that when it is desired to configure the same underlying operational state from multiple sources, it is through disjoint pieces of the model. An example would be for static routes to have a local-config mechanism and a completely separate ephemeral config model. This is the "easy" option. - Permit such overrides as long as the semantics are "clear". > Where an ephemeral datastore has dependencies on data in another datastore, > it should incorporate these other objects "by reference". The objects that > are authoritatively owned by the ephemeral datastore can refer to those > objects, have them referred to in conditions and constraints, and so on. > (This can also indicate which ephemeral objects are to be removed when an > object in the other datastore they depend on is deleted, etc) > > Changes to the non-ephemeral objects (e.g. the running datastore) have to be > made to the "golden copy", i.e. the owning datastore. One way to do that > involves implementing a "write-through" operation, in which an update to an > ephemeral copy of the object is realized by having the server of the > ephemeral datastore turn around and make a corresponding request at the other > datastore. > > Very simple semantics. I think this is preferrable to have different copies > of the same object in different datastores, requiring "logical anding" (or > other inter-datastore arithmetic) of different copies representing the same > object to figure out what actual value is in effect, etc. > > In the netmod WG, we have today posted a draft for what we refer to as > requirements for a peer mount > (http://www.ietf.org/internet-drafts/draft-voit-netmod-peer-mount-requirements-00.txt), > motivating why a it would be useful to have a capability to "mount" subtrees > from a remote datastore into a local datastore, and the requirements that > such a capability needs to address. While the original use case and > motivation described there are somewhat different, it seems applicable to the > discussion here. I'll have to ready this draft. From the title, the ability to "mount" a subtree was one of the likely use cases in i2rs where augmenting protocol modules was done rather than "copy and paste" sections (or utilizing well refactored groupings) in a separate model. -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
