On 27/11/2018 20:45, Robert Varga wrote:
>> But genius code is also doing a put and that works, it doesn't delete
>> any existing ports. In fact Genius code most times adds multiple ports
>> in quick succession. Only difference between two is Genius code sets
>> createMissingParents=True.
> Got a pointer to that code?
>
> Assuming bridgeNode exists in the data store, createMissingParents=true
> should not have a bearing on the effects of the overall list (but I may
> be missing something or there could be a bug).
>

Sorry for self-reply, it just occurred to me.

There are slight differences in handling
createMissingParents={true,false} between controller APIs, md-sal APIs
and mdsal-3.0.2 in this particular case (keyed list entry):

1) Controller and MD-SAL < 3.0.2 (read: up until Neon right now) with
createMissingParents=false will issue an empty merge to the parent list:

https://github.com/opendaylight/controller/blob/master/opendaylight/md-sal/sal-binding-broker/src/main/java/org/opendaylight/controller/md/sal/binding/impl/AbstractWriteTransaction.java#L98

https://github.com/opendaylight/mdsal/blob/11ed4d0bd7625ae2202782e0785ec15981e49130/binding/mdsal-binding-dom-adapter/src/main/java/org/opendaylight/mdsal/binding/dom/adapter/AbstractWriteTransaction.java#L101

This is needed because before yangtools-2.1.0 the list needed to be
created, but there is no way to address the list itself in Binding (you
can address a list's parent and you can address all its entries, but you
cannot address the list itself)


2) MDSAL >= 3.0.2 (read: Neon real soon now) will take no additional steps

This is noted in https://jira.opendaylight.org/browse/MDSAL-383: with
yangtools-2.1.0 the list node comes as goes as needed, hence the hoopla
in 1) is not necessary.


3) Controller with createMissingParents=true will walk the path and
issue an empty merge for each path component:

https://github.com/opendaylight/controller/blob/master/opendaylight/md-sal/sal-binding-broker/src/main/java/org/opendaylight/controller/md/sal/binding/impl/BindingDOMWriteTransactionAdapter.java#L60

Note that this is a superset of 1).


4) MD_SAL with createMissingParents=true will create a single "empty
parents" structure and merge it that as immediate descendant of root:

https://github.com/opendaylight/mdsal/blob/master/binding/mdsal-binding-dom-adapter/src/main/java/org/opendaylight/mdsal/binding/dom/adapter/AbstractWriteTransaction.java#L82


The difference between 3) and 4) exists because 4) is seen as more
efficient way of achieving the same goal -- but the details are sketchy,
as that was Tony's patch a looong time ago. I do believe it was all
about the utility 4) uses actually coming from netconf to yangtools (and
not being available when 3) was implemented) and us not wanting to risk
a behaviour change in the controller.


Nevertheless, the expectation is that all of these different approaches
produce the same resulting data tree content and same ModificationType
in associated DTCLs.

So if we have exhausted all other alternatives, someone can check if the
behaviour changes with
https://git.opendaylight.org/gerrit/#/q/topic:mdsal-3.0.2, assuming
Netvirt is using MD-SAL APIs :)

Regards,
Robert