Jason, Wolfgang, I completely agree defining an extension statement would be the way to go here. I think I have already seen some proprietary extensions in this vein. Leveraging NMDA would also be the right thing, on servers that are NMDA capable.
Best Regards, /jan > On 26 Jul 2022, at 00:46, Sterne, Jason (Nokia - CA/Ottawa) > <[email protected]> wrote: > > Hello Wolfgang, > > I don't see any clear right answer here. > > You're talking about a condition that must be met for a configuration change > to take operational effect. In this case it is a restart. But there could be > other types of similar conditions. E.g. other nodes that need: > - an admin-state to be disabled and then enabled (i.e. toggle/kick a protocol) > - some other magic before it takes effect > > *Maybe* there are a set of somewhat common conditions across many types of > systems that could be standardized in a YANG extension (and tag those nodes). > Or using a new standardized YANG model to list "needs restart" nodes (or > nodes with other standard conditions). These solutions are along the lines > of your option 2 (although I'd lean more towards the extension route). > > Using a leaf to indicate "needs restart" is possible but I think that would > be a proprietary-only approach. Would you then also have some state > information that says which list of nodes are waiting on a restart ? Or > maybe in your case it is "good enough" to just know you need a restart. But a > client app would have to be specifically programmed with knowledge of that > "needs restart" leaf. > > I'm not sure I understand your approach #3. > > Note that it is probably useful here to talk about the "applied config" > concept for this node. Let's pretend node 'foo' was configured with value 5 > and a system restart occurred after that. Then the user configures value 23 > but does not restart the system: > A) IETF NMDA would say that reading node 'foo' in the operational datastore > should return 5 (but reading node 'foo' in the running DS would return 23) > B) Another approach might be to have another leaf (config false) called > 'oper-foo' that always reflects the current operational value (e.g. 5 in this > case) > C) OpenConfig would have a "state" copy of node foo and reading that would > return 5 (a bit like B above, although with a 'well known convention') > > A client could diff the running config vs the applied config and at least > know there is a difference (but then there isn't anything standard to know a > restart is needed to bring them into sync). > > Jason > >> -----Original Message----- >> From: netmod <[email protected]> On Behalf Of Hauck Wolfgang >> (ETAS-DAP/XPC-Fe6) >> Sent: Wednesday, July 20, 2022 11:34 AM >> To: [email protected] >> Subject: [netmod] How to handle configuration node being effective after >> system-restart? >> >> Hi all! >> >> The use case I think about is as follows: >> >> A configuration node in a YANG model is effective only after a system- >> restart (i.e. not only a restart of the NETCONF server). Now I would like to >> see from a YANG model if a system-restart actually has to be carried out for >> that node. E.g. as system operator I would like to know from the model only >> if I have to wait and poll for the operational state resulting from the >> configuration, or if I have to actively restart the system. At the end, I >> would >> like to publish a YANG model such that the model's user is able to derive his >> or her actions only from that model without further studying any >> documentation. >> >> Modelling how to perform a system-restart is easy, as I have seen in the >> draft "Factory default Setting". Recognising its necessity is the difficulty >> here. >> >> What would be the best practice here? >> >> I can think about three options: >> >> 1) Explicitly modelling the property "system-restart needed", e.g. by a leaf >> next to the configuration node. >> >> 2) Providing a YANG module listing all configuration nodes requiring a >> system- >> restart. >> >> 3) Using the startup datastore. However, as the conventional configuration >> datastores have all the same datastore schema, there seems to be no >> possibility to see the property "system-start needed". Otherwise, it could >> have been modelled by a configuration node in the startup datastore, and as >> status node in all other datastores. >> >> I highly appreciate any hints. - Thanks. >> >> Regards, >> Wolfgang >> >> --- >> >> Dr. Wolfgang Hauck >> Engineering Data Acquisition and Processing - Lead Architect >> >> ETAS GmbH, ETAS-DAP/XPC-Fe6 >> Borsigstraße 24, 70469 Stuttgart, Germany >> www.etas.com >> >> ETAS - Empowering Tomorrow's Automotive Software >> >> Managing Directors: Christoph Hartung, Günter Gromeier, Götz Nigge >> Chairman of the Supervisory Board: Dr. Walter Schirm >> Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart, HRB: >> 19033 >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
