You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Maxim Muzafarov <ma...@gmail.com> on 2019/06/03 17:14:59 UTC

Re: {DISCUSSION] Cluster read-only mode.

Sergey,

Do we have an IEP for this feature?

What should happen when on an active cluster with put operations if we
receive a read-only state change request? How we guarantee that all
cache operations delivered (or not yet) to backups are not rejected by
applied read-only request? I haven't found such tests in your PR.

I've downloaded your branch and run some tests locally. I've tried
DataStreamer cache loads (allowOverwrite mode false) with a concurrent
cluster change state request to read-only mode and I've got strange
behaviour. My test scenario was:
1) Start DataStremer cache load;
2) change cluster to read-only state;
3) change state back to normal;

When the state has been changed to `read-only` I've flooded with a lot
of `Failed to perform cache operation (cluster is in read-only mode)`
errors, but when I've reverted the state back the DataStreamer
continue its load without any error. I think we should not allow such
behaviour. We should cancel the DataStreamer task or allow it to be
finished.

On Fri, 31 May 2019 at 13:00, Sergey Antonov <an...@gmail.com> wrote:
>
> Hello, Zhenya, Maxim!
>
> Thank you for your replies!
>
> >> Should we also allow writes to the DistributedMetaStorage and if not why?
> Yes. DistributedMetastorage available for updates with enabled read-only
> mode. I added test about it to ClusterReadOnlyModeSelfTest
>
> >> What's the purpose for ignite-sys-cache updates still be available ?
> ignite-sys-cache is using in the different subcomponents, for example,
> security.
>
> чт, 30 мая 2019 г. в 20:30, Zhenya Stanilovsky <ar...@mail.ru.invalid>:
>
> > hi, Sergey.
> > What's the purpose for ignite-sys-cache updates still be available ?
> >
> > thanks !
> >
> > > Hello Igniters!
> > >
> > > I'm working on cluster read-only mode [1] feature. In this mode cluster
> > > will be available only for read operations, all data modification
> > > operations in user caches will be rejected
> > > with ClusterReadOnlyModeCheckedException. This feature could be helpfull
> > > for maintenance works (control.sh idle_verify/validate_indexes).
> > >
> > > A few points about cluster read-only mode:
> > > 1) Read-only mode could be enabled on active cluster only.
> > > 2) Read-only mode doens't store on PDS (i.e. after cluster restart
> > > enabled
> > > read-only mode will be forgotten)
> > > 3) Updates to ignite-sys-cache will be available with enabled read-only
> > > mode.
> > >
> > > More informartion about implementation you could find in PR [2].
> > >
> > > What do you think about this feature?
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-11256
> > > [2] https://github.com/apache/ignite/pull/6423
> >
>
>
> --
> BR, Sergey Antonov

Re: {DISCUSSION] Cluster read-only mode.

Posted by Alexey Kukushkin <ku...@gmail.com>.
I agree with Ivan's concern - do we really need the "activation" concept in
Ignite?

Activation was introduced with Ignite persistence: we must prevent both the
read and write operations on a cluster with persistence on until full data
set is loaded (all the nodes are started). Cluster "activation" was a hint
to the cluster to know that enough nodes had started for the cluster to have
all the data.

Then we introduced the concept of "baseline topology". It looks like the
"cluster is active" is similar to "cluster has baseline topology defined". 

Can we remove the concept of "activation" now and leave only "set baseline
topology" ? Having duplicate concepts negatively impacts Ignite's usability,
making it unnecessary more complex. 



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: {DISCUSSION] Cluster read-only mode.

Posted by Павлухин Иван <vo...@gmail.com>.
Alex and all,

> From a user's point of view:
> Inactive cluster - deny writes, deny reads.
> Read-only cluster - deny writes, allow reads.

I would be great to explain what is the need to deny both reads and
writes. What tasks are not possible to solve when cluster is in
read-only state?

ср, 5 июн. 2019 г. в 11:55, Alex Plehanov <pl...@gmail.com>:
>
> Ivan,
>
> From a user's point of view:
> Inactive cluster - deny writes, deny reads.
> Read-only cluster - deny writes, allow reads.
>
> ср, 5 июн. 2019 г. в 10:44, Павлухин Иван <vo...@gmail.com>:
>
> > Sergey,
> >
> > > On inactive cluster caches aren't started. So you can't get data from
> > cache.
> >
> > As a user I do not understand what does it mean for cache to be
> > started. IgniteCache does not provide start/stop methods.
> >
> > I am trying to figure out why there should be 2 modes (not from an
> > implementation point of view but from a user one). And my concerns are
> > simple. Supporting 2 modes (and 4 combinations) can make more complex
> > both an experience for users and a maintenance for developers.
> >
> > вт, 4 июн. 2019 г. в 16:30, Sergey Antonov <an...@gmail.com>:
> > >
> > > Maxim, thank you for reproducer. It looks like a bug. I will fix it!
> > >
> > > вт, 4 июн. 2019 г. в 15:58, Maxim Muzafarov <ma...@gmail.com>:
> > >
> > > > >> We throw CacheException on each update to read-only cluster. User
> > code
> > > > must handle CacheException correctly .You could find test on it in
> > > > ClusterReadOnlyModeTest#testDataStreamerReadOnly()
> > > >
> > > > In this test, DataStreamer starts when the cluster already changes its
> > > > mode, but not before. Please, check my reproducer [1]. CacheException
> > > > is not thrown. Am I missing something?
> > > >
> > > > [1]
> > > >
> > https://github.com/Mmuzaf/ignite/blob/readonly_streamer/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/ClusterReadOnlyModeTest.java#L72
> > > >
> > > > On Tue, 4 Jun 2019 at 14:42, Sergey Antonov <antonovsergey93@gmail.com
> > >
> > > > wrote:
> > > > >
> > > > > Hello, Maxim!
> > > > >
> > > > > >> Do we have an IEP for this feature?
> > > > > No, we don't have.
> > > > >
> > > > > >> How we guarantee that all cache operations delivered (or not yet)
> > to
> > > > > backups are not rejected by applied read-only request?
> > > > > I reused cluster activation mechanism. So enabling read-only mode
> > > > generates
> > > > > an exchange on cluster. Cluster exchange guarantees update
> > consistency
> > > > > between primary and backups.
> > > > >
> > > > > >> We should cancel the DataStreamer task or allow it to be finished.
> > > > > We throw CacheException on each update to read-only cluster. User
> > code
> > > > must
> > > > > handle CacheException correctly .You could find test on it in
> > > > > ClusterReadOnlyModeTest#testDataStreamerReadOnly()
> > > > >
> > > > > пн, 3 июн. 2019 г. в 20:15, Maxim Muzafarov <ma...@gmail.com>:
> > > > >
> > > > > > Sergey,
> > > > > >
> > > > > > Do we have an IEP for this feature?
> > > > > >
> > > > > > What should happen when on an active cluster with put operations
> > if we
> > > > > > receive a read-only state change request? How we guarantee that all
> > > > > > cache operations delivered (or not yet) to backups are not
> > rejected by
> > > > > > applied read-only request? I haven't found such tests in your PR.
> > > > > >
> > > > > > I've downloaded your branch and run some tests locally. I've tried
> > > > > > DataStreamer cache loads (allowOverwrite mode false) with a
> > concurrent
> > > > > > cluster change state request to read-only mode and I've got strange
> > > > > > behaviour. My test scenario was:
> > > > > > 1) Start DataStremer cache load;
> > > > > > 2) change cluster to read-only state;
> > > > > > 3) change state back to normal;
> > > > > >
> > > > > > When the state has been changed to `read-only` I've flooded with a
> > lot
> > > > > > of `Failed to perform cache operation (cluster is in read-only
> > mode)`
> > > > > > errors, but when I've reverted the state back the DataStreamer
> > > > > > continue its load without any error. I think we should not allow
> > such
> > > > > > behaviour. We should cancel the DataStreamer task or allow it to be
> > > > > > finished.
> > > > > >
> > > > > > On Fri, 31 May 2019 at 13:00, Sergey Antonov <
> > > > antonovsergey93@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > Hello, Zhenya, Maxim!
> > > > > > >
> > > > > > > Thank you for your replies!
> > > > > > >
> > > > > > > >> Should we also allow writes to the DistributedMetaStorage and
> > if
> > > > not
> > > > > > why?
> > > > > > > Yes. DistributedMetastorage available for updates with enabled
> > > > read-only
> > > > > > > mode. I added test about it to ClusterReadOnlyModeSelfTest
> > > > > > >
> > > > > > > >> What's the purpose for ignite-sys-cache updates still be
> > > > available ?
> > > > > > > ignite-sys-cache is using in the different subcomponents, for
> > > > example,
> > > > > > > security.
> > > > > > >
> > > > > > > чт, 30 мая 2019 г. в 20:30, Zhenya Stanilovsky
> > > > > > <ar...@mail.ru.invalid>:
> > > > > > >
> > > > > > > > hi, Sergey.
> > > > > > > > What's the purpose for ignite-sys-cache updates still be
> > available
> > > > ?
> > > > > > > >
> > > > > > > > thanks !
> > > > > > > >
> > > > > > > > > Hello Igniters!
> > > > > > > > >
> > > > > > > > > I'm working on cluster read-only mode [1] feature. In this
> > mode
> > > > > > cluster
> > > > > > > > > will be available only for read operations, all data
> > modification
> > > > > > > > > operations in user caches will be rejected
> > > > > > > > > with ClusterReadOnlyModeCheckedException. This feature could
> > be
> > > > > > helpfull
> > > > > > > > > for maintenance works (control.sh
> > idle_verify/validate_indexes).
> > > > > > > > >
> > > > > > > > > A few points about cluster read-only mode:
> > > > > > > > > 1) Read-only mode could be enabled on active cluster only.
> > > > > > > > > 2) Read-only mode doens't store on PDS (i.e. after cluster
> > > > restart
> > > > > > > > > enabled
> > > > > > > > > read-only mode will be forgotten)
> > > > > > > > > 3) Updates to ignite-sys-cache will be available with enabled
> > > > > > read-only
> > > > > > > > > mode.
> > > > > > > > >
> > > > > > > > > More informartion about implementation you could find in PR
> > [2].
> > > > > > > > >
> > > > > > > > > What do you think about this feature?
> > > > > > > > >
> > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11256
> > > > > > > > > [2] https://github.com/apache/ignite/pull/6423
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > BR, Sergey Antonov
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > BR, Sergey Antonov
> > > >
> > >
> > >
> > > --
> > > BR, Sergey Antonov
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
> >



