Imagine the common situation where a NSO service is modifying 10 devices and let's say each device have 1000 lines of configs to be modified (total 10000 lines in the get-modifications.)
When you do an update of the service that only one device, NSO would need to calculate diff for the 10.000 lines even if for 9 of the 10 devices there are no changes.
Let's say now that you re-organize your code and use stacked services where each changes on a given device is isolated in a service instance with 10 input parameters. For any update (or re-deploy) call that affects one device, for the 9 other device you will only be evaluating 9x10=90 leafs instead of 9x1000=9000.
There are many similar examples but the idea is always the same, to isolate things that do not typically change "together" and the benefits are in service updates/re-deploys rather than create or delete.
Thank you very much for your reply.
I understand the idea and appreciate the idea. My question is how to do it.. i couldn't figure out how to maintain the situation that when i re-deploy the upper-service, lower-service will only be diff-checked in case "lower-service input parameters" are modified. I tried to explain how i tried this above.
Or may be i am missing something very obvious here.
Thanks and regards.
I believe your problem is that you are having a 1:1 relationship between the number of top services instances and the lower service instances. You need to make that relationship 1:N. So, one top service creates many lower services so you can play with the different combinations.
Maybe something like:
The important point is if you were able to create the relationship where a single top instance has many lower instances (what I called 1:N). If you do so, you will be able to see when you update the top service, only the create() code of the instances that are modified is actually called.
When dealing with re-deploy, there are two behaviors:
- deep: will re-deploy all service instances involved (N+1) because you want to make sure that the full tree is in-sync all the way two to the device configuration.
- shallow: you only re-deploy the top service and all the lower service. However, if that re-deploy would imply changes in some of the lower services, the create() code of these services is also run (to capture all effects that running re-deploy will have). That is why you are seeing the changes being applied. Note that with a "shallow" option, you may still be out-of-sync with the device config as you did not tested the instances where there was no modifications.
Of course, shallow should be more performant than deep.
BTW, If possible, you want to try to avoid that and always drive modifications from top to bottom and avoid unsync between service instances.