Jan Lindblad <j...@tail-f.com> writes: > Hi, >>> While I agree with Martin, in our systems we have a number of places, where >>> the system does create configuration in running, due to >>> >>> different levels of automation and autonomous algorithms kick-in >>> the created config needs to be possible to be further modified by the >>> operator >>> the created config needs to be referenced from operator created config >>> the created config is not always ephemeral, it might need to be part of >>> backup/restore >> This is only a sampling from "the list of excuses". I have heard many more. >> The road to hell is paved with good intentions, however. If we want to build >> automation based on sound theory, clearly separating the orders from >> managers from a system's own operational view is key, IMO. Reliability, >> security, accountability are growing in importance, and they all play in >> this direction. >> >> We may not need to standardize rules to outlaw the above; the market will >> take care of that. What we need to ensure is that it is possible to be >> standards compliant without having to implement design excuses like these. >> >> >> NMDA has a lot of room for proprietary mechanisms for converting <running> >> to <intended>. >> Many times the features desired by engineers exceed the capabilities of >> YANG, such as >> a dynamic default leaf. YANG allows a simple constant, and no business >> logic to pick the default. >> This is a very valid use of "server auto-magic". >> >> Maybe a future version of YANG can improve the client visibility into this >> "auto-magic" > > As you say, this is not uncommon. I usually recommend to leave out any > default statement, and write in the description what happens if this > leaf isn't set. The operator can then override the default by giving a > value.
Anyway, this is not a case where the server writes something on its own to a configuration datastore. > > While some more advanced features for default values may be of some > utility, the simplicity of YANG is also important. We don't want to > make the YANG models -- the interface contracts -- the new place for > all business logic. Absolutely. Lada > > /jan > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