-- 
Best regards,
Ivan Pavlukhin

Re: {DISCUSSION] Cluster read-only mode.

Posted by Alex Plehanov <pl...@gmail.com>.
Ivan,

From a user's point of view:
Inactive cluster - deny writes, deny reads.
Read-only cluster - deny writes, allow reads.

ср, 5 июн. 2019 г. в 10:44, Павлухин Иван <vo...@gmail.com>:

> Sergey,
>
> > On inactive cluster caches aren't started. So you can't get data from
> cache.
>
> As a user I do not understand what does it mean for cache to be
> started. IgniteCache does not provide start/stop methods.
>
> I am trying to figure out why there should be 2 modes (not from an
> implementation point of view but from a user one). And my concerns are
> simple. Supporting 2 modes (and 4 combinations) can make more complex
> both an experience for users and a maintenance for developers.
>
> вт, 4 июн. 2019 г. в 16:30, Sergey Antonov <an...@gmail.com>:
> >
> > Maxim, thank you for reproducer. It looks like a bug. I will fix it!
> >
> > вт, 4 июн. 2019 г. в 15:58, Maxim Muzafarov <ma...@gmail.com>:
> >
> > > >> We throw CacheException on each update to read-only cluster. User
> code
> > > must handle CacheException correctly .You could find test on it in
> > > ClusterReadOnlyModeTest#testDataStreamerReadOnly()
> > >
> > > In this test, DataStreamer starts when the cluster already changes its
> > > mode, but not before. Please, check my reproducer [1]. CacheException
> > > is not thrown. Am I missing something?
> > >
> > > [1]
> > >
> https://github.com/Mmuzaf/ignite/blob/readonly_streamer/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/ClusterReadOnlyModeTest.java#L72
> > >
> > > On Tue, 4 Jun 2019 at 14:42, Sergey Antonov <antonovsergey93@gmail.com
> >
> > > wrote:
> > > >
> > > > Hello, Maxim!
> > > >
> > > > >> Do we have an IEP for this feature?
> > > > No, we don't have.
> > > >
> > > > >> How we guarantee that all cache operations delivered (or not yet)
> to
> > > > backups are not rejected by applied read-only request?
> > > > I reused cluster activation mechanism. So enabling read-only mode
> > > generates
> > > > an exchange on cluster. Cluster exchange guarantees update
> consistency
> > > > between primary and backups.
> > > >
> > > > >> We should cancel the DataStreamer task or allow it to be finished.
> > > > We throw CacheException on each update to read-only cluster. User
> code
> > > must
> > > > handle CacheException correctly .You could find test on it in
> > > > ClusterReadOnlyModeTest#testDataStreamerReadOnly()
> > > >
> > > > пн, 3 июн. 2019 г. в 20:15, Maxim Muzafarov <ma...@gmail.com>:
> > > >
> > > > > Sergey,
> > > > >
> > > > > Do we have an IEP for this feature?
> > > > >
> > > > > What should happen when on an active cluster with put operations
> if we
> > > > > receive a read-only state change request? How we guarantee that all
> > > > > cache operations delivered (or not yet) to backups are not
> rejected by
> > > > > applied read-only request? I haven't found such tests in your PR.
> > > > >
> > > > > I've downloaded your branch and run some tests locally. I've tried
> > > > > DataStreamer cache loads (allowOverwrite mode false) with a
> concurrent
> > > > > cluster change state request to read-only mode and I've got strange
> > > > > behaviour. My test scenario was:
> > > > > 1) Start DataStremer cache load;
> > > > > 2) change cluster to read-only state;
> > > > > 3) change state back to normal;
> > > > >
> > > > > When the state has been changed to `read-only` I've flooded with a
> lot
> > > > > of `Failed to perform cache operation (cluster is in read-only
> mode)`
> > > > > errors, but when I've reverted the state back the DataStreamer
> > > > > continue its load without any error. I think we should not allow
> such
> > > > > behaviour. We should cancel the DataStreamer task or allow it to be
> > > > > finished.
> > > > >
> > > > > On Fri, 31 May 2019 at 13:00, Sergey Antonov <
> > > antonovsergey93@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > Hello, Zhenya, Maxim!
> > > > > >
> > > > > > Thank you for your replies!
> > > > > >
> > > > > > >> Should we also allow writes to the DistributedMetaStorage and
> if
> > > not
> > > > > why?
> > > > > > Yes. DistributedMetastorage available for updates with enabled
> > > read-only
> > > > > > mode. I added test about it to ClusterReadOnlyModeSelfTest
> > > > > >
> > > > > > >> What's the purpose for ignite-sys-cache updates still be
> > > available ?
> > > > > > ignite-sys-cache is using in the different subcomponents, for
> > > example,
> > > > > > security.
> > > > > >
> > > > > > чт, 30 мая 2019 г. в 20:30, Zhenya Stanilovsky
> > > > > <ar...@mail.ru.invalid>:
> > > > > >
> > > > > > > hi, Sergey.
> > > > > > > What's the purpose for ignite-sys-cache updates still be
> available
> > > ?
> > > > > > >
> > > > > > > thanks !
> > > > > > >
> > > > > > > > Hello Igniters!
> > > > > > > >
> > > > > > > > I'm working on cluster read-only mode [1] feature. In this
> mode
> > > > > cluster
> > > > > > > > will be available only for read operations, all data
> modification
> > > > > > > > operations in user caches will be rejected
> > > > > > > > with ClusterReadOnlyModeCheckedException. This feature could
> be
> > > > > helpfull
> > > > > > > > for maintenance works (control.sh
> idle_verify/validate_indexes).
> > > > > > > >
> > > > > > > > A few points about cluster read-only mode:
> > > > > > > > 1) Read-only mode could be enabled on active cluster only.
> > > > > > > > 2) Read-only mode doens't store on PDS (i.e. after cluster
> > > restart
> > > > > > > > enabled
> > > > > > > > read-only mode will be forgotten)
> > > > > > > > 3) Updates to ignite-sys-cache will be available with enabled
> > > > > read-only
> > > > > > > > mode.
> > > > > > > >
> > > > > > > > More informartion about implementation you could find in PR
> [2].
> > > > > > > >
> > > > > > > > What do you think about this feature?
> > > > > > > >
> > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11256
> > > > > > > > [2] https://github.com/apache/ignite/pull/6423
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > BR, Sergey Antonov
> > > > >
> > > >
> > > >
> > > > --
> > > > BR, Sergey Antonov
> > >
> >
> >
> > --
> > BR, Sergey Antonov
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>

