Robert & Tom, Faseela reminded us (thank you) in genius of this thread in the context of the ongoing review of https://git.opendaylight.org/gerrit/#/c/63118/, where there appears to be some disagreement (suneel verma) as to whether a delete() must be preceded by an exists check to avoid some exception..
I've therefore just re-read this thread, and my understand is that this is about something else, and that therefore https://git.opendaylight.org/gerrit/#/c/63118/ is correct (the check there is not needed, even dangerous) - perhaps you would have a second to confirm this reading and +1 that change? Tx, M. -- Michael Vorburger, Red Hat vorbur...@redhat.com | IRC: vorburger @freenode | ~ = http://vorburger.ch On Mon, Jan 23, 2017 at 9:45 AM, Sela, Guy <guy.s...@hpe.com> wrote: > 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 >
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
