Tom, On Tue, Sep 30, 2014 at 12:23:10PM -0700, Thomas D. Nadeau wrote: > On Sep 25, 2014:6:19 AM, at 6:19 AM, Joel M. Halpern <[email protected]> > wrote: > > Top posting for ease of reading, but retaining the content for those who > > want context. > > > > As I understand the shadow proposal, there is the regular local config data > > store, and then there is a second data store (shadow) used by I2RS for its > > ephemeral data. That store is never persisted. So far, so good. > > > > Then Andy asked about when they are synchronized, and suggested that they > > would be sychronized only when the shadow datastore is established by teh > > first I2RS modification request (if I understood him correctly). > > > > I don't think that works. Suppose that I2RS has adjusted data items A and > > B, creating and filling the shadow data store. And then someone using CLI > > / normal NetCONF adjusts item C. If an I2RS client goes to read C, or does > > some operation which depends upon the value of C, it has to be working with > > the new value of C, not the value at the time the ephemeral store was > > created. > > It might be useful to define the operational semantics of what the > shadow data store is. In my opinion, its modifying a version of the running > config of the device.
During the interim, the phrase I was using was "active" config. Effectively when both local config and ephemeral config are both functioning without issues, logically: Without ephemeral datastore: Active = Running With ephemeral datastore: Active = Running + Ephemeral. (I.e. patch running < ephemeral) The question about whether we have "pull-up/snapshot" of local config on top of ephemeral or simply "overlay/see-through" is mostly an implementation detail to cover what happens when there's problems. ----- Overlay: Active = patch running < ephemeral Ephemeral crashes: Active = running (should still be in tact) Instead, running goes away Active = patch NULL < ephemeral This may lead you to an invalid config. ----- Snapshot: Active = cp running ephemeral.candidate ; patch ephemeral.candidate < ephemeral; mv ephemeral.candidate ephemeral. Ephemeral crashes: Running config remains. Instead, running goes away: Ephemeral = last state of ephemeral, potentially with future changes laid on top. In other words, in the snapshot implementation, if you lose local config, you have the last in tact state of running copied in ephemeral. You still must track the individual ephemeral-only changes to lay on top of it. > > > > > Yours, > > Joel > > > > On 9/24/14, 11:47 AM, Andy Bierman wrote: > >> > >> > >> On Wed, Sep 24, 2014 at 8:30 AM, Jeffrey Haas <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> In the proposed overlay model, presume that we have ephemeral data > >> from a > >> model that lives within an augmentation to a local config model. In > >> other > >> words, the ephemeral nodes are children of the local config nodes. > >> > >> Presume, per discussion, that the local config lives in the "config" > >> data > >> store and that the ephemeral config - the augmenting nodes above - > >> live in > >> the ephemeral data store. > >> > >> If we delete the container in the local config that the epehemeral > >> config is > >> augmenting, is there any expectation that such a deletion should carry > >> through to the ephemeral config? > >> > >> Per the netmod interim discussion, probably not. It's in a separate > >> datastore. But it does lead to integrity issues since we now have > >> orphaned > >> state. In this particular example, permitting the deletion to carry > >> through > >> to the ephemeral datastore at least provides one additional level of > >> consistency. > >> > >> > >> I think the concept of "shadowing the local config" makes this behavior > >> confusing. > >> If the ephemeral datastore instances remains after the config datastore > >> instances are deleted, how is that really shadowing? > >> > >> IMO, shadowing only occurs when the ephemeral datastore is edited. > >> It is used as a snapshot to reduce the I2RS payload size (shadow patch?. > >> But the data that gets created in the ephemeral datastore is complete and > >> self-contained. The actual data structures are implementation details. > >> Maybe the local config is cloned, maybe it is shadowed. > >> > >> ----- > >> > >> My second thought is would we ever want to provide filtering in the > >> conditional checks (must/when) in the ephemeral datastore based on the > >> underlying source of the data? Since local config would be shadowed > >> into > >> the ephemeral datastore, do we want the ability to match on the > >> source of > >> the node set under evaluation? > >> > >> > >> Each datastore should only validated against itself, or else the > >> XPath implementation would be even more complicated. If the ephemeral > >> datastore > >> is supposed to be fast (I remember 5000 updates a second from the BoF) > >> then running validation tests across multiple datastores constantly will > >> not help. > >> > >> Or do you mean flag a must/when as "do-not-use" in the ephemeral datastore? > >> If that were possible it would help speed up the server. > >> > >> > >> > >> -- Jeff > >> > >> > >> Andy > >> > >> _______________________________________________ > >> i2rs mailing list > >> [email protected] <mailto:[email protected]> > >> https://www.ietf.org/mailman/listinfo/i2rs > >> > >> > >> > >> > >> _______________________________________________ > >> i2rs mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/i2rs > >> > > > > _______________________________________________ > > i2rs mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/i2rs > > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
