If two devices are added to the list with the same "group" value then I want my RFS to add additional common configuration to both of them. If a device is removed so the peer device remains alone in the group, I want the additional configuration to be removed from both devices.
What's the best way to perform this?
This is easy to achieve with a bit of Python or Java. The way you model it here, however, the code would have to scan all service instances. If this service scales to a lot of instances, that would take a bit of CPU. If instead you modeled leaf group as a leafref to the other device, the search would not be needed and you could also use this "XPATH bridge" to cross over to the other device in your template.
Is there any way from a Java RFS to force the redeployment of another instance of the service, so each device looks for possible peers, and updates itself only?
Yes, but you would need an intermediary (subscriber, kicker, etc) because you can't start a new transaction (which redeploy does) while you are in the RFS create() code.
Is there any way when applying a template from a Java RFS to use another node as backreference rather than the currently changed service?
Yes. What you need is some element in the service YANG that points to some location in the YANG tree from where you can navigate to the desired data using a relative path. For example, modeling the leaf group as a leafref to the other device, or as a leafref to a group list, which in turn has leafrefs to both/all the members would do it.
You could also implement a leaf the-other-device { type leafref { ... } } backed by a data provider that points out which device this one is paired with (if any). Then the template could simply use {/the-other-device/...} to access the other device. This data provider approach sounds like more work than the above, tho.
I guess I could attach the servicepoint at the parent level, so the callback would be triggered for any change, and loop over all devices, but this looks like an expensive operation in case there are many devices.
Yes. And the semantics would change from N service instances to a single one. Probably not a good idea.
I would prefer avoiding adding a leaf to the device model to track this, because I don't want this flag to be visible and/or changeable by anything else than the RFS code.
Well, if you model the leaf group as I suggested, the solution would be simple, straight forward and efficient. If you want to keep group as a string (and scan all service instances) then you need some variant of the data provider approach.
