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 <[email protected]> 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 <[email protected]>:
>
> > 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 <[email protected]>
> > 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 <[email protected]
> > >:
> > >
> > > > 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
