He, Igniters!

I'd like to share some points encountered during work on ticket [1]:

   - I added property clusterStateOnStart with type ClusterState to
   IgniteConfiguration. The property will be analogue of activeOnStart.
   Default value of the property will be ACTIVE for keeping defalut value
   consistency. Also I marked property activeOnStart as deprecated.
   - I introduced order on values of ClusterState. It needs for user
   friendly behaviour during cluster state transition. If cluster is changing
   state from state_A to state_B and user is requesting current cluster
   state without waiting end of transition we must return lesser of two
   states: state_A and state_B. I think the order must be: ACTIVE >
   READ_ONLY > INACTIVE. Examples (state_A -> state_B = response on the
   users cluster state request during transition):
      - ACTIVE -> INACTIVE = INACTIVE (Now we have this behavior)
      - INACTIVE -> ACTIVE = INACTIVE (Now we have this behavior)
      - ACTIVE -> READ_ONLY = READ_ONLY
      - READ_ONLY -> ACTIVE = READ_ONLY
      - READ_ONLY -> INACTIVE = INACTIVE
      - INACTIVE -> READ_ONLY = INACTIVE

I'd like to know your opinion about my points. What do you think about it?

[1] https://issues.apache.org/jira/browse/IGNITE-12225


вт, 15 окт. 2019 г. в 14:56, Sergey Antonov <antonovserge...@gmail.com>:

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


-- 
BR, Sergey Antonov

Reply via email to