Re: {DISCUSSION] Cluster read-only mode.

Posted by Павлухин Иван <vo...@gmail.com>.
Sergey,

> On inactive cluster caches aren't started. So you can't get data from
cache.

As a user I do not understand what does it mean for cache to be
started. IgniteCache does not provide start/stop methods.

I am trying to figure out why there should be 2 modes (not from an
implementation point of view but from a user one). And my concerns are
simple. Supporting 2 modes (and 4 combinations) can make more complex
both an experience for users and a maintenance for developers.

вт, 4 июн. 2019 г. в 16:30, Sergey Antonov <an...@gmail.com>:
>
> Maxim, thank you for reproducer. It looks like a bug. I will fix it!
>
> вт, 4 июн. 2019 г. в 15:58, Maxim Muzafarov <ma...@gmail.com>:
>
> > >> We throw CacheException on each update to read-only cluster. User code
> > must handle CacheException correctly .You could find test on it in
> > ClusterReadOnlyModeTest#testDataStreamerReadOnly()
> >
> > In this test, DataStreamer starts when the cluster already changes its
> > mode, but not before. Please, check my reproducer [1]. CacheException
> > is not thrown. Am I missing something?
> >
> > [1]
> > https://github.com/Mmuzaf/ignite/blob/readonly_streamer/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/ClusterReadOnlyModeTest.java#L72
> >
> > On Tue, 4 Jun 2019 at 14:42, Sergey Antonov <an...@gmail.com>
> > wrote:
> > >
> > > Hello, Maxim!
> > >
> > > >> Do we have an IEP for this feature?
> > > No, we don't have.
> > >
> > > >> How we guarantee that all cache operations delivered (or not yet) to
> > > backups are not rejected by applied read-only request?
> > > I reused cluster activation mechanism. So enabling read-only mode
> > generates
> > > an exchange on cluster. Cluster exchange guarantees update consistency
> > > between primary and backups.
> > >
> > > >> We should cancel the DataStreamer task or allow it to be finished.
> > > We throw CacheException on each update to read-only cluster. User code
> > must
> > > handle CacheException correctly .You could find test on it in
> > > ClusterReadOnlyModeTest#testDataStreamerReadOnly()
> > >
> > > пн, 3 июн. 2019 г. в 20:15, Maxim Muzafarov <ma...@gmail.com>:
> > >
> > > > Sergey,
> > > >
> > > > Do we have an IEP for this feature?
> > > >
> > > > What should happen when on an active cluster with put operations if we
> > > > receive a read-only state change request? How we guarantee that all
> > > > cache operations delivered (or not yet) to backups are not rejected by
> > > > applied read-only request? I haven't found such tests in your PR.
> > > >
> > > > I've downloaded your branch and run some tests locally. I've tried
> > > > DataStreamer cache loads (allowOverwrite mode false) with a concurrent
> > > > cluster change state request to read-only mode and I've got strange
> > > > behaviour. My test scenario was:
> > > > 1) Start DataStremer cache load;
> > > > 2) change cluster to read-only state;
> > > > 3) change state back to normal;
> > > >
> > > > When the state has been changed to `read-only` I've flooded with a lot
> > > > of `Failed to perform cache operation (cluster is in read-only mode)`
> > > > errors, but when I've reverted the state back the DataStreamer
> > > > continue its load without any error. I think we should not allow such
> > > > behaviour. We should cancel the DataStreamer task or allow it to be
> > > > finished.
> > > >
> > > > On Fri, 31 May 2019 at 13:00, Sergey Antonov <
> > antonovsergey93@gmail.com>
> > > > wrote:
> > > > >
> > > > > Hello, Zhenya, Maxim!
> > > > >
> > > > > Thank you for your replies!
> > > > >
> > > > > >> Should we also allow writes to the DistributedMetaStorage and if
> > not
> > > > why?
> > > > > Yes. DistributedMetastorage available for updates with enabled
> > read-only
> > > > > mode. I added test about it to ClusterReadOnlyModeSelfTest
> > > > >
> > > > > >> What's the purpose for ignite-sys-cache updates still be
> > available ?
> > > > > ignite-sys-cache is using in the different subcomponents, for
> > example,
> > > > > security.
> > > > >
> > > > > чт, 30 мая 2019 г. в 20:30, Zhenya Stanilovsky
> > > > <ar...@mail.ru.invalid>:
> > > > >
> > > > > > hi, Sergey.
> > > > > > What's the purpose for ignite-sys-cache updates still be available
> > ?
> > > > > >
> > > > > > thanks !
> > > > > >
> > > > > > > Hello Igniters!
> > > > > > >
> > > > > > > I'm working on cluster read-only mode [1] feature. In this mode
> > > > cluster
> > > > > > > will be available only for read operations, all data modification
> > > > > > > operations in user caches will be rejected
> > > > > > > with ClusterReadOnlyModeCheckedException. This feature could be
> > > > helpfull
> > > > > > > for maintenance works (control.sh idle_verify/validate_indexes).
> > > > > > >
> > > > > > > A few points about cluster read-only mode:
> > > > > > > 1) Read-only mode could be enabled on active cluster only.
> > > > > > > 2) Read-only mode doens't store on PDS (i.e. after cluster
> > restart
> > > > > > > enabled
> > > > > > > read-only mode will be forgotten)
> > > > > > > 3) Updates to ignite-sys-cache will be available with enabled
> > > > read-only
> > > > > > > mode.
> > > > > > >
> > > > > > > More informartion about implementation you could find in PR [2].
> > > > > > >
> > > > > > > What do you think about this feature?
> > > > > > >
> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11256
> > > > > > > [2] https://github.com/apache/ignite/pull/6423
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > BR, Sergey Antonov
> > > >
> > >
> > >
> > > --
> > > BR, Sergey Antonov
> >
>
>
> --
> BR, Sergey Antonov



-- 
Best regards,
Ivan Pavlukhin

Re: {DISCUSSION] Cluster read-only mode.

Posted by Sergey Antonov <an...@gmail.com>.
Maxim, thank you for reproducer. It looks like a bug. I will fix it!

вт, 4 июн. 2019 г. в 15:58, Maxim Muzafarov <ma...@gmail.com>:

