Hi, Igniters. Note that DeactivateCommand#confirmationPrompt will be ignored in case of auto confirmation.
I agree that the force flag should be removed when the user data and datastructures will not be clearing on deactivation. For now, cmd, jmx and rest interfaces should be covered. вт, 24 мар. 2020 г. в 15:56, Вячеслав Коптилин <slava.kopti...@gmail.com>: > > Hello Nikolay, > > I am talking about the interactive mode of the control utility, which > requires explicit confirmation from the user. > Please take a look at DeactivateCommand#prepareConfirmation and its usages. > It seems to me, this mode has the same aim as the forceDeactivation flag. > We can change the message returned by DeactivateCommand#confirmationPrompt > as follows: > "Warning: the command will deactivate the cluster nnn and clear > in-memory caches (without persistence) including system caches." > > What do you think? > > Thanks, > S. > > вт, 24 мар. 2020 г. в 13:07, Nikolay Izhikov <nizhi...@apache.org>: > > > Hello, Slava. > > > > Are you talking about this commit [1] (sorry for commit message it’s due > > to the Github issue)? > > > > The message for this command for now > > > > «Deactivation stopped. Deactivation clears in-memory caches (without > > persistence) including the system caches.» > > > > Is it clear enough? > > > > [1] > > https://github.com/apache/ignite/commit/4921fcf1fecbd8a1ab02099e09cc2adb0b3ff88a > > > > > > > 24 марта 2020 г., в 13:02, Вячеслав Коптилин <slava.kopti...@gmail.com> > > написал(а): > > > > > > Hi Nikolay, > > > > > >> 1. We should add —force flag to the command.sh deactivation command. > > > I just checked and it seems that the deactivation command > > > (control-utility.sh) already has a confirmation option. > > > Perhaps, we need to clearly state the consequences of using this command > > > with in-memory caches. > > > > > > Thanks, > > > S. > > > > > > вт, 24 мар. 2020 г. в 12:51, Nikolay Izhikov <nizhi...@apache.org>: > > > > > >> Hello, Alexey. > > >> > > >> I just repeat our agreement to be on the same page > > >> > > >>> The confirmation should only present in the user-facing interfaces. > > >> > > >> 1. We should add —force flag to the command.sh deactivation command. > > >> 2. We should throw the exception if cluster has in-memory caches and > > >> —force=false. > > >> 3. We shouldn’t change Java API for deactivation. > > >> > > >> Is it correct? > > >> > > >>> The DROP TABLE command does not have a "yes I am sure" clause in it > > >> > > >> I think it because the command itself has a «DROP» word in it’s name. > > >> Which clearly explains what will happen on it’s execution. > > >> > > >> On the opposite «deactivation» command doesn’t have any sign of > > >> destructive operation. > > >> That’s why we should warn user about it’s consequences. > > >> > > >> > > >>> 24 марта 2020 г., в 12:38, Alexey Goncharuk < > > alexey.goncha...@gmail.com> > > >> написал(а): > > >>> > > >>> Igniters, Ivan, Nikolay, > > >>> > > >>> I am strongly against adding confirmation flags to any kind of APIs, > > >>> whether we change the deactivation behavior or not (even though I agree > > >>> that it makes sense to fix the deactivation to not clean up the > > in-memory > > >>> data). The confirmation should only present in the user-facing > > >> interfaces. > > >>> I cannot recall any software interface which has such a flag. None of > > the > > >>> syscalls which delete files (a very destructive operation) have this > > >> flag. > > >>> The DROP TABLE command does not have a "yes I am sure" clause in it. > > As I > > >>> already mentioned, when used programmatically, most users will likely > > >>> simply pass 'true' as the new flag because they already know the > > >> behavior. > > >>> This is a clear sign of a bad design choice. > > >>> > > >>> On top of that, given that it is our intention to change the behavior > > of > > >>> deactivation to not loose the in-memory data, it does not make sense to > > >> me > > >>> to change the API. > > >> > > >> > > > > -- Best wishes, Amelchev Nikita
