[sysrepo-devel] ?==?utf-8?q? A few simple sysrepo questions

[Michal Vaško]

Hi Andrew,

actually, we did not plan to support this datastore but it seems it is exactly your use-case. We did not pay much attention to it as it does not interact with other datastores. So, once the new generation sysrepo is finished with all currently-planned features (at least half a year from now) we probably can implement this.

Regards,
Michal

On Monday, October 22, 2018 23:50 CEST, Andrew Collins <bsderandrew at gmail.com> wrote: 
 
> > I think this is a use-case covered by neither YANG nor sysrepo so I would advise against doing this. If you still want to use sysrepo like this, there is no better way than what you described, I think.
> 
> +cc list this time...
> 
> Thank your for the helpful responses Michal, in reading the NMDA RFC I
> ran across https://tools.ietf.org/html/rfc8342#section-5.2 which seems
> to be similar to what I am looking for, that is an ephemeral data
> store:
> 
>    The model recognizes the need for dynamic configuration datastores
>    that are, by definition, not part of the persistent configuration of
>    a device.  In some contexts, these have been termed "ephemeral
>    datastores", since the information is ephemeral, i.e., lost upon
>    reboot.
> 
>    o  dynamic configuration datastore: A configuration datastore holding
>       configuration obtained dynamically during the operation of a
>       device through interaction with other systems, rather than through
>       one of the conventional configuration datastores.
> 
> Is this part of the upcoming NMDA support in next-gen sysrepo?
> 
> Thanks,
> Andrew
> On Mon, Oct 22, 2018 at 12:59 AM Michal Vaško <mvasko at cesnet.cz> wrote:
> >
> > Hi,
> >
> > On Friday, October 19, 2018 22:09 CEST, Andrew Collins <bsderandrew at gmail.com> wrote:
> >
> > > I'm looking into sysrepo for a new project and I have a few, hopefully
> > > simple, questions.  I've read the docs and the answer wasn't
> > > immediately obvious to me, but if RTFM is the proper answer here, let
> > > me know.
> > >
> > > Anyway, I'm looking into sysrepo as both a configuration store as well
> > > as a form of yang-based-IPC.  That is, not only will it store
> > > configuration coming from an external source, but when two services
> > > wish to communicate, one will do a "sr_set_item" to a data store in
> > > volatile storage (RAM), and another would register a change handler to
> > > respond to and handle the event.
> > >
> > > I realize there exists the yang "rpc" definition, and associated
> > > sysrepo subsystem, but I'm interested in a more persistent
> > > alternative, one which doesn't get stored to filesystem, but is not as
> > > ephemeral as a one time message.  The goal here is to avoid the case
> >
> > > where a service is unavailable/crashed/being restarted, and an
> > > important RPC is sent but not handled.  I'm relatively new to all
> > > these systems so I may be taking the wrong approach here, but I'm
> > > interested if anyone has any ideas here.
> >
> > I think this is a use-case covered by neither YANG nor sysrepo so I would advise against doing this. If you still want to use sysrepo like this, there is no better way than what you described, I think.
> >
> > > Another unrelated question I have is around the efficiency of state
> > > data handling.  In a complex system there may be a variety of state
> > > elements which can be pushed, rather than pulled (mainly items that
> > > rarely change).  That is, for the sake of efficiency, rather than
> > > registering a data provider subscription, simply doing an
> > > "sr_set_item" whenever the state element needs to be changed.  Can
> > > state elements be just "set", or is a data provider always required?
> >
> >
> > No, you must act as a data provider. However, this provider can simply cache the state data and the actual provider can just "push" changes to this cache. Also, this use-case should be directly supported in the new sysrepo generation with NMDA [1].
> >
> > Regards,
> > Michal
> >
> > [1] https://tools.ietf.org/html/rfc8342