> >> We throw CacheException on each update to read-only cluster. User code
> must handle CacheException correctly .You could find test on it in
> ClusterReadOnlyModeTest#testDataStreamerReadOnly()
>
> In this test, DataStreamer starts when the cluster already changes its
> mode, but not before. Please, check my reproducer [1]. CacheException
> is not thrown. Am I missing something?
>
> [1]
> https://github.com/Mmuzaf/ignite/blob/readonly_streamer/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/ClusterReadOnlyModeTest.java#L72
>
> On Tue, 4 Jun 2019 at 14:42, Sergey Antonov <an...@gmail.com>
> wrote:
> >
> > Hello, Maxim!
> >
> > >> Do we have an IEP for this feature?
> > No, we don't have.
> >
> > >> How we guarantee that all cache operations delivered (or not yet) to
> > backups are not rejected by applied read-only request?
> > I reused cluster activation mechanism. So enabling read-only mode
> generates
> > an exchange on cluster. Cluster exchange guarantees update consistency
> > between primary and backups.
> >
> > >> We should cancel the DataStreamer task or allow it to be finished.
> > We throw CacheException on each update to read-only cluster. User code
> must
> > handle CacheException correctly .You could find test on it in
> > ClusterReadOnlyModeTest#testDataStreamerReadOnly()
> >
> > пн, 3 июн. 2019 г. в 20:15, Maxim Muzafarov <ma...@gmail.com>:
> >
> > > Sergey,
> > >
> > > Do we have an IEP for this feature?
> > >
> > > What should happen when on an active cluster with put operations if we
> > > receive a read-only state change request? How we guarantee that all
> > > cache operations delivered (or not yet) to backups are not rejected by
> > > applied read-only request? I haven't found such tests in your PR.
> > >
> > > I've downloaded your branch and run some tests locally. I've tried
> > > DataStreamer cache loads (allowOverwrite mode false) with a concurrent
> > > cluster change state request to read-only mode and I've got strange
> > > behaviour. My test scenario was:
> > > 1) Start DataStremer cache load;
> > > 2) change cluster to read-only state;
> > > 3) change state back to normal;
> > >
> > > When the state has been changed to `read-only` I've flooded with a lot
> > > of `Failed to perform cache operation (cluster is in read-only mode)`
> > > errors, but when I've reverted the state back the DataStreamer
> > > continue its load without any error. I think we should not allow such
> > > behaviour. We should cancel the DataStreamer task or allow it to be
> > > finished.
> > >
> > > On Fri, 31 May 2019 at 13:00, Sergey Antonov <
> antonovsergey93@gmail.com>
> > > wrote:
> > > >
> > > > Hello, Zhenya, Maxim!
> > > >
> > > > Thank you for your replies!
> > > >
> > > > >> Should we also allow writes to the DistributedMetaStorage and if
> not
> > > why?
> > > > Yes. DistributedMetastorage available for updates with enabled
> read-only
> > > > mode. I added test about it to ClusterReadOnlyModeSelfTest
> > > >
> > > > >> What's the purpose for ignite-sys-cache updates still be
> available ?
> > > > ignite-sys-cache is using in the different subcomponents, for
> example,
> > > > security.
> > > >
> > > > чт, 30 мая 2019 г. в 20:30, Zhenya Stanilovsky
> > > <ar...@mail.ru.invalid>:
> > > >
> > > > > hi, Sergey.
> > > > > What's the purpose for ignite-sys-cache updates still be available
> ?
> > > > >
> > > > > thanks !
> > > > >
> > > > > > Hello Igniters!
> > > > > >
> > > > > > I'm working on cluster read-only mode [1] feature. In this mode
> > > cluster
> > > > > > will be available only for read operations, all data modification
> > > > > > operations in user caches will be rejected
> > > > > > with ClusterReadOnlyModeCheckedException. This feature could be
> > > helpfull
> > > > > > for maintenance works (control.sh idle_verify/validate_indexes).
> > > > > >
> > > > > > A few points about cluster read-only mode:
> > > > > > 1) Read-only mode could be enabled on active cluster only.
> > > > > > 2) Read-only mode doens't store on PDS (i.e. after cluster
> restart
> > > > > > enabled
> > > > > > read-only mode will be forgotten)
> > > > > > 3) Updates to ignite-sys-cache will be available with enabled
> > > read-only
> > > > > > mode.
> > > > > >
> > > > > > More informartion about implementation you could find in PR [2].
> > > > > >
> > > > > > What do you think about this feature?
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11256
> > > > > > [2] https://github.com/apache/ignite/pull/6423
> > > > >
> > > >
> > > >
> > > > --
> > > > BR, Sergey Antonov
> > >
> >
> >
> > --
> > BR, Sergey Antonov
>


-- 
BR, Sergey Antonov

Re: {DISCUSSION] Cluster read-only mode.

Posted by Sergey Antonov <an...@gmail.com>.
Maxim, I fixed issue, which you found above. Look
at org.apache.ignite.internal.processors.cache.ClusterReadOnlyModeTest#testDataStreamerReadOnlyConcurrent*
tests.

вт, 4 июн. 2019 г. в 15:58, Maxim Muzafarov <ma...@gmail.com>:

> >> We throw CacheException on each update to read-only cluster. User code
> must handle CacheException correctly .You could find test on it in
> ClusterReadOnlyModeTest#testDataStreamerReadOnly()
>
> In this test, DataStreamer starts when the cluster already changes its
> mode, but not before. Please, check my reproducer [1]. CacheException
> is not thrown. Am I missing something?
>
> [1]
> https://github.com/Mmuzaf/ignite/blob/readonly_streamer/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/ClusterReadOnlyModeTest.java#L72
>
> On Tue, 4 Jun 2019 at 14:42, Sergey Antonov <an...@gmail.com>
> wrote:
> >
> > Hello, Maxim!
> >
> > >> Do we have an IEP for this feature?
> > No, we don't have.
> >
> > >> How we guarantee that all cache operations delivered (or not yet) to
> > backups are not rejected by applied read-only request?
> > I reused cluster activation mechanism. So enabling read-only mode
> generates
> > an exchange on cluster. Cluster exchange guarantees update consistency
> > between primary and backups.
> >
> > >> We should cancel the DataStreamer task or allow it to be finished.
> > We throw CacheException on each update to read-only cluster. User code
> must
> > handle CacheException correctly .You could find test on it in
> > ClusterReadOnlyModeTest#testDataStreamerReadOnly()
> >
> > пн, 3 июн. 2019 г. в 20:15, Maxim Muzafarov <ma...@gmail.com>:
> >
> > > Sergey,
> > >
> > > Do we have an IEP for this feature?
> > >
> > > What should happen when on an active cluster with put operations if we
> > > receive a read-only state change request? How we guarantee that all
> > > cache operations delivered (or not yet) to backups are not rejected by
> > > applied read-only request? I haven't found such tests in your PR.
> > >
> > > I've downloaded your branch and run some tests locally. I've tried
> > > DataStreamer cache loads (allowOverwrite mode false) with a concurrent
> > > cluster change state request to read-only mode and I've got strange
> > > behaviour. My test scenario was:
> > > 1) Start DataStremer cache load;
> > > 2) change cluster to read-only state;
> > > 3) change state back to normal;
> > >
> > > When the state has been changed to `read-only` I've flooded with a lot
> > > of `Failed to perform cache operation (cluster is in read-only mode)`
> > > errors, but when I've reverted the state back the DataStreamer
> > > continue its load without any error. I think we should not allow such
> > > behaviour. We should cancel the DataStreamer task or allow it to be
> > > finished.
> > >
> > > On Fri, 31 May 2019 at 13:00, Sergey Antonov <
> antonovsergey93@gmail.com>
> > > wrote:
> > > >
> > > > Hello, Zhenya, Maxim!
> > > >
> > > > Thank you for your replies!
> > > >
> > > > >> Should we also allow writes to the DistributedMetaStorage and if
> not
> > > why?
> > > > Yes. DistributedMetastorage available for updates with enabled
> read-only
> > > > mode. I added test about it to ClusterReadOnlyModeSelfTest
> > > >
> > > > >> What's the purpose for ignite-sys-cache updates still be
> available ?
> > > > ignite-sys-cache is using in the different subcomponents, for
> example,
> > > > security.
> > > >
> > > > чт, 30 мая 2019 г. в 20:30, Zhenya Stanilovsky
> > > <ar...@mail.ru.invalid>:
> > > >
> > > > > hi, Sergey.
> > > > > What's the purpose for ignite-sys-cache updates still be available
> ?
> > > > >
> > > > > thanks !
> > > > >
> > > > > > Hello Igniters!
> > > > > >
> > > > > > I'm working on cluster read-only mode [1] feature. In this mode
> > > cluster
> > > > > > will be available only for read operations, all data modification
> > > > > > operations in user caches will be rejected
> > > > > > with ClusterReadOnlyModeCheckedException. This feature could be
> > > helpfull
> > > > > > for maintenance works (control.sh idle_verify/validate_indexes).
> > > > > >
> > > > > > A few points about cluster read-only mode:
> > > > > > 1) Read-only mode could be enabled on active cluster only.
> > > > > > 2) Read-only mode doens't store on PDS (i.e. after cluster
> restart
> > > > > > enabled
> > > > > > read-only mode will be forgotten)
> > > > > > 3) Updates to ignite-sys-cache will be available with enabled
> > > read-only
> > > > > > mode.
> > > > > >
> > > > > > More informartion about implementation you could find in PR [2].
> > > > > >
> > > > > > What do you think about this feature?
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11256
> > > > > > [2] https://github.com/apache/ignite/pull/6423
> > > > >
> > > >
> > > >
> > > > --
> > > > BR, Sergey Antonov
> > >
> >
> >
> > --
> > BR, Sergey Antonov
>


