Hello, Ivan.
> Is it correct? If we are on the same page, let's proceed this way.
+1 from me for your plan.
> We have removed GridClientClusterState#state(ClusterState) from Java client
> API. Is it a legitimate thing to do? Don't we have to support API
There is no changes in Public API except discussed in this thread.
GridClientClusterState is in internal package so it’s an internal class.
org/apache/ignite/internal/client/GridClientClusterState.java
> 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.
OK for me.
Feel free to suggest your statement.
> 27 марта 2020 г., в 10:51, Ivan Rakov <ivan.glu...@gmail.com> написал(а):
>
> 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.
>>>>>>
>>>>
>>
