Specifically in this case it's not in a shutdown flow, and even if it was and my example is bad, it doesn't prove my point is wrong. There are obviously many examples where this permissive mode is bad, and this is why the default should behave as of today. I'm trying to argue that there are situations where permissive mode is wanted. For example let's say I have a node (switch), inside the node I have a openflow table and inside the openflow table I have a flow. I can *theoretically* write a code in Interface-Delete that deletes all the flows related to this interface, and in Switch-Delete a code that deletes all the tables of the node, or even the node itself. Now if the switch is deleted, all the Interface delete listeners are triggered too right ? In this case the flow deletions will happen concurrently with the node delete, and I can step on this exception, even though I don't really care it logically failed.
> To solve what you are asking for is to prove that the two deletes were > deleting the same data Not really, I'm specifically talking about cases that the entity you are trying to delete is not there anymore for any reason (Maybe its father was deleted, maybe the entity itself was deleted, etc.). I'm saying that in these specific situations, we will keep the same logic and result for the operation, just not throw an exception to the user. My suggestion is focused on the higher layer (API to user), this is why I specifically talked about ModifiedNodeDoesNotExistException. -----Original Message----- From: Robert Varga [mailto:n...@hq.sk] Sent: Monday, January 23, 2017 12:10 AM To: Sela, Guy <guy.s...@hpe.com>; controller-dev@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; Tom Pantelis <tompante...@gmail.com> Subject: Re: Deleting a node from MD-SAL that doesn't exist / already deleted On 01/22/2017 09:16 AM, Sela, Guy wrote: > Hi > I totally agree with you that it might indicate there is a cleanup code that > runs in an un-coordinated fashion. > There is no value in explaining what causes this problem in this specific > case, because it is probably solvable. > My point was the bigger picture, should we even solve this ? Is this even a > problem that a developer needs to think of? > If you allow "permissive" mode to delete operations, you basically allow the > developer to say - I don't care if someone else is concurrently cleaning up > the same part I'm cleaning, it's doesn't matter to me. As long as it will be > deleted in the end, that's fine by me. > This will not be the default mode, default mode would behave as today. Hello, If the shutdown is uncoordinated, you can have a situation where that other component starts up, and your cleanup will delete its state. It is not a question of 'default mode' or a 'flag'. To solve what you are asking for is to prove that the two deletes were deleting the same data -- and that means we would have to retain complete version history (for as long as there is any snapshots can reference it). This particular call site does not cover deletes only, but rather any subtree overlaps, including unattached subtrees (you are writing /a/b/c/d, /a/b was deleted, what is the result?). See code surrounding https://github.com/opendaylight/yangtools/blob/master/yang/yang-data-impl/src/main/java/org/opendaylight/yangtools/yang/data/impl/schema/tree/ModificationApplyOperation.java for details. Regards, Robert _______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
