ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Antonov <antonovserge...@gmail.com>
Subject Re: [DISCUSSION] Single point in API for changing cluster state.
Date Tue, 15 Oct 2019 11:56:21 GMT
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 <agoncharuk@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.scherbakoff@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 <antonovsergey93@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 <mmuzaf@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 <
> antonovsergey93@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.mashenkov@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 <
> > > antonovsergey93@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 <
> > > antonovsergey93@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message