> On Aug 22, 2024, at 1:24 PM, Andy Bierman <[email protected]> wrote: > On Tue, Aug 20, 2024 at 5:54 AM Jürgen Schönwälder > <[email protected]> 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
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
