Hi Susan, Andy, all,
there would be two datastore – “local” and “ephemeral”.
Local implements and owns foo, instantiated as you describe below. This
is the golden copy.
Furthermore, for simplicity sake, assume that list foo is contained in a
container, foos.
The ephemeral datastore implements a separate model “foo-ext”.
This model declares a reference / “mount” to “foos” in the local datastore.
In addition, it defines some other data, that is “owned” by the
ephemeral datastore. (This data can have conditions/constraints to data
that has been mounted from foo.)
So, in the ephemeral you might have
foo-ext
+-- M foos --> /local/foos
+-- bar
An application/client that accesses ephemeral can access foo 42 via
/foo-ext/foos/foo 42. The fact that the ephemeral datastore turns
around as needed, as the golden copy is owned by local, is transparent
to the application. If someone changes foo 42, e.g. because they access
the local datastore directly, that will be reflected in the ephemeral
datastore by virtue of the fact that it in effect acts as a “cache” to
the data in the local datastore.
Now, there are a couple of items to consider:
-If you want to have a list where some list elements reside on one
datastore, others in another, you cannot do that directly. What you
need to do in that case is to introduce a partition (as part of the
model that you implement in the ephemeral) that e.g. has a “my-foos”
container containing the list elements it authoritatively owns, and a
separate “cached-foos” container that “contains” the list elements from
the other datastore.
-Should you be able to have a remote data item contain a local one? I
would argue that you should not allow for that, precisely to avoid the
scenario in which the local object get “decapitated” because something
happens to the containing objects that are owned by a different system.
If you want to attach a piece of ephemeral data to the remote data item,
you should do so with other ways than containment, e.g. adding a leafref
to the mounted/referenced remote object.
The distinction to other proposals is that with this proposal, the
ephemeral datastore defines its own separate model (which indicates
which data it “owns”, vs which data it “caches”). Note that the model
for the cached data does not need to be redefined; it is used as-is; the
fact that there is another datastore which decides to incorporate that
information is not something the local datastore needs to be aware of.
Does this answer your questions?
--- Alex
*From:*Susan Hares [mailto:[email protected]]
*Sent:* Friday, September 26, 2014 8:30 AM
*To:* Alexander Clemm (alex); 'Andy Bierman'; 'Martin Bjorklund'
*Cc:* 'Jeffrey Haas'; [email protected]; Eric Voit (evoit)
*Subject:* RE: [i2rs] Two thoughts on an ephemeral data store
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
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.
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
*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] <mailto:[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]] *On Behalf Of *Andy Bierman
*Sent:* Thursday, September 25, 2014 8:44 AM
*To:* Martin Bjorklund
*Cc:* Jeffrey Haas; [email protected] <mailto:[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]
<mailto:[email protected]>> wrote:
Jeffrey Haas <[email protected] <mailto:[email protected]>> wrote:
> On Thu, Sep 25, 2014 at 12:29:35PM +0200, Martin Bjorklund wrote:
> > 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.
> >
> > 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
