You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Sergey Antonov <an...@gmail.com> on 2019/09/24 13:18:19 UTC
[DISCUSSION] Single point in API for changing cluster state.
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
Re: [DISCUSSION] Single point in API for changing cluster state.
Posted by Sergey Antonov <an...@gmail.com>.
Igniters, ticket[1] in patch available state.
Anybody want to review changes?
[1] https://issues.apache.org/jira/browse/IGNITE-12225
пн, 25 нояб. 2019 г. в 14:56, Sergey Antonov <an...@gmail.com>:
> Alexei Scherbakov,
>
> > 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.
> I'm afraid, we can't guarantee truly read-only mode due to TTL on cache
> entries
>
> > 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 ?
> User could face the unexpected behaviour, If we always return current
> state (target state of transition) or previous state (initial state of
> transition). For example, transition from INACTIVE to ACTIVE and we return
> current state. User gets cluster state (ACTIVE) and tries to get cache, but
> activation has not been completed yet. User will get exception, but cluster
> state returns ACTIVE value. So, we can't always return current state.
> Another example: transition from ACTIVE to READ_ONLY and we return
> previous state. User gets cluster state (ACTIVE) and tries to update value
> in cache. User could get ClusterReadOnlyModeException in this case.
> So we should return state with lower functionality from previous and
> current states for avoiding unexpected behaviour.
>
>
>
> чт, 31 окт. 2019 г. в 18:24, Alexei Scherbakov <
> alexey.scherbakoff@gmail.com>:
>
>> 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 <an...@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 <antonovsergey93@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
>> > > <ag...@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 <mm...@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
>> > >
>> >
>> >
>> > --
>> > BR, Sergey Antonov
>> >
>>
>>
>> --
>>
>> Best regards,
>> Alexei Scherbakov
>>
>
>
> --
> BR, Sergey Antonov
>
--
BR, Sergey Antonov
Re: [DISCUSSION] Single point in API for changing cluster state.
Posted by Sergey Antonov <an...@gmail.com>.
Alexei Scherbakov,
> 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.
I'm afraid, we can't guarantee truly read-only mode due to TTL on cache
entries
> 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 ?
User could face the unexpected behaviour, If we always return current state
(target state of transition) or previous state (initial state of
transition). For example, transition from INACTIVE to ACTIVE and we return
current state. User gets cluster state (ACTIVE) and tries to get cache, but
activation has not been completed yet. User will get exception, but cluster
state returns ACTIVE value. So, we can't always return current state.
Another example: transition from ACTIVE to READ_ONLY and we return previous
state. User gets cluster state (ACTIVE) and tries to update value in cache.
User could get ClusterReadOnlyModeException in this case.
So we should return state with lower functionality from previous and
current states for avoiding unexpected behaviour.
чт, 31 окт. 2019 г. в 18:24, Alexei Scherbakov <alexey.scherbakoff@gmail.com
>:
> 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 <an...@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 <an...@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
> > > <ag...@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 <mm...@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
> > >
> >
> >
> > --
> > BR, Sergey Antonov
> >
>
>
> --
>
> Best regards,
> Alexei Scherbakov
>
--
BR, Sergey Antonov
Re: [DISCUSSION] Single point in API for changing cluster state.
Posted by Alexei Scherbakov <al...@gmail.com>.
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 <an...@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 <an...@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
> > <ag...@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 <mm...@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
> >
>
>
> --
> BR, Sergey Antonov
>
--
Best regards,
Alexei Scherbakov
Re: [DISCUSSION] Single point in API for changing cluster state.
Posted by Sergey Antonov <an...@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 <an...@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
> <ag...@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 <an...@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 <mm...@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
>
--
BR, Sergey Antonov
Re: [DISCUSSION] Single point in API for changing cluster state.
Posted by Sergey Antonov <an...@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 <ag...@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 <an...@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 <mm...@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
Re: [DISCUSSION] Single point in API for changing cluster state.
Posted by Alexei Scherbakov <al...@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 <an...@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 <mm...@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 <an...@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
Re: [DISCUSSION] Single point in API for changing cluster state.
Posted by Sergey Antonov <an...@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 <mm...@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 <an...@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
Re: [DISCUSSION] Single point in API for changing cluster state.
Posted by Maxim Muzafarov <mm...@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 <an...@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 <an...@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 <an...@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
Re: [DISCUSSION] Single point in API for changing cluster state.
Posted by Sergey Antonov <an...@gmail.com>.
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 <an...@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 <an...@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
Re: [DISCUSSION] Single point in API for changing cluster state.
Posted by Andrey Mashenkov <an...@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 <an...@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 <an...@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
Re: [DISCUSSION] Single point in API for changing cluster state.
Posted by Sergey Antonov <an...@gmail.com>.
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 <an...@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