-- 
BR, Sergey Antonov

Re: {DISCUSSION] Cluster read-only mode.

Posted by Maxim Muzafarov <ma...@gmail.com>.
>> We throw CacheException on each update to read-only cluster. User code must handle CacheException correctly .You could find test on it in ClusterReadOnlyModeTest#testDataStreamerReadOnly()

In this test, DataStreamer starts when the cluster already changes its
mode, but not before. Please, check my reproducer [1]. CacheException
is not thrown. Am I missing something?

[1] https://github.com/Mmuzaf/ignite/blob/readonly_streamer/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/ClusterReadOnlyModeTest.java#L72

On Tue, 4 Jun 2019 at 14:42, Sergey Antonov <an...@gmail.com> wrote:
>
> Hello, Maxim!
>
> >> Do we have an IEP for this feature?
> No, we don't have.
>
> >> How we guarantee that all cache operations delivered (or not yet) to
> backups are not rejected by applied read-only request?
> I reused cluster activation mechanism. So enabling read-only mode generates
> an exchange on cluster. Cluster exchange guarantees update consistency
> between primary and backups.
>
> >> We should cancel the DataStreamer task or allow it to be finished.
> We throw CacheException on each update to read-only cluster. User code must
> handle CacheException correctly .You could find test on it in
> ClusterReadOnlyModeTest#testDataStreamerReadOnly()
>
> пн, 3 июн. 2019 г. в 20:15, Maxim Muzafarov <ma...@gmail.com>:
>
> > Sergey,
> >
> > Do we have an IEP for this feature?
> >
> > What should happen when on an active cluster with put operations if we
> > receive a read-only state change request? How we guarantee that all
> > cache operations delivered (or not yet) to backups are not rejected by
> > applied read-only request? I haven't found such tests in your PR.
> >
> > I've downloaded your branch and run some tests locally. I've tried
> > DataStreamer cache loads (allowOverwrite mode false) with a concurrent
> > cluster change state request to read-only mode and I've got strange
> > behaviour. My test scenario was:
> > 1) Start DataStremer cache load;
> > 2) change cluster to read-only state;
> > 3) change state back to normal;
> >
> > When the state has been changed to `read-only` I've flooded with a lot
> > of `Failed to perform cache operation (cluster is in read-only mode)`
> > errors, but when I've reverted the state back the DataStreamer
> > continue its load without any error. I think we should not allow such
> > behaviour. We should cancel the DataStreamer task or allow it to be
> > finished.
> >
> > On Fri, 31 May 2019 at 13:00, Sergey Antonov <an...@gmail.com>
> > wrote:
> > >
> > > Hello, Zhenya, Maxim!
> > >
> > > Thank you for your replies!
> > >
> > > >> Should we also allow writes to the DistributedMetaStorage and if not
> > why?
> > > Yes. DistributedMetastorage available for updates with enabled read-only
> > > mode. I added test about it to ClusterReadOnlyModeSelfTest
> > >
> > > >> What's the purpose for ignite-sys-cache updates still be available ?
> > > ignite-sys-cache is using in the different subcomponents, for example,
> > > security.
> > >
> > > чт, 30 мая 2019 г. в 20:30, Zhenya Stanilovsky
> > <ar...@mail.ru.invalid>:
> > >
> > > > hi, Sergey.
> > > > What's the purpose for ignite-sys-cache updates still be available ?
> > > >
> > > > thanks !
> > > >
> > > > > Hello Igniters!
> > > > >
> > > > > I'm working on cluster read-only mode [1] feature. In this mode
> > cluster
> > > > > will be available only for read operations, all data modification
> > > > > operations in user caches will be rejected
> > > > > with ClusterReadOnlyModeCheckedException. This feature could be
> > helpfull
> > > > > for maintenance works (control.sh idle_verify/validate_indexes).
> > > > >
> > > > > A few points about cluster read-only mode:
> > > > > 1) Read-only mode could be enabled on active cluster only.
> > > > > 2) Read-only mode doens't store on PDS (i.e. after cluster restart
> > > > > enabled
> > > > > read-only mode will be forgotten)
> > > > > 3) Updates to ignite-sys-cache will be available with enabled
> > read-only
> > > > > mode.
> > > > >
> > > > > More informartion about implementation you could find in PR [2].
> > > > >
> > > > > What do you think about this feature?
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11256
> > > > > [2] https://github.com/apache/ignite/pull/6423
> > > >
> > >
> > >
> > > --
> > > BR, Sergey Antonov
> >
>
>
> --
> BR, Sergey Antonov

Re: {DISCUSSION] Cluster read-only mode.

Posted by Sergey Antonov <an...@gmail.com>.
Hello, Maxim!

>> Do we have an IEP for this feature?
No, we don't have.

>> How we guarantee that all cache operations delivered (or not yet) to
backups are not rejected by applied read-only request?
I reused cluster activation mechanism. So enabling read-only mode generates
an exchange on cluster. Cluster exchange guarantees update consistency
between primary and backups.

>> We should cancel the DataStreamer task or allow it to be finished.
We throw CacheException on each update to read-only cluster. User code must
handle CacheException correctly .You could find test on it in
ClusterReadOnlyModeTest#testDataStreamerReadOnly()

пн, 3 июн. 2019 г. в 20:15, Maxim Muzafarov <ma...@gmail.com>:

