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

[Luka Perkov]

+ Kristian since I don't think he is subscribed.

Luka

On Fri, Oct 7, 2016 at 4:52 PM, Rastislav Szabo -X (raszabo - PANTHEON
TECHNOLOGIES at Cisco) <raszabo at cisco.com> wrote:

> 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 J
>
>
>
> 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>
> .[image: Image removed by sender.]
>
> _______________________________________________
> sysrepo-devel mailing list
> sysrepo-devel at sysrepo.org
> http://lists.sysrepo.org/listinfo/sysrepo-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sysrepo.org/archives/sysrepo-devel/attachments/20161007/84cf55b5/attachment.html>