On Thu, Sep 25, 2014 at 7:39 AM, Martin Bjorklund <[email protected]> wrote:
> Jeffrey Haas <[email protected]> wrote: > > On Thu, Sep 25, 2014 at 12:29:35PM +0200, Martin Bjorklund wrote: > > > Jeffrey Haas <[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. > > > > > > My interpretation of the interim discussion is that the deletion > > > carries through. > > > > To be clear what I meant, consider: > > > > local config: ephemeral: > > A A/B - B is introduced as an augmentation of A > > I think there might be a terminology confusion here, so let's do a > simple example. > > list foo { > key id; > leaf id { type int32; } > leaf a { type int32; } > } > > local config: > > foo 42 > > In ephemeral config we now do SET /foo[id=42]/a to 4711. Thus, in > ephemeral we now have a single node (a) with value 4711. > > What happens if we in local config delete foo 42? > > If /foo[id=42]/a is NOT deleted from the ephemeral config, what is now > presented to the internal apps? > Yes -- and what is presented to a client that retrieves the ephemeral config in a GET request? IMO, coupling the datastores does not make sense. Your example is 1 reason I prefer the "shadow shapshot" approach. I think the local config and client that added the "foo" entry in the ephemeral datastore are meant to have different priorities. The entries are not coupled. One wins and the other loses (main use-case is that ephemeral wins). Editing "foo 42" in the local config just changes what will be installed as local config when the device restarts (or the ephemeral state is removed). It should not change the injected I2RS state at all. IMO it is really important that edits stay within a single datastore. > > /martin > Andy
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
