Hi, Igniters.
I'd like to remind you that cluster can be deactivated by user with 3
utilities: control.sh, *JMX and the REST*. Proposed in [1] solution is
not about control.sh. It suggests same approach regardless of the
utility user executes. The task touches *only* *API of the user calls*,
not the internal APIs.
The reasons why flag “--yes” and confirmation prompt hasn’t taken into
account for control.sh are:
-Various commands widely use “--yes” just to start. Even not dangerous
ones require “--yes” to begin. “--force” is dedicated for *harmless
actions*.
-Checking of probable data erasure works after command start and
“--force” may not be required at all.
-There are also JMX and REST. They have no “—yes” but should work alike.
To get the deactivation safe I propose to merge last ticket with
the JMX fixes [2]. In future releases, I believe, we should estimate
jobs and fix memory erasure in general. For now, let’s prevent it. WDYT?
[1] https://issues.apache.org/jira/browse/IGNITE-12614
[2] https://issues.apache.org/jira/browse/IGNITE-12779
24.03.2020 15:55, Вячеслав Коптилин пишет:
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.
