[netmod] Re: 2nd WGLC on system-config-08

[Kent Watsen <[e-mail]>]

> On Aug 22, 2024, at 1:24 PM, Andy Bierman <[e-mail]> wrote:
> On Tue, Aug 20, 2024 at 5:54 AM Jürgen Schönwälder <[e-mail]> wrote:
>> On Tue, Aug 20, 2024 at 12:20:55PM +0000, Jan Lindblad (jlindbla) wrote:
>> > 
>> > PS: And with a well designed merge operation, one might in the future
>> >     even move towards breaking the monolithic <running> into pieces,
>> >     like we do for the <candidate> singleton today.
>> > 
>> > [janl] Could you expand on that last PS? I’m not following your train of thought here.
>> >
>> 
>> If you take the configuration of a web server, then it is common
>> practice to organize the configuration of different sites a server is
>> serving into separate files. (I am talking about modularity of config
>> instance data, not modularity of the underlying data models.) The
>> server then loads the configs of all active sites and merges the
>> settings somehow to derive all the internal settings necessary to
>> provide the configured services.
>> 
> 
> The <system> datastore is not a functional partition, like virtual WEB servers .
> The split between system and client is somewhat arbitrary and quite implementation-specific.
> It does not provide modularity at all.
> 
> <running> as a datastore is conceptually monolithic, but required to be that way in implementation.
> Certainly the protocol operations are not required to operate on the entire config at once.
> 
> I do not see any significant difference between system-created config and
> traditional client-created config.  In modern distributed systems, the system config
> could actually be (at least partially) client config, even using the exact same operations as a "real" client.
> The distinction between system and client-created data is no longer relevant.
> The immutable flag addresses the relevant issues.


I read Jürgen’s text as “if we can generalize the ‘datastore-merge’ operation enough, it could be used as the basis for a really cool templating mechanism”.   That is, <running> might actually be a hierarchy of datastores that are merged to become <running>.

If my reading is correct, it is a really interesting out-of-the-box idea.  It might be overkill for a templating mechanism, given the existence of vendor-specific implementations that work inside a single datastore.  Still, if there is an opportunity to do something revolutionary, that simplifies things in the end, it seems good to consider the option.


Kent // as a contributor