Subject: Re: [Netconf] edit-config to startup configuration datastore

From: Phil Shafer <[email-masked]>
Date: Mon, 18 Apr 2016 13:02:55 -0400

Kent Watsen writes:
>   This is before my time, but I would've thought startup would be editable, given
>   that it is lockable...

The basic use case for distinct-startup was IOS, where the startup is
out in flash.  It can be copied but not edited.

>   From: Netconf <[email-masked]> on behalf of "Rastislav Szabo -X (raszabo - PANTHEON TECHNOLOGIES at Cisco)" <[email-masked]>
>   In sysrepo [1] and Netopeer2 [2] integration project we aim to provide a
>   convenient API for any Linux applications/daemons to become manageable via
>   NETCONF. To do it, (in the most-basic use-case) they would just need to switch
>   (or amend) the part of the code, where they read their configuration e.g. from
>   text config files to the code that would read it from sysrepo datastore. The
>   issue is, that many Linux daemons are designed to read the config only by their
>   startup. We thought that for such applications, the best approach would be to
>   say that they do not support running datastore (their config never appears in
>   running) and the only way to control them is via modification of their startup
>   configuration. Sysrepo datastore of course will provide the API to support
>   changes of the running state of the applications, but it will be more
>   challenging for the integration into legacy Linux daemons. While it is not
>   integrated into some of them, it would be better to have only startup config
>   NETCONF support, than no NETCONF support at all.
>   [1] https://github.com/sysrepo/sysrepo
>   [2] https://github.com/CESNET/Netopeer2

You might want to take a look at how JUNOS handles this.  We're
built on freebsd, not linux, but the basic model holds.  A central
daemon holds all system configuration, and at commit time, writes
each daemon's specific files and HUPs or restarts them as needed.
To the user, it's all completely invisible, integrated under the
covers.

Thanks,
 Phil

---

From: "Rastislav Szabo -X (raszabo - PANTHEON TECHNOLOGIES at Cisco)" <[email-masked]>
Date: Tue, 19 Apr 2016 07:58:12 +0000

Hi,
 
> The basic use case for distinct-startup was IOS, where the startup is out in
> flash.  It can be copied but not edited.

Yes, I understand that use case. However, I think that writeable startup would fit the use case of generic Unix/Linux OS better than pretending that there is a non-editable startup datastore, since on Unix/Linux system an administrator can edit a config file without any immediate effect, which in terms of NETCONF is a partial edit of the startup datastore config. Therefore I think that writeable startup could be considered as an optional feature.

> You might want to take a look at how JUNOS handles this.  We're built on
> freebsd, not linux, but the basic model holds.  A central daemon holds all
> system configuration, and at commit time, writes each daemon's specific files
> and HUPs or restarts them as needed.
> To the user, it's all completely invisible, integrated under the covers.

Thanks for the info. We have also considered sending of a SIGHUP or restarting of the process, but it brings one issue - you need to be the superuser to do that. Sysrepo, however, is designed so that it can work also without the daemon (in so-called library mode) to address no-single-point-of-failure needs. If we implemented it this way, edit-config to startup could be unsuccessful in library mode access to sysrepo in some cases. But yes, without writeable startup, it seems to be the only way of supporting daemons without the ability of changing their state while running.

Thanks,
Rastislav