> Sergey,
>
> Do we have an IEP for this feature?
>
> What should happen when on an active cluster with put operations if we
> receive a read-only state change request? How we guarantee that all
> cache operations delivered (or not yet) to backups are not rejected by
> applied read-only request? I haven't found such tests in your PR.
>
> I've downloaded your branch and run some tests locally. I've tried
> DataStreamer cache loads (allowOverwrite mode false) with a concurrent
> cluster change state request to read-only mode and I've got strange
> behaviour. My test scenario was:
> 1) Start DataStremer cache load;
> 2) change cluster to read-only state;
> 3) change state back to normal;
>
> When the state has been changed to `read-only` I've flooded with a lot
> of `Failed to perform cache operation (cluster is in read-only mode)`
> errors, but when I've reverted the state back the DataStreamer
> continue its load without any error. I think we should not allow such
> behaviour. We should cancel the DataStreamer task or allow it to be
> finished.
>
> On Fri, 31 May 2019 at 13:00, Sergey Antonov <an...@gmail.com>
> wrote:
> >
> > Hello, Zhenya, Maxim!
> >
> > Thank you for your replies!
> >
> > >> Should we also allow writes to the DistributedMetaStorage and if not
> why?
> > Yes. DistributedMetastorage available for updates with enabled read-only
> > mode. I added test about it to ClusterReadOnlyModeSelfTest
> >
> > >> What's the purpose for ignite-sys-cache updates still be available ?
> > ignite-sys-cache is using in the different subcomponents, for example,
> > security.
> >
> > чт, 30 мая 2019 г. в 20:30, Zhenya Stanilovsky
> <ar...@mail.ru.invalid>:
> >
> > > hi, Sergey.
> > > What's the purpose for ignite-sys-cache updates still be available ?
> > >
> > > thanks !
> > >
> > > > Hello Igniters!
> > > >
> > > > I'm working on cluster read-only mode [1] feature. In this mode
> cluster
> > > > will be available only for read operations, all data modification
> > > > operations in user caches will be rejected
> > > > with ClusterReadOnlyModeCheckedException. This feature could be
> helpfull
> > > > for maintenance works (control.sh idle_verify/validate_indexes).
> > > >
> > > > A few points about cluster read-only mode:
> > > > 1) Read-only mode could be enabled on active cluster only.
> > > > 2) Read-only mode doens't store on PDS (i.e. after cluster restart
> > > > enabled
> > > > read-only mode will be forgotten)
> > > > 3) Updates to ignite-sys-cache will be available with enabled
> read-only
> > > > mode.
> > > >
> > > > More informartion about implementation you could find in PR [2].
> > > >
> > > > What do you think about this feature?
> > > >
> > > > [1] https://issues.apache.org/jira/browse/IGNITE-11256
> > > > [2] https://github.com/apache/ignite/pull/6423
> > >
> >
> >
> > --
> > BR, Sergey Antonov
>


-- 
BR, Sergey Antonov

Re: {DISCUSSION] Cluster read-only mode.

Posted by Sergey Antonov <an...@gmail.com>.
Hello, Ivan.

>>What is a fundamental difference between them?
On inactive cluster caches aren't started. So you can't get data from
cache.

вт, 4 июн. 2019 г. в 12:16, Павлухин Иван <vo...@gmail.com>:

> Sergey, Igniters,
>
> Sorry if my question is not very smart.
>
> I am trying to think about it from a perspective of a (newbie) user.
> And from the first glance it is not clear how a read-only cluster is
> different from a not active cluster? What is a fundamental difference
> between them? Can we combine two modes into one? If not we will need a
> clear explanation for a user.
>
> пн, 3 июн. 2019 г. в 20:15, Maxim Muzafarov <ma...@gmail.com>:
> >
> > Sergey,
> >
> > Do we have an IEP for this feature?
> >
> > What should happen when on an active cluster with put operations if we
> > receive a read-only state change request? How we guarantee that all
> > cache operations delivered (or not yet) to backups are not rejected by
> > applied read-only request? I haven't found such tests in your PR.
> >
> > I've downloaded your branch and run some tests locally. I've tried
> > DataStreamer cache loads (allowOverwrite mode false) with a concurrent
> > cluster change state request to read-only mode and I've got strange
> > behaviour. My test scenario was:
> > 1) Start DataStremer cache load;
> > 2) change cluster to read-only state;
> > 3) change state back to normal;
> >
> > When the state has been changed to `read-only` I've flooded with a lot
> > of `Failed to perform cache operation (cluster is in read-only mode)`
> > errors, but when I've reverted the state back the DataStreamer
> > continue its load without any error. I think we should not allow such
> > behaviour. We should cancel the DataStreamer task or allow it to be
> > finished.
> >
> > On Fri, 31 May 2019 at 13:00, Sergey Antonov <an...@gmail.com>
> wrote:
> > >
> > > Hello, Zhenya, Maxim!
> > >
> > > Thank you for your replies!
> > >
> > > >> Should we also allow writes to the DistributedMetaStorage and if
> not why?
> > > Yes. DistributedMetastorage available for updates with enabled
> read-only
> > > mode. I added test about it to ClusterReadOnlyModeSelfTest
> > >
> > > >> What's the purpose for ignite-sys-cache updates still be available ?
> > > ignite-sys-cache is using in the different subcomponents, for example,
> > > security.
> > >
> > > чт, 30 мая 2019 г. в 20:30, Zhenya Stanilovsky
> <ar...@mail.ru.invalid>:
> > >
> > > > hi, Sergey.
> > > > What's the purpose for ignite-sys-cache updates still be available ?
> > > >
> > > > thanks !
> > > >
> > > > > Hello Igniters!
> > > > >
> > > > > I'm working on cluster read-only mode [1] feature. In this mode
> cluster
> > > > > will be available only for read operations, all data modification
> > > > > operations in user caches will be rejected
> > > > > with ClusterReadOnlyModeCheckedException. This feature could be
> helpfull
> > > > > for maintenance works (control.sh idle_verify/validate_indexes).
> > > > >
> > > > > A few points about cluster read-only mode:
> > > > > 1) Read-only mode could be enabled on active cluster only.
> > > > > 2) Read-only mode doens't store on PDS (i.e. after cluster restart
> > > > > enabled
> > > > > read-only mode will be forgotten)
> > > > > 3) Updates to ignite-sys-cache will be available with enabled
> read-only
> > > > > mode.
> > > > >
> > > > > More informartion about implementation you could find in PR [2].
> > > > >
> > > > > What do you think about this feature?
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11256
> > > > > [2] https://github.com/apache/ignite/pull/6423
> > > >
> > >
> > >
> > > --
> > > BR, Sergey Antonov
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>


-- 
BR, Sergey Antonov

Re: {DISCUSSION] Cluster read-only mode.

Posted by Dmitriy Pavlov <dp...@apache.org>.
I don't remember if we agreed on it before. But it may be so, just a
problem for me to remember it. Any big feature - it is quite a vague
definition.

My concern we'll end up with +1 inactive/uncompleted/not actual IEP. For
now, we have a number of open IEPs, and no-one resolves it. I guess it
should be part of the IEP process of 'how to' and 'when' close it. For me,
this process seems to be still incomplete.

If someone will lead all existing IEPs to be closed and finalize the
process, it would work.

вт, 4 июн. 2019 г. в 13:49, Nikolay Izhikov <ni...@apache.org>:

