Vladimir, Igniters,
Let's emphasize our final plan.
We are going to add --force flags that will be necessary to pass for a
deactivation if there are in-memory caches to:
1) Rest API (already implemented in [1])
2) Command line utility (already implemented in [1])
3) JMX bean (going to be implemented in [2])
We are *not* going to change IgniteCluster or any other thick Java API,
thus we are *not* going to merge [3].
We plan to *fully rollback* [1] and [2] once cache data survival after
activation-deactivation cycle will be implemented.
Is it correct? If we are on the same page, let's proceed this way.
I propose to:
- Create a JIRA issue for in-memory-data-safe deactivation (possibly,
without IEP and detailed design so far)
- Describe in the issue description what exact parts of API should be
removed under the issue scope.
Also, a few questions on already merged [1]:
- We have removed GridClientClusterState#state(ClusterState) from Java
client API. Is it a legitimate thing to do? Don't we have to support API
compatibility for thin clients as well?
- In many places in the code I can see the following javadoc
> @param forceDeactivation If {@code true}, cluster deactivation will be
> forced.
>
> As for me, this javadoc doesn't clarify anything. I'd suggest to describe
in which cases deactivation won't happen unless it's forced and which
impact forced deactivation will bring on the system.
[1]: https://issues.apache.org/jira/browse/IGNITE-12701
[2]: https://issues.apache.org/jira/browse/IGNITE-12779
[3]: https://issues.apache.org/jira/browse/IGNITE-12614
--
Ivan
On Tue, Mar 24, 2020 at 7:18 PM Vladimir Steshin <vlads...@gmail.com> wrote:
> 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.
> >>>>
> >>
>
