Re: [netmod] How to handle configuration node being effective after system-restart?

["Hauck Wolfgang (ETAS-DAP/XPC-Fe6)" <[e-mail]>]

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 <[e-mail]>
> Gesendet: Dienstag, 26. Juli 2022 09:23
> An: Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]>; Hauck
> Wolfgang (ETAS-DAP/XPC-Fe6) <[e-mail]>
> Cc: [e-mail]
> 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)
> <[e-mail]> 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 <[e-mail]> On Behalf Of Hauck Wolfgang
> >> (ETAS-DAP/XPC-Fe6)
> >> Sent: Wednesday, July 20, 2022 11:34 AM
> >> To: [e-mail]
> >> 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&amp;data=05%7C01%7Cwolfgang.hauck%40etas.com%7Cdc6d
> 6766d4
> >>
> 5e4f36d60808da6ed7b6e0%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0
> %7C0%7C6
> >>
> 37944170117250883%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjo
> >>
> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;s
> data=rYG
> >>
> EhP9A3EEzQFC7BfagIzLXJ9OmFAIxnjFePl%2BJ%2F%2Fs%3D&amp;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
> >> [e-mail]
> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> >>
> .ietf.org%2Fmailman%2Flistinfo%2Fnetmod&amp;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&amp;sdata=y6wxdb16tAOs6P4hOqPLN29fhh%2BjaP0Vk
> wHaO0QIGn
> >> I%3D&amp;reserved=0
> >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >
> ietf.org%2Fmailman%2Flistinfo%2Fnetmod&amp;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&amp;sdata=y6wxdb16tAOs6P4hOqPLN29fhh%2BjaP0VkwHaO
> 0QIGnI%3D&a
> > mp;reserved=0
> >