[sysrepo-devel] FW: [sysrepo/sysrepo] Edit config without subscriptions fails (#387)

[Rastislav Szabo -X (raszabo - PANTHEON TECHNOLOGIES at Cisco)]

Hi,

I’d rather move this discussion to the sysrepo-devel mailing list, since not all people from the sysrepo ecosystem follow the issues on GitHub.

I think that the main difference between sysrepo and the other systems controlled via NETCONF is that sysrepo is focused on individual Linux applications instead of a whole system.

When a typical router controlled via NETCONF boots, it always starts all its processes during the boot process, which basically means that all the configuration in the running datastore is applicable and valid.

In sysrepo world we can have applications that do not start on system boot. Having their config in running datastore could be misleading if the controlled application is actually not running. Even more, if you changed something in running DS and then start the application, it would overwrite the changes in running, since when the application starts, it is supposed to read startup configuration and copy the startup content to running.

>> From a provisioning perspective I think it's confusing because we always work with the running datastore

If the sysrepo-based system consisted only out of applications/daemons that start automatically on system boot, you would not experience any difference – all the config will be always enabled in running.

We led many discussions on this topic before we decided to design sysrepo this way, so if others have something to add, please do it ☺

Thanks,
Rastislav

From: Kristian Larsson [mailto:notifications at github.com]
Sent: Friday, October 7, 2016 12:43 PM
To: sysrepo/sysrepo <sysrepo at noreply.github.com>
Cc: Rastislav Szabo -X (raszabo - PANTHEON TECHNOLOGIES at Cisco) <raszabo at cisco.com>; Comment <comment at noreply.github.com>
Subject: Re: [sysrepo/sysrepo] Edit config without subscriptions fails (#387)


To me this sounds a bit like replicating the ideas of opstate (current discussion in IETF/NETMOD) but you've used running and startup to differentiate between applied and intended.

The whole point of opstate is to be able to query independently whether something is actually applied and not just part of the intended configuration. Even with the daemon running (thus you've copied startup -> running) there's no guarantee it's actually "running" just yet since it likely takes some time to apply the config.

From a provisioning perspective I think it's confusing because we always work with the running datastore (most of the time we trust the box to copy running -> startup when doing NETCONF commit which means we never even deal with the startup config). I think the approach you've taken differs from what pretty much all other implementations do, right?

I'm not convinced this is the proper way to do it, nor am I convinced it should change. Need to think more about it ;)

If we just flip it around, what is improved by the current behaviour? If sysrepo were to support opstate (whichever solution is picked in IETF) what benefits would the current behaviour bring?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://github.com/sysrepo/sysrepo/issues/387#issuecomment-252212534>, or mute the thread<https://github.com/notifications/unsubscribe-auth/APMGxOGW1b6tQhS6-N7bnQrwaKhI37IKks5qxiIegaJpZM4KQJXD>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sysrepo.org/archives/sysrepo-devel/attachments/20161007/ca4a2951/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 332 bytes
Desc: image002.jpg
URL: <http://lists.sysrepo.org/archives/sysrepo-devel/attachments/20161007/ca4a2951/attachment.jpg>