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
