First of all, I want to talk about our usecases. We have some named preset configuration and whenever user change the preset configuration, other some configurations should be change to other preset value. you can think like that profile names and profile settings. Profile settings depends on active profile(profile name). Whenever user change the profile name, value of depended configuration should be changed automatically.
How is it possible in yang?
Is it possible to have preset configurations depends on a value of single leaf?
Main idea: I’m trying to do it in a yang files. So, Some restriction can be acceptable.
There is no such thing as populating configuration automatically based on other configuration changes, in YANG.
In ConfD there are callbacks you can use to automatically configure things as part of a single transaction.
Another way that may work in some cases is if you use the “when” statement in YANG which may hide or show nodes depending on the “when” expression evaluation. You can for example has some nodes under the “when” statement parent node, that have default values…
The callbacks referred to by Nabil are described in the chapter “Transformations, Hooks, and Hidden Data” of the user guide. In your case the tool of choice would be transaction hooks that are triggered by a configuration change at the commit time and can do further configuration changes. Note though that in general this has some drawbacks, any northbound management system may not be aware of this auto-configuration mechanism and would become out of sync every time it is triggered; so alternatives should be considered.
I got your point. If I change something automatically on the background. The other netconf clients will be out of sync. But if we think in our case. Changing data automatically sounds like sense, right?
Let’s think about use case. We have some profile settings which depends on user. And we want to apply setting according to data of active user. In that case, what do u think about alternative approach? I’m open to new idea
I’m assuming your data model looks somewhat like this:
container users {
list user-profile {
key profile-name;
leaf profile-name {
type string;
}
leaf profile-value {
type string;
}
// other leafs
}
list user {
key user-name;
leaf user-name {
type string;
}
leaf user-profile {
type leafref {
path ../../user-profile/profile-name;
}
mandatory true;
}
leaf user-value {
type string;
}
// other leafs
}
}
Now, value of the leaf user-value is given by profile-value, so when the latter changes, the former should change too. But that in effect means that user-value is not really configurable and should not be modelled so - the leaf should not be there at all (if its value can easily be computed, there is really no reason to keep it), or perhaps should be config false.
The following list is stolen from a to-be-published-soon presentation that discusses so called “configuration side-effects” - i.e. exactly this kind of behavior:
It is best to remove the side effects completely
If not possible, then minimize them or don’t do them for programmatic interfaces (NETCONF/RESTCONF/…)
Hide auto-configured leaves from programmatic interfaces
Require configuration data to be given in canonical format
