[netmod] 答复: system configuration sync mechanism

["Fengchong (frank)" <[e-mail]>]

Hi andy and all.

I don’t think get-data with origin can solve the issues below:


1.       Some leafs like interface type CAN NOT be modified by user, but can be referenced by other config nodes(e.g. using leafref or occur in when/must). The validation will be fail if these leafs are not be configured by user now explicitly (we assume these leafs are optional and no default value).

2.       Some instances are generated by system, but these instances can be referenced by other config nodes. The validation must be fail if these instances are not be recreated by user explicitly now.

3.       User may need know what the original system configuration is, if we get data from <operational>, you may get the modified system configuration.(for example, user modify or template is expanded, or only active instances)

I don’t care about whether system datastore is imported to running or intended datastores. But I think if a config node reference a system node, the validation (running or intended datastores) will be successful even if the system node is not configured by user explicitly.

Especially on the client side,  if a client need validate all data retrieved from server, the validation SHOULD be successful. If system configuration are not imported to running, at a minimum, the client needs to know what the original system configuration is. Another way is adding with-system-used parameter to get-config operation to retrieved all user configuration and system configuration referenced by user configuration.

发件人: netmod [mailto:[e-mail]] 代表 Andy Bierman
发送时间: 2021年8月3日 6:50
收件人: Kent Watsen <[e-mail]>
抄送: Balázs Lengyel <balazs.lengyel=[e-mail]>; [e-mail]
主题: Re: [netmod] system configuration sync mechanism



On Mon, Aug 2, 2021 at 3:31 PM Kent Watsen <[e-mail]<mailto:[e-mail]>> wrote:

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.
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.


I prefer neither.
I think NMDA <get-data> with an origin-filter and/or with-origin parameter already solves this problem.


Andy


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.