Jan, Jason, thanks for sharing your ideas. Indeed, I thought about the generalised use case, too; i.e. changes of configuration items requiring item specific actions for an actual application. A system-restart is a quite common action, but by far not the only thinkable one.
The suggested approach using a YANG extension statement (https://www.rfc-editor.org/rfc/rfc7950.html#section-7.19) looks the most promising to me. There would be the possibility to use an argument indicating the required action. For me, it has been helpful to study the YANG-module "tailf-meta-extensions" to get an impression what would be possible. Regards, Wolfgang > Von: Jan Lindblad <[email protected]> > Gesendet: Dienstag, 26. Juli 2022 09:23 > An: Sterne, Jason (Nokia - CA/Ottawa) <[email protected]>; Hauck > Wolfgang (ETAS-DAP/XPC-Fe6) <[email protected]> > Cc: [email protected] > Betreff: Re: [netmod] How to handle configuration node being effective after > system-restart? > > 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 > >> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. > >> > etas.com%2F&data=05%7C01%7Cwolfgang.hauck%40etas.com%7Cdc6d > 6766d4 > >> > 5e4f36d60808da6ed7b6e0%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0 > %7C0%7C6 > >> > 37944170117250883%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD > AiLCJQIjo > >> > iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&s > data=rYG > >> > EhP9A3EEzQFC7BfagIzLXJ9OmFAIxnjFePl%2BJ%2F%2Fs%3D&reserved > =0 > >> > >> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > >> > .ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C01%7Cwolfgan > g.h > >> > auck%40etas.com%7Cdc6d6766d45e4f36d60808da6ed7b6e0%7C0ae51e190 > 7c84e4b > >> > bb6d648ee58410f4%7C0%7C0%7C637944170117261606%7CUnknown%7C > TWFpbGZsb3d > >> > 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 > D%7 > >> > C2000%7C%7C%7C&sdata=y6wxdb16tAOs6P4hOqPLN29fhh%2BjaP0Vk > wHaO0QIGn > >> I%3D&reserved=0 > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > > ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C01%7Cwolfgang > .hau > > > ck%40etas.com%7Cdc6d6766d45e4f36d60808da6ed7b6e0%7C0ae51e1907c > 84e4bbb6 > > > d648ee58410f4%7C0%7C0%7C637944170117261606%7CUnknown%7CTWF > pbGZsb3d8eyJ > > > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7 > C2000 > > > %7C%7C%7C&sdata=y6wxdb16tAOs6P4hOqPLN29fhh%2BjaP0VkwHaO > 0QIGnI%3D&a > > mp;reserved=0 > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
