Sergey Antonov, > Read-only mode doesn't affects rebalance process. After activation (in read-only mode or not) rebalancing is possible to begin and the grid will not be free of updates until it's finished. So the grid will not be in truly read-only mode even if cache updates are prohibited. Probably it would be enough just wait until rebalancing is finished before releasing future.
> How about INACTIVE, ACTIVE, ACTIVE_READ-ONLY states? INACTIVE, READ_WRITE, READ_ONLY seems more appropriate for ClusterState. I do not understand the necessity of handling states comparison on transition. Why not just return current(previous) state ? Could you give more detailed explanation for this ? вт, 29 окт. 2019 г. в 14:25, Sergey Antonov <antonovserge...@gmail.com>: > He, Igniters! > > I'd like to share some points encountered during work on ticket [1]: > > - I added property clusterStateOnStart with type ClusterState to > IgniteConfiguration. The property will be analogue of activeOnStart. > Default value of the property will be ACTIVE for keeping defalut value > consistency. Also I marked property activeOnStart as deprecated. > - I introduced order on values of ClusterState. It needs for user > friendly behaviour during cluster state transition. If cluster is > changing > state from state_A to state_B and user is requesting current cluster > state without waiting end of transition we must return lesser of two > states: state_A and state_B. I think the order must be: ACTIVE > > READ_ONLY > INACTIVE. Examples (state_A -> state_B = response on the > users cluster state request during transition): > - ACTIVE -> INACTIVE = INACTIVE (Now we have this behavior) > - INACTIVE -> ACTIVE = INACTIVE (Now we have this behavior) > - ACTIVE -> READ_ONLY = READ_ONLY > - READ_ONLY -> ACTIVE = READ_ONLY > - READ_ONLY -> INACTIVE = INACTIVE > - INACTIVE -> READ_ONLY = INACTIVE > > I'd like to know your opinion about my points. What do you think about it? > > [1] https://issues.apache.org/jira/browse/IGNITE-12225 > > > вт, 15 окт. 2019 г. в 14:56, Sergey Antonov <antonovserge...@gmail.com>: > > > Hi, Alexei! > > > > Thank you for reply! > > > > > The states ACTIVE, INACTIVE, READ-ONLY look confusing. Actually > > read-only cluster is active too. > > How about INACTIVE, ACTIVE, ACTIVE_READ-ONLY states? > > > > > Also it would be useful to allow users wait for re-balance which could > > happen after activation in read-only mode to achieve really idle grid. > > Read-only mode doesn't affects rebalance process. > > > > > I would suggest adding new property to Ignite configuration like > > setActivationOptions(ActivationOption... options) which should be mutable > > in runtime. > > I'm not sure that it's good idea. @Alexey Goncharuk > > <agoncha...@apache.org> I'd like to know your opinion about activation > > option and storing them on PDS. > > > > > This proposal also better regarding backward compatibility. > > Which kind of compatibility did you mean? New cluster mode doesn't > affects > > PDS compatibility. > > > > ср, 25 сент. 2019 г. в 13:26, Alexei Scherbakov < > > alexey.scherbak...@gmail.com>: > > > >> Sergey Antonov, > >> > >> The states ACTIVE, INACTIVE, READ-ONLY look confusing. > >> Actually read-only cluster is active too. > >> > >> I would suggest adding new property to Ignite configuration like > >> setActivationOptions(ActivationOption... options) which should be > mutable > >> in runtime. > >> > >> For control.sh should be the same options for activate command. > >> > >> Also it would be useful to allow users wait for re-balance which could > >> happen after activation in read-only mode to achieve really idle grid. > >> > >> So, available options list in my opinion: READ_ONLY, WAIT_FOR_REBALANCE. > >> > >> This proposal also better regarding backward compatibility. > >> > >> вт, 24 сент. 2019 г. в 20:35, Sergey Antonov <antonovserge...@gmail.com > >: > >> > >> > Maxim, > >> > > >> > > I think from the user point the INACTIVE -> READ-ONLY transition [1] > >> > should be allowed prior to adding a new `state` command [2] to avoid > >> > unnecessary error messages. > >> > Yes. I plan complete both tickets till the code freeze of 2.8 release. > >> > > >> > > I also think we can avoid the word 'set` in this command. > >> > I don't think so. We already have command control.sh --state command > for > >> > getting current state. I think we shouldn't "overload" commands in > >> > control.sh. > >> > > >> > > What about cluster deactivation confirmation? Will it be used for > all > >> the > >> > cluster state changes? > >> > Yes. I think we should confirm any cluster state transition. > >> > > >> > вт, 24 сент. 2019 г. в 19:07, Maxim Muzafarov <mmu...@apache.org>: > >> > > >> > > Sergey, > >> > > > >> > > +1, I like your idea. > >> > > > >> > > I think from the user point the INACTIVE -> READ-ONLY transition [1] > >> > > should be allowed prior to adding a new `state` command [2] to avoid > >> > > unnecessary error messages. I also think we can avoid the word 'set` > >> > > in this command. > >> > > > >> > > Example: control.sh --state ACTIVE [--yes] > >> > > > >> > > > >> > > What about cluster deactivation confirmation? Will it be used for > all > >> > > the cluster state changes? > >> > > Deactivate cluster: > >> > > control.(sh|bat) --deactivate [--yes] > >> > > > >> > > > >> > > [1] https://issues.apache.org/jira/browse/IGNITE-11866 > >> > > [2] https://issues.apache.org/jira/browse/IGNITE-12225 > >> > > > >> > > > >> > > > >> > > On Tue, 24 Sep 2019 at 16:50, Sergey Antonov < > >> antonovserge...@gmail.com> > >> > > wrote: > >> > > > > >> > > > Andrey, > >> > > > > >> > > > > What are state transitions valid? > >> > > > Now all transitions are valid, except INACTIVE -> READ-ONLY. This > >> > > > transition will be fixed under [1] > >> > > > > >> > > > > Regarding state names, as I understand, all transitions are > valid > >> > from > >> > > > any to any of 3 states. > >> > > > Yes, see my comment above. > >> > > > > >> > > > > But, regarding on console.sh command it is not obvious. > >> > > > Yes. It's one of points why we should have single command in > >> > control.sh. > >> > > > > >> > > > > What effect will --read-only-on and --read-only-off commands > have > >> if > >> > > > current state is INACTIVE ? > >> > > > --read-only-on - cluster will be activated in read-only mode > >> > > > --read-only-off - cluster will be activated. I.e --read-only-off > >> will > >> > > have > >> > > > the same effect as --activate > >> > > > [1] https://issues.apache.org/jira/browse/IGNITE-11866 > >> > > > > >> > > > вт, 24 сент. 2019 г. в 16:40, Andrey Mashenkov < > >> > > andrey.mashen...@gmail.com>: > >> > > > > >> > > > > Sergey, > >> > > > > > >> > > > > What are state transitions valid? > >> > > > > For now we have only 2 states (active and inactive) and possible > >> > > > > transitions are obvious Active <--> Inactive. > >> > > > > > >> > > > > Regarding state names, as I understand, all transitions are > valid > >> > from > >> > > any > >> > > > > to any of 3 states. > >> > > > > But, regarding on console.sh command it is not obvious. > >> > > > > What effect will --read-only-on and --read-only-off commands > have > >> if > >> > > > > current state is INACTIVE ? > >> > > > > > >> > > > > > >> > > > > On Tue, Sep 24, 2019 at 4:23 PM Sergey Antonov < > >> > > antonovserge...@gmail.com> > >> > > > > wrote: > >> > > > > > >> > > > > > Also, I would add IGNITE-12225 > >> > > > > > <https://issues.apache.org/jira/browse/IGNITE-12225> ticket > to > >> 2.8 > >> > > > > release > >> > > > > > scope. > >> > > > > > > >> > > > > > вт, 24 сент. 2019 г. в 16:18, Sergey Antonov < > >> > > antonovserge...@gmail.com > >> > > > > >: > >> > > > > > > >> > > > > > > Hi, Igniters! > >> > > > > > > > >> > > > > > > We have 3 cluster states at the moment: inactive, active, > >> > > read-only. > >> > > > > > > > >> > > > > > > For getting current cluster state and changing them > >> IgniteCluster > >> > > has > >> > > > > > > methods: > >> > > > > > > > >> > > > > > > - boolean active(), void active(boolean active) - for > >> cluster > >> > > > > > > activation/deactivation > >> > > > > > > - boolean readOnly(), void readOnly(boolean readOnly) - > for > >> > > > > > > enabling/disabling read-only mode. > >> > > > > > > > >> > > > > > > Also we have control.sh commans for changing cluster state: > >> > > > > > > > >> > > > > > > - --activate > >> > > > > > > - --deactivate > >> > > > > > > - --read-only-on > >> > > > > > > - --read-only-off > >> > > > > > > > >> > > > > > > For me current API looks unuseful. My proposal: > >> > > > > > > > >> > > > > > > 1. Create enum ClusterState with values ACTIVE, INACTIVE, > >> > > READ-ONLY. > >> > > > > > > 2. Add methods to IgniteCluster: > >> > > > > > > - ClusterState state() returns current cluster state > >> > > > > > > - void state(ClusterState newState) changes cluster > >> state > >> > to > >> > > > > > > newState state > >> > > > > > > 3. Mark as deprecated the following methods in > >> IgniteCluster: > >> > > > > boolean > >> > > > > > > active(), void active(boolean active), > >> > > > > > > 4. Add new command to control.sh: control.sh --set-state > >> > > > > > > (ACTIVE|INACTIVE|READ-ONLY) > >> > > > > > > 5. Add warn message that command is depricated in > >> control.sh. > >> > > > > > > Commands: --activate, --deactivate, --read-only-on, > >> > > --read-only-off > >> > > > > > > > >> > > > > > > > >> > > > > > > I created ticket [1] in Jira for it. > >> > > > > > > > >> > > > > > > What do you think about my proposal? > >> > > > > > > > >> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12225 > >> > > > > > > -- > >> > > > > > > BR, Sergey Antonov > >> > > > > > > > >> > > > > > > >> > > > > > > >> > > > > > -- > >> > > > > > BR, Sergey Antonov > >> > > > > > > >> > > > > > >> > > > > > >> > > > > -- > >> > > > > Best regards, > >> > > > > Andrey V. Mashenkov > >> > > > > > >> > > > > >> > > > > >> > > > -- > >> > > > BR, Sergey Antonov > >> > > > >> > > >> > > >> > -- > >> > BR, Sergey Antonov > >> > > >> > >> > >> -- > >> > >> Best regards, > >> Alexei Scherbakov > >> > > > > > > -- > > BR, Sergey Antonov > > > > > -- > BR, Sergey Antonov > -- Best regards, Alexei Scherbakov
