On Sep 30, 2014:1:55 PM, at 1:55 PM, Jeffrey Haas <[email protected]> wrote:
> 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. That makes sense. --Tom > > > >> >>> >>> 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 >>> >> > > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
