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