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.
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
