Operating System: All
Platform: All

What can happen is when we assign a field to an Augmentation, we have to ensure that there aren't existing augmentations. Either pull the aug's and update and push back, or update the subtree using the specific key.

https://git.opendaylight.org/gerrit/#/c/21759/

Unfortunately, the code for EndpointBuilder (in fact, any builder) generated by Yangtools provides only "unsafe" version of addAugmentation method. So it is mostly on programmer's good will, whether the potentially existing (in Datastore) augmentations added by some other party will be replaced with the new augmentation or not. The most reliable way seems to carefully chose between "put" or "merge", and general knowledge of possibility to break consistency.

The pressure will be on code reviewers to control the intention of the whole operation.
So far, there was just one such unsafe part of code, which was fixed.
Ideally, a feature request for yangtools should be raised.

I added a method that can check if an EP with given key exists and if it has some other augmentations (not counting our OfOverlayContext/OfOverlayL3Context). So one can chose if put or merge should be done.

The only fragment of code where there was a possibility to unintentionally delete augmentations was eliminated by change https://git.opendaylight.org/gerrit/#/c/22114
Further we have to rely on programmer's understanding of possible consequences of datastore writing operations.