Re: [DISCUSSION] Single point in API for changing cluster state.

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 : > Alexei Scherbakov, > > > After activation (in read-only mode or not) rebalancing is possible to > begin and the

Re: [DISCUSSION] Single point in API for changing cluster state.

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

Re: [DISCUSSION] Single point in API for changing cluster state.

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.

Re: [DISCUSSION] Single point in API for changing cluster state.

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

Re: [DISCUSSION] Single point in API for changing cluster state.

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

Re: [DISCUSSION] Single point in API for changing cluster state.

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

Re: [DISCUSSION] Single point in API for changing cluster state.

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

Re: [DISCUSSION] Single point in API for changing cluster state.

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

Re: [DISCUSSION] Single point in API for changing cluster state.

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

Re: [DISCUSSION] Single point in API for changing cluster state.

Also, I would add IGNITE-12225 ticket to 2.8 release scope. вт, 24 сент. 2019 г. в 16:18, Sergey Antonov : > Hi, Igniters! > > We have 3 cluster states at the moment: inactive, active, read-only. > > For getting current cluster state and

[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