Re: [netmod] system configuration sync mechanism

[Andy Bierman <[e-mail]>]

On Wed, Aug 4, 2021 at 5:34 AM Kent Watsen <[e-mail]> wrote:

>
> I am confused by the confusion  ;)
>
> You all know that JUNOS implemented this concept before YANG was even a
> thing, right?
>
> Admittedly, it’s not a “datastore“, but flexing the NMDA is where we can
> do better.
>
> A “with-system” mechanism could also work.  The only downside is the
> inability for a client to get only the system configuration, without the
> rest of <running>.
>
> Please stop stating/suggesting “config true” nodes are referencing “config
> false” nodes,  or that config is referencing operational state.  There is
> no intention to break either of these tenants here.
>
> I think that some folks just joined the conversation and may have missed
> out when we covered all this before.
>
> The draft needs to be updated to more clearly identify the goals.



I strongly agree the draft could better explain the problem and the value
of the solution, especially how
this datastore is used to represent system values that are not in use.
Since NMDA already
provides a solution to retrieve the "system-only" nodes that are in use,
there is no value in that part
of the system datastore at all.

Also some pointers to implementations of this system datastore would be
helpful.

I am confused because there was an assertion made that this system
datastore was needed
so that the nodes could be referenced in config XPath.  This is not
correct.  The solution that Balazs
outlined is quite common and much better and less disruptive than adding a
new datastore.
It is trivial to identify the user-write operations that are allowed (e.g.
modify but not create, delete,
or rename a physical interface).


>
> K.
>
>
Andy