Vladimir,
@param forceDeactivation If {@code true}, cluster deactivation will be
> forced.
It's true that it's possible to infer semantics of forced deactivation from
other parts of API. I just wanted to highlight that exactly this
description explains something that can be guessed by the parameter name.
I suppose to shorten the lookup path and shed a light on deactivation
semantics a bit:
> @param forceDeactivation If {@code true}, cluster will be deactivated even
> if running in-memory caches are present. All data in the corresponding
> caches will be vanished as a result.
Does this make sense?
On Fri, Mar 27, 2020 at 12:00 PM Vladimir Steshin <vlads...@gmail.com>
wrote:
> Ivan, hi.
>
>
> 1) >>> Is it correct? If we are on the same page, let's proceed this way
>
> It is correct.
>
>
> 2) - In many places in the code I can see the following javadoc
>
> > @param forceDeactivation If {@code true}, cluster deactivation will be
> forced.
>
> In the internal params/flags. You can also find /@see
> ClusterState#INACTIVE/ and full description with several public APIs (
> like /Ignite.active(boolean)/ ):
>
> //
>
> /* <p>/
>
> //
>
> /* <b>NOTE:</b>/
>
> //
>
> /* Deactivation clears in-memory caches (without persistence) including
> the system caches./
>
> Should be enough. Is not?
>
>
> 27.03.2020 10:51, Ivan Rakov пишет:
> > 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.
>