> Hello, Dmitriy.
>
> I don't agree with you.
>
> IEP should be written for any big changes in product.
> We should have it for:
>
> 1. Following contributors.
> 2. History of decision making.
> 3. Easier documenting.
>
> Without IEPs our product will become a total mess.
>
> In the Apache Kafka one can't change any public API without KIP(Kafka
> improvement proposal).
> I think it's a good practice.
>
>
> В Вт, 04/06/2019 в 13:43 +0300, Dmitriy Pavlov пишет:
> > Folks,
> >
> > Sorry for offtopic. IEP is a good tool for case design is discussed
> before
> > any implementation available. It is a good place to share the intent to
> do
> > something and provide some details. It is a better place then mile-long
> > emails.
> >
> > For now, we have code and documentation later should be updated. I don't
> > think we need to create IEP.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > вт, 4 июн. 2019 г. в 12:16, Павлухин Иван <vo...@gmail.com>:
> >
> > > Sergey, Igniters,
> > >
> > > Sorry if my question is not very smart.
> > >
> > > I am trying to think about it from a perspective of a (newbie) user.
> > > And from the first glance it is not clear how a read-only cluster is
> > > different from a not active cluster? What is a fundamental difference
> > > between them? Can we combine two modes into one? If not we will need a
> > > clear explanation for a user.
> > >
> > > пн, 3 июн. 2019 г. в 20:15, Maxim Muzafarov <ma...@gmail.com>:
> > > >
> > > > Sergey,
> > > >
> > > > Do we have an IEP for this feature?
> > > >
> > > > What should happen when on an active cluster with put operations if
> we
> > > > receive a read-only state change request? How we guarantee that all
> > > > cache operations delivered (or not yet) to backups are not rejected
> by
> > > > applied read-only request? I haven't found such tests in your PR.
> > > >
> > > > I've downloaded your branch and run some tests locally. I've tried
> > > > DataStreamer cache loads (allowOverwrite mode false) with a
> concurrent
> > > > cluster change state request to read-only mode and I've got strange
> > > > behaviour. My test scenario was:
> > > > 1) Start DataStremer cache load;
> > > > 2) change cluster to read-only state;
> > > > 3) change state back to normal;
> > > >
> > > > When the state has been changed to `read-only` I've flooded with a
> lot
> > > > of `Failed to perform cache operation (cluster is in read-only mode)`
> > > > errors, but when I've reverted the state back the DataStreamer
> > > > continue its load without any error. I think we should not allow such
> > > > behaviour. We should cancel the DataStreamer task or allow it to be
> > > > finished.
> > > >
> > > > On Fri, 31 May 2019 at 13:00, Sergey Antonov <
> antonovsergey93@gmail.com>
> > >
> > > wrote:
> > > > >
> > > > > Hello, Zhenya, Maxim!
> > > > >
> > > > > Thank you for your replies!
> > > > >
> > > > > > > Should we also allow writes to the DistributedMetaStorage and
> if
> > >
> > > not why?
> > > > > Yes. DistributedMetastorage available for updates with enabled
> > >
> > > read-only
> > > > > mode. I added test about it to ClusterReadOnlyModeSelfTest
> > > > >
> > > > > > > What's the purpose for ignite-sys-cache updates still be
> available ?
> > > > >
> > > > > ignite-sys-cache is using in the different subcomponents, for
> example,
> > > > > security.
> > > > >
> > > > > чт, 30 мая 2019 г. в 20:30, Zhenya Stanilovsky
> > >
> > > <ar...@mail.ru.invalid>:
> > > > >
> > > > > > hi, Sergey.
> > > > > > What's the purpose for ignite-sys-cache updates still be
> available ?
> > > > > >
> > > > > > thanks !
> > > > > >
> > > > > > > Hello Igniters!
> > > > > > >
> > > > > > > I'm working on cluster read-only mode [1] feature. In this mode
> > >
> > > cluster
> > > > > > > will be available only for read operations, all data
> modification
> > > > > > > operations in user caches will be rejected
> > > > > > > with ClusterReadOnlyModeCheckedException. This feature could be
> > >
> > > helpfull
> > > > > > > for maintenance works (control.sh
> idle_verify/validate_indexes).
> > > > > > >
> > > > > > > A few points about cluster read-only mode:
> > > > > > > 1) Read-only mode could be enabled on active cluster only.
> > > > > > > 2) Read-only mode doens't store on PDS (i.e. after cluster
> restart
> > > > > > > enabled
> > > > > > > read-only mode will be forgotten)
> > > > > > > 3) Updates to ignite-sys-cache will be available with enabled
> > >
> > > read-only
> > > > > > > mode.
> > > > > > >
> > > > > > > More informartion about implementation you could find in PR
> [2].
> > > > > > >
> > > > > > > What do you think about this feature?
> > > > > > >
> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11256
> > > > > > > [2] https://github.com/apache/ignite/pull/6423
> > > > >
> > > > >
> > > > > --
> > > > > BR, Sergey Antonov
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Ivan Pavlukhin
> > >
>

Re: {DISCUSSION] Cluster read-only mode.

Posted by Nikolay Izhikov <ni...@apache.org>.
Hello, Dmitriy.

I don't agree with you.

IEP should be written for any big changes in product.
We should have it for:

1. Following contributors.
2. History of decision making.
3. Easier documenting.

Without IEPs our product will become a total mess.

In the Apache Kafka one can't change any public API without KIP(Kafka improvement proposal).
I think it's a good practice.


В Вт, 04/06/2019 в 13:43 +0300, Dmitriy Pavlov пишет:
> Folks,
> 
> Sorry for offtopic. IEP is a good tool for case design is discussed before
> any implementation available. It is a good place to share the intent to do
> something and provide some details. It is a better place then mile-long
> emails.
> 
> For now, we have code and documentation later should be updated. I don't
> think we need to create IEP.
> 
> Sincerely,
> Dmitriy Pavlov
> 
> вт, 4 июн. 2019 г. в 12:16, Павлухин Иван <vo...@gmail.com>:
> 
> > Sergey, Igniters,
> > 
> > Sorry if my question is not very smart.
> > 
> > I am trying to think about it from a perspective of a (newbie) user.
> > And from the first glance it is not clear how a read-only cluster is
> > different from a not active cluster? What is a fundamental difference
> > between them? Can we combine two modes into one? If not we will need a
> > clear explanation for a user.
> > 
> > пн, 3 июн. 2019 г. в 20:15, Maxim Muzafarov <ma...@gmail.com>:
> > > 
> > > Sergey,
> > > 
> > > Do we have an IEP for this feature?
> > > 
> > > What should happen when on an active cluster with put operations if we
> > > receive a read-only state change request? How we guarantee that all
> > > cache operations delivered (or not yet) to backups are not rejected by
> > > applied read-only request? I haven't found such tests in your PR.
> > > 
> > > I've downloaded your branch and run some tests locally. I've tried
> > > DataStreamer cache loads (allowOverwrite mode false) with a concurrent
> > > cluster change state request to read-only mode and I've got strange
> > > behaviour. My test scenario was:
> > > 1) Start DataStremer cache load;
> > > 2) change cluster to read-only state;
> > > 3) change state back to normal;
> > > 
> > > When the state has been changed to `read-only` I've flooded with a lot
> > > of `Failed to perform cache operation (cluster is in read-only mode)`
> > > errors, but when I've reverted the state back the DataStreamer
> > > continue its load without any error. I think we should not allow such
> > > behaviour. We should cancel the DataStreamer task or allow it to be
> > > finished.
> > > 
> > > On Fri, 31 May 2019 at 13:00, Sergey Antonov <an...@gmail.com>
> > 
> > wrote:
> > > > 
> > > > Hello, Zhenya, Maxim!
> > > > 
> > > > Thank you for your replies!
> > > > 
> > > > > > Should we also allow writes to the DistributedMetaStorage and if
> > 
> > not why?
> > > > Yes. DistributedMetastorage available for updates with enabled
> > 
> > read-only
> > > > mode. I added test about it to ClusterReadOnlyModeSelfTest
> > > > 
> > > > > > What's the purpose for ignite-sys-cache updates still be available ?
> > > > 
> > > > ignite-sys-cache is using in the different subcomponents, for example,
> > > > security.
> > > > 
> > > > чт, 30 мая 2019 г. в 20:30, Zhenya Stanilovsky
> > 
> > <ar...@mail.ru.invalid>:
> > > > 
> > > > > hi, Sergey.
> > > > > What's the purpose for ignite-sys-cache updates still be available ?
> > > > > 
> > > > > thanks !
> > > > > 
> > > > > > Hello Igniters!
> > > > > > 
> > > > > > I'm working on cluster read-only mode [1] feature. In this mode
> > 
> > cluster
> > > > > > will be available only for read operations, all data modification
> > > > > > operations in user caches will be rejected
> > > > > > with ClusterReadOnlyModeCheckedException. This feature could be
> > 
> > helpfull
> > > > > > for maintenance works (control.sh idle_verify/validate_indexes).
> > > > > > 
> > > > > > A few points about cluster read-only mode:
> > > > > > 1) Read-only mode could be enabled on active cluster only.
> > > > > > 2) Read-only mode doens't store on PDS (i.e. after cluster restart
> > > > > > enabled
> > > > > > read-only mode will be forgotten)
> > > > > > 3) Updates to ignite-sys-cache will be available with enabled
> > 
> > read-only
> > > > > > mode.
> > > > > > 
> > > > > > More informartion about implementation you could find in PR [2].
> > > > > > 
> > > > > > What do you think about this feature?
> > > > > > 
> > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11256
> > > > > > [2] https://github.com/apache/ignite/pull/6423
> > > > 
> > > > 
> > > > --
> > > > BR, Sergey Antonov
> > 
> > 
> > 
> > --
> > Best regards,
> > Ivan Pavlukhin
> > 

