On Fri, Sep 26, 2014 at 8:30 AM, Susan Hares <[email protected]> wrote:
> Alexander:
>
>
>
> To help me understand your proposal, let us move to the previous example:
>
>
>
> Previous example:
>
>
>
> list foo {
> key id;
> leaf id { type int32; }
> leaf a { type int32; }
> }
>
> local config:
>
> foo 42
>
>
>
So in this "foo 42" step, you are assuming that the NETCONF or RESTCONF
client
told the NETCONF or RESTCONF server that the edit to the local config is
supposed
to be copied to the ephemeral datastore? So modifications to those
protocols
to edit multiple datastores at once will be needed? (Your Q (a) below)
So we are assuming the 2 datastores are in sync so concurrent edits are
feasible?
> 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.
>
>
>
You have this only if the previous step copied "foo 42".
You cannot create a child node unless the parent exists or is also getting
created.
If you delete a node, the entire subtree (the XPath descendant-or-self
axis) is deleted.
I hope the various plans to couple the running and ephemeral datastores do
not
try to violate these rules.
Andy
Your model:
>
> a) The value 4711 - would be a "non-golden" copy.
>
> b) It would not be written through to the the "golden copy".
>
>
>
> Questions:
>
> a) How would you specify a "write-through" copy?
>
> b) Can I2RS decide later it wants to write-through the golden copy? Or
> are variables only "non-write-through" and "write-through"?
>
> c) If we delete foo 42, what happens?
>
>
>
> Thank you,
>
> Sue Hares
>
>
>
Andy
> *From:* i2rs [mailto:[email protected]] *On Behalf Of *Alexander
> Clemm (alex)
> *Sent:* Thursday, September 25, 2014 8:57 PM
> *To:* Andy Bierman; Martin Bjorklund
> *Cc:* Jeffrey Haas; [email protected]; Eric Voit (evoit)
> *Subject:* Re: [i2rs] Two thoughts on an ephemeral data store
>
>
>
> FWIW, I would think the semantics should be kept simple.
>
>
>
> 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.
>
> (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.
>
>
>
> 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.
>
>
>
> --- Alex
>
>
>
> *From:* i2rs [mailto:[email protected] <[email protected]>] *On
> Behalf Of *Andy Bierman
> *Sent:* Thursday, September 25, 2014 8:44 AM
> *To:* Martin Bjorklund
> *Cc:* Jeffrey Haas; [email protected]
> *Subject:* Re: [i2rs] Two thoughts on an ephemeral data store
>
>
>
>
>
>
>
> 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
