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
