Robert and other controller/mdsal experts, On Tue, Sep 19, 2017 at 6:45 PM, Michael Vorburger <vorbur...@redhat.com> wrote:
> 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? > do you have any input re. https://git.opendaylight.org/gerrit/#/c/63118/ ? There's a doubt in the discussion of that change whether a delete does fail if non-existent or not - as its JavaDoc says... > 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
