Re: [netmod] system configuration sync mechanism

[Kent Watsen <[e-mail]>]

Hi Balazs, Andy, Quifang,

> I agree a new datastore will just add complexity without any value.
> Your solution approach is better, but I think it would require a new YANG version
> to allow config node XPath to reference non-config nodes.

In no case is there a need for a config Xpath to ref non-config.


> Another solution is to model the referenced node as config=true, but setup
> automatic NACM rules so no user editing is allowed. This works well for
> setting up an initial config that gets saved and not changed unless a reset is done.

I don’t like the NACM dependency.


> What if <intended> is what is NV-stored?  When that occurs, the config changes from system to user config.
> Routers have been saving the combined config for decades. IMO the standards
> intentionally avoid discussing the conversion of a datastore to/from NV-storage.

I’m unsure about this point, but a don’t see any dependency on an NV-store needing to use a particular encoding or format.

> As I see it this is the same problem that we discussed in https://github.com/netmod-wg/yang-next/issues/41 <https://github.com/netmod-wg/yang-next/issues/41>.
> 
> I know this is a radical change, but I think using a new YANG extension to create a read-only config=true datatype is a much cleaner solution. One which some companies have already implemented.
> 
> +1
> 
> Actually, separate running and system would be a radical change, not this.
> Cleaner and less disruptive. 

I disagree with the need to resolve issue #41 here, and I disagree a <system> datastore would be a radical change, or even complicated.

That said, something like RFC 6243 (with-defaults) but called “with-system” could work.  That is, the “system" config is like <running> config that is hidden until asked to be revealed. It would be interesting to discuss if “with-defaults" returns all of the system config, or just the parts that are used, assuming we define “used” appropriately.   Presumably system-defined ordered-list entries cannot be ordered by user, or used as before/after pivots.

We could even do both: have a read-only <system> datastore *and* a "with-system" interaction API.  Each complimenting the other.

FWIW, a "with-system <running>” still may not pass validation if, e.g., templates need to be expanded.  Of course, any controller/orchestrator can expand the templates themselves to resolve that concern.  Such a system could also fetch <system> without skipping a beat.

Thought exercise: a controller is managing 1000 endpoints all running the same software version.  Is it better for the controller to get "with-system <running>” 1000 times, or get <system> once and have knowledge for how its merged in?

K.