Hi,
When multiple services can potentially modify the same nodes in the device model in conflicting ways (e.g. configure description on one interface with two different values), it means that potentially at least one of those services will be out-of-sync at any given moment. In turn, this means that redeploying/modifying/deleting any of them can lead to some unexpected results.
Even if you protect yourself through some sort of mechanism that stops BAU from breaking critical, what happens when critical overwrites BAU configs (makes BAU out of sync), and then you need to modify BAU for unrelated reasons?
BAU will try to restore the configs overwritten by the critical service - does execution fails now, even though change is unrelated?
All in all, there are some considerations to take into account here.
I think that a different approach will be to stack another service on top that conflicting resource:
You have this low-level service that will manage the conflicting resource.
It will have a list of the inputs that will be populated by the high-level services (BAU, critical), with the type of service associated to each list entry.
Then, the mapping logic of this low-level service will decide according to all high-level services which provided inputs to this service, what the configs should look like.
If we take the interface description a simple example, then the low-level service model will look something like this:
list desc-service {
key "device interface";
leaf device { ... }
leaf interface { ... }
list description {
key service-path;
leaf service-path { ... }
leaf description { ... }
leaf service-type {
type enumeration {
enum bau;
enum critical;
}
}
The mapping logic of the above service will consider all entries on list description (taking into account the content and the type of service to request this content), and will construct the final description accordingly, each time the list changes (each time consuming service is added/removed/modified).
The mapping logic of both BAU and critical services, will add entries to this service, rather than directly populating the device model.
This way, you have a single owner to the shared configs, nothing gets out of sync, and you can apply any sort of logic in order to decide what should be configured or not.
Yftach
