On Thu, Nov 7, 2024 at 6:50 AM Jason Sterne (Nokia) <jason.sterne= [email protected]> wrote:
> IMO the <system> DS was more about explicitly showing list entries that > the system has populated under the hood, that can be referenced by the > <running>. It came about because many implementations today support > leafrefs in running to those list entries (even though they aren’t in > running). Built-in qos policies. Built-in system interface. That sort of > thing. > > > > In my example, the leaf “foo” only exists in any DS (running and > operational) once the user explicitly configures it. But it just so happens > that the underlying implementation can’t exactly program 1500 into the > datapath, and needs to adjust it for various reasons so the value 1492 is > actually in use. So that gets reflected in the <operational> DS. > > > > But I think it would be odd for that leaf to suddenly appear in the system > DS. It wouldn’t be in there if the user/client didn’t explicitly configure > that leaf in <running> (e.g. with the value 1500). > > > There are several yang-next issues related to this topic. Most recently #147 - https://github.com/netmod-wg/yang-next/issues/147 There are many types of system resources that cannot be represented in <system> until the dynamic default leaf is actually needed. Current conditions (e.g. temperature) combined with the other client values provided, determine the dynamic default. There are many implementation details that cannot be represented in <system>. e.g. multiple YANG lists share N system resources. There can be N total, not N of each, and not N/M each, etc. -- the internal resource does not have an associated YANG list. These dynamic defaults will continue to come from the system, not <system>. Jason > > > Andy > > > > > *From:* Kent Watsen <[email protected]> > *Sent:* Thursday, November 7, 2024 9:33 AM > *To:* Jason Sterne (Nokia) <[email protected]> > *Cc:* Jürgen Schönwälder <[email protected]>; > [email protected] > *Subject:* Re: [netmod] origin "system" in system-config-09 > > > > > > *CAUTION:* This is an external email. Please be very careful when > clicking links or opening attachments. See the URL nok.it/ext for > additional information. > > > > Hi Jason and Juergen, > > > > This email responds to both of your messages, i.e., keep scrolling! ;) > > > > Kent // contributor > > > > > > On Nov 7, 2024, at 1:35 PM, Jason Sterne (Nokia) < > [email protected]> wrote: > > > > Hi Kent, > > My thinking was along the lines of what Jurgen mentions here: there are > some values in operational that come from the system, but don't come from > the system DS. > > > > Before a server implements ietf-system, *all* such values fall into that > category, right? Now assume in the next release the server implements > ietf-system, which just indicates what values are/were selected before. > Nothing else (e.g., internal code) changes. Did the value suddenly come > from the <system> datastore, or is it more that the <system> datastore > accurately modeled the system’s behavior? I think that it is that latter, > but read on... > > > > > > I don't think the intention was that *anything* marked with origin > "system" is also sitting there in the system DS. > > > > That would entail the data-tree in <system> being perfectly complete and > accurate, which is ideal but highly unlikely. FWIW, I view this point as > supporting my perspective of not trying to over engineer this. > > > > > > My example of node "foo" having different values was between <running> and > <operational> (nothing to do with system DS). In the current specs > (without the new DS draft), do you agree the origin of foo would be > "or:system"? > > > > Yes. > > > > > > I'm simply talking about a situation where the user asks for 1500 in the > <running> but the server can't quite program that in the h/w due to some > other constraints, or some rounding function, etc and can only do 1492 so > that is what they report in <operational>. I don't think it makes sense for > that leaf to suddenly now show up in the system DS. > > > > Why not? The system-config draft indicates that the contents of the > <system> datastore may change based on events such as a > software/hardware/license change. What else of you think the draft intends > then? > > > > > > [keep scrolling] > > > > > > Jason > > > -----Original Message----- > From: Jürgen Schönwälder <[email protected]> > Sent: Thursday, November 7, 2024 4:02 AM > To: Kent Watsen <[email protected]> > Cc: Jason Sterne (Nokia) <[email protected]>; [email protected] > Subject: Re: [netmod] Re: origin "system" in system-config-09 > > > CAUTION: This is an external email. Please be very careful when clicking > links or > opening attachments. See the URL nok.it/ext for additional information. > > > > On Thu, Nov 07, 2024 at 08:01:14AM +0000, Kent Watsen wrote: > > > > I think it is important to keep the distinction between 'or:system' > and 'sysds:system' since config generated by the system is different > than config originating from a system datastore. > > > I saw this comment last night and it didn’t sit right. > > Assume a server initially has no <system> datastore, and so reports a > node’s > > origin as “ds:system”. > > > Then later supports the <system> datastore, trying to expose some of what > it > > does internally. Nothing has changed with the internal code, only the > datastore > was created. Why should the node’s origin change? > > For me, a valued copied from a datastore is different than a value > generated by some program logic buried somewhere inside the system. I > assume we have different understandings what a system datastore is all > about, which then may be a bigger problem. > > > > I appreciate this perspective, but I also think that the entire goal of > the <system> datastore is to model (as best as possible) the values that > the buried program logic generates. > > > > > > Regarding a value in <operational> varying from a value in <system>, > this just seems like a bug in the YANG defined for the <system> > datastore. > > > For me, the origin indicates where I can find the source of a value. > If the source is the system datastore, then I expect that to be > reported and I expect to find the value also in the system datastore. > If the source of the value is the system itself, then I expect that to > be reported and I do not necessarily expect to find the value in the > system datastore. > > > > I get that but, again, I see any variance as an opportunity for the > server-developer to update the values populated in <system> to better model > the system’s true behavior. > > > > > > I fear we may have a bigger problem by not agreeing on what the system > datastore actually is... > > > > Indeed. It might help to think about the use-case that <system> intends > to support. My understanding is that it’s trying to reveal more about what > the buried program logic does, so that the network’s functioning can be > better understood, e.g., to implement a digital twin. > > > > K. > > > > > > > /js > > -- > Jürgen Schönwälder Constructor University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > _______________________________________________ > netmod mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > _______________________________________________ > netmod mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