Re: {DISCUSSION] Cluster read-only mode.

Posted by Dmitriy Pavlov <dp...@apache.org>.
Folks,

Sorry for offtopic. IEP is a good tool for case design is discussed before
any implementation available. It is a good place to share the intent to do
something and provide some details. It is a better place then mile-long
emails.

For now, we have code and documentation later should be updated. I don't
think we need to create IEP.

Sincerely,
Dmitriy Pavlov

вт, 4 июн. 2019 г. в 12:16, Павлухин Иван <vo...@gmail.com>:

> Sergey, Igniters,
>
> Sorry if my question is not very smart.
>
> I am trying to think about it from a perspective of a (newbie) user.
> And from the first glance it is not clear how a read-only cluster is
> different from a not active cluster? What is a fundamental difference
> between them? Can we combine two modes into one? If not we will need a
> clear explanation for a user.
>
> пн, 3 июн. 2019 г. в 20:15, Maxim Muzafarov <ma...@gmail.com>:
> >
> > Sergey,
> >
> > Do we have an IEP for this feature?
> >
> > What should happen when on an active cluster with put operations if we
> > receive a read-only state change request? How we guarantee that all
> > cache operations delivered (or not yet) to backups are not rejected by
> > applied read-only request? I haven't found such tests in your PR.
> >
> > I've downloaded your branch and run some tests locally. I've tried
> > DataStreamer cache loads (allowOverwrite mode false) with a concurrent
> > cluster change state request to read-only mode and I've got strange
> > behaviour. My test scenario was:
> > 1) Start DataStremer cache load;
> > 2) change cluster to read-only state;
> > 3) change state back to normal;
> >
> > When the state has been changed to `read-only` I've flooded with a lot
> > of `Failed to perform cache operation (cluster is in read-only mode)`
> > errors, but when I've reverted the state back the DataStreamer
> > continue its load without any error. I think we should not allow such
> > behaviour. We should cancel the DataStreamer task or allow it to be
> > finished.
> >
> > On Fri, 31 May 2019 at 13:00, Sergey Antonov <an...@gmail.com>
> wrote:
> > >
> > > Hello, Zhenya, Maxim!
> > >
> > > Thank you for your replies!
> > >
> > > >> Should we also allow writes to the DistributedMetaStorage and if
> not why?
> > > Yes. DistributedMetastorage available for updates with enabled
> read-only
> > > mode. I added test about it to ClusterReadOnlyModeSelfTest
> > >
> > > >> What's the purpose for ignite-sys-cache updates still be available ?
> > > ignite-sys-cache is using in the different subcomponents, for example,
> > > security.
> > >
> > > чт, 30 мая 2019 г. в 20:30, Zhenya Stanilovsky
> <ar...@mail.ru.invalid>:
> > >
> > > > hi, Sergey.
> > > > What's the purpose for ignite-sys-cache updates still be available ?
> > > >
> > > > thanks !
> > > >
> > > > > Hello Igniters!
> > > > >
> > > > > I'm working on cluster read-only mode [1] feature. In this mode
> cluster
> > > > > will be available only for read operations, all data modification
> > > > > operations in user caches will be rejected
> > > > > with ClusterReadOnlyModeCheckedException. This feature could be
> helpfull
> > > > > for maintenance works (control.sh idle_verify/validate_indexes).
> > > > >
> > > > > A few points about cluster read-only mode:
> > > > > 1) Read-only mode could be enabled on active cluster only.
> > > > > 2) Read-only mode doens't store on PDS (i.e. after cluster restart
> > > > > enabled
> > > > > read-only mode will be forgotten)
> > > > > 3) Updates to ignite-sys-cache will be available with enabled
> read-only
> > > > > mode.
> > > > >
> > > > > More informartion about implementation you could find in PR [2].
> > > > >
> > > > > What do you think about this feature?
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11256
> > > > > [2] https://github.com/apache/ignite/pull/6423
> > > >
> > >
> > >
> > > --
> > > BR, Sergey Antonov
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>

Re: {DISCUSSION] Cluster read-only mode.

Posted by Павлухин Иван <vo...@gmail.com>.
Sergey, Igniters,

Sorry if my question is not very smart.

I am trying to think about it from a perspective of a (newbie) user.
And from the first glance it is not clear how a read-only cluster is
different from a not active cluster? What is a fundamental difference
between them? Can we combine two modes into one? If not we will need a
clear explanation for a user.

пн, 3 июн. 2019 г. в 20:15, Maxim Muzafarov <ma...@gmail.com>:
>
> Sergey,
>
> Do we have an IEP for this feature?
>
> What should happen when on an active cluster with put operations if we
> receive a read-only state change request? How we guarantee that all
> cache operations delivered (or not yet) to backups are not rejected by
> applied read-only request? I haven't found such tests in your PR.
>
> I've downloaded your branch and run some tests locally. I've tried
> DataStreamer cache loads (allowOverwrite mode false) with a concurrent
> cluster change state request to read-only mode and I've got strange
> behaviour. My test scenario was:
> 1) Start DataStremer cache load;
> 2) change cluster to read-only state;
> 3) change state back to normal;
>
> When the state has been changed to `read-only` I've flooded with a lot
> of `Failed to perform cache operation (cluster is in read-only mode)`
> errors, but when I've reverted the state back the DataStreamer
> continue its load without any error. I think we should not allow such
> behaviour. We should cancel the DataStreamer task or allow it to be
> finished.
>
> On Fri, 31 May 2019 at 13:00, Sergey Antonov <an...@gmail.com> wrote:
> >
> > Hello, Zhenya, Maxim!
> >
> > Thank you for your replies!
> >
> > >> Should we also allow writes to the DistributedMetaStorage and if not why?
> > Yes. DistributedMetastorage available for updates with enabled read-only
> > mode. I added test about it to ClusterReadOnlyModeSelfTest
> >
> > >> What's the purpose for ignite-sys-cache updates still be available ?
> > ignite-sys-cache is using in the different subcomponents, for example,
> > security.
> >
> > чт, 30 мая 2019 г. в 20:30, Zhenya Stanilovsky <ar...@mail.ru.invalid>:
> >
> > > hi, Sergey.
> > > What's the purpose for ignite-sys-cache updates still be available ?
> > >
> > > thanks !
> > >
> > > > Hello Igniters!
> > > >
> > > > I'm working on cluster read-only mode [1] feature. In this mode cluster
> > > > will be available only for read operations, all data modification
> > > > operations in user caches will be rejected
> > > > with ClusterReadOnlyModeCheckedException. This feature could be helpfull
> > > > for maintenance works (control.sh idle_verify/validate_indexes).
> > > >
> > > > A few points about cluster read-only mode:
> > > > 1) Read-only mode could be enabled on active cluster only.
> > > > 2) Read-only mode doens't store on PDS (i.e. after cluster restart
> > > > enabled
> > > > read-only mode will be forgotten)
> > > > 3) Updates to ignite-sys-cache will be available with enabled read-only
> > > > mode.
> > > >
> > > > More informartion about implementation you could find in PR [2].
> > > >
> > > > What do you think about this feature?
> > > >
> > > > [1] https://issues.apache.org/jira/browse/IGNITE-11256
> > > > [2] https://github.com/apache/ignite/pull/6423
> > >
> >
> >
> > --
> > BR, Sergey Antonov



-- 
Best regards,
Ivan Pavlukhin