[DISCUSSION] Ignite 3.0 and to be removed list

[Alexey Goncharuk-3]

Igniters,

Even though we are still planning the Ignite 2.8 release, I would like to
kick-off a discussion related to Ignite 3.0, because the efforts for AI 3.0
will be significantly larger than for AI 2.8, better to start early.

As a first step, I would like to discuss the list of things to be removed
in Ignite 3.0 (partially this thread is inspired by Denis Magda's IGFS
removal thread). I've separated all to-be-removed points from existing
Ignite 3.0 wishlist [1] to a dedicated block and also added a few more
things that look right to be dropped.

Please share your thoughts, probably, there are more outdated things we
need to add to the wishlist.

As a side question: I think it makes sense to create tickets for such
improvements, how do we track them. Will the 3.0 version suffice or should
we add a separate label?

--AG

[Nikolay Izhikov-2]

* Scalar.
* LOCAL caches.
* Deprecated metrics.

В Пн, 17/06/2019 в 15:18 +0300, Alexey Goncharuk пишет:

> Igniters,
>
> Even though we are still planning the Ignite 2.8 release, I would like to
> kick-off a discussion related to Ignite 3.0, because the efforts for AI 3.0
> will be significantly larger than for AI 2.8, better to start early.
>
> As a first step, I would like to discuss the list of things to be removed
> in Ignite 3.0 (partially this thread is inspired by Denis Magda's IGFS
> removal thread). I've separated all to-be-removed points from existing
> Ignite 3.0 wishlist [1] to a dedicated block and also added a few more
> things that look right to be dropped.
>
> Please share your thoughts, probably, there are more outdated things we
> need to add to the wishlist.
>
> As a side question: I think it makes sense to create tickets for such
> improvements, how do we track them. Will the 3.0 version suffice or should
> we add a separate label?

[Alexey Goncharuk]

Nikolay,

Local caches and scalar are already in the list :) Added the outdated
metrics point.

пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov <[hidden email]>:

> * Scalar.
> * LOCAL caches.
> * Deprecated metrics.
>
> В Пн, 17/06/2019 в 15:18 +0300, Alexey Goncharuk пишет:
> > Igniters,
> >
> > Even though we are still planning the Ignite 2.8 release, I would like to
> > kick-off a discussion related to Ignite 3.0, because the efforts for AI
> 3.0
> > will be significantly larger than for AI 2.8, better to start early.
> >
> > As a first step, I would like to discuss the list of things to be removed
> > in Ignite 3.0 (partially this thread is inspired by Denis Magda's IGFS
> > removal thread). I've separated all to-be-removed points from existing
> > Ignite 3.0 wishlist [1] to a dedicated block and also added a few more
> > things that look right to be dropped.
> >
> > Please share your thoughts, probably, there are more outdated things we
> > need to add to the wishlist.
> >
> > As a side question: I think it makes sense to create tickets for such
> > improvements, how do we track them. Will the 3.0 version suffice or
> should
> > we add a separate label?
>

[Nikolay Izhikov-2]

Alexey.

I want to share a thought (just don't drop it out in one moment :) ).

Do we really need "client nodes"?

We have thin client protocol that is a very convenient point to interact with Ignite.
So, why, we need one more entity and work mode such as "client node"?

From my point of view, client nodes were required in the time without a thin client.
Now, we have it.

Let's simplify Ignite codebase and drop client nodes!

How does it sound?


В Пн, 17/06/2019 в 15:52 +0300, Alexey Goncharuk пишет:

> Nikolay,
>
> Local caches and scalar are already in the list :) Added the outdated
> metrics point.
>
> пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov <[hidden email]>:
>
> > * Scalar.
> > * LOCAL caches.
> > * Deprecated metrics.
> >
> > В Пн, 17/06/2019 в 15:18 +0300, Alexey Goncharuk пишет:
> > > Igniters,
> > >
> > > Even though we are still planning the Ignite 2.8 release, I would like to
> > > kick-off a discussion related to Ignite 3.0, because the efforts for AI
> >
> > 3.0
> > > will be significantly larger than for AI 2.8, better to start early.
> > >
> > > As a first step, I would like to discuss the list of things to be removed
> > > in Ignite 3.0 (partially this thread is inspired by Denis Magda's IGFS
> > > removal thread). I've separated all to-be-removed points from existing
> > > Ignite 3.0 wishlist [1] to a dedicated block and also added a few more
> > > things that look right to be dropped.
> > >
> > > Please share your thoughts, probably, there are more outdated things we
> > > need to add to the wishlist.
> > >
> > > As a side question: I think it makes sense to create tickets for such
> > > improvements, how do we track them. Will the 3.0 version suffice or
> >
> > should
> > > we add a separate label?

[Andrew Mashenkov]

Alexey,

* SqlQuery (not SqlFieldsQuery)
* Twitter module

On Mon, Jun 17, 2019 at 3:52 PM Alexey Goncharuk <[hidden email]>
wrote:

> Nikolay,
>
> Local caches and scalar are already in the list :) Added the outdated
> metrics point.
>
> пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov <[hidden email]>:
>
> > * Scalar.
> > * LOCAL caches.
> > * Deprecated metrics.
> >
> > В Пн, 17/06/2019 в 15:18 +0300, Alexey Goncharuk пишет:
> > > Igniters,
> > >
> > > Even though we are still planning the Ignite 2.8 release, I would like
> to
> > > kick-off a discussion related to Ignite 3.0, because the efforts for AI
> > 3.0
> > > will be significantly larger than for AI 2.8, better to start early.
> > >
> > > As a first step, I would like to discuss the list of things to be
> removed
> > > in Ignite 3.0 (partially this thread is inspired by Denis Magda's IGFS
> > > removal thread). I've separated all to-be-removed points from existing
> > > Ignite 3.0 wishlist [1] to a dedicated block and also added a few more
> > > things that look right to be dropped.
> > >
> > > Please share your thoughts, probably, there are more outdated things we
> > > need to add to the wishlist.
> > >
> > > As a side question: I think it makes sense to create tickets for such
> > > improvements, how do we track them. Will the 3.0 version suffice or
> > should
> > > we add a separate label?
> >
>

--
Best regards,
Andrey V. Mashenkov

[Anton Vinogradov-2]

>>  * Twitter module
Every extension/adapter/etc module should be checked to be useful.
My wish is to get rid of all lesser-used features, to make AI as small as
possible.
It's time to clean-up legacy :)

BTW, do we really need TCK support?

On Mon, Jun 17, 2019 at 4:05 PM Andrey Mashenkov <[hidden email]>
wrote:

> Alexey,
>
> * SqlQuery (not SqlFieldsQuery)
> * Twitter module
>
> On Mon, Jun 17, 2019 at 3:52 PM Alexey Goncharuk <
> [hidden email]>
> wrote:
>
> > Nikolay,
> >
> > Local caches and scalar are already in the list :) Added the outdated
> > metrics point.
> >
> > пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov <[hidden email]>:
> >
> > > * Scalar.
> > > * LOCAL caches.
> > > * Deprecated metrics.
> > >
> > > В Пн, 17/06/2019 в 15:18 +0300, Alexey Goncharuk пишет:
> > > > Igniters,
> > > >
> > > > Even though we are still planning the Ignite 2.8 release, I would
> like
> > to
> > > > kick-off a discussion related to Ignite 3.0, because the efforts for
> AI
> > > 3.0
> > > > will be significantly larger than for AI 2.8, better to start early.
> > > >
> > > > As a first step, I would like to discuss the list of things to be
> > removed
> > > > in Ignite 3.0 (partially this thread is inspired by Denis Magda's
> IGFS
> > > > removal thread). I've separated all to-be-removed points from
> existing
> > > > Ignite 3.0 wishlist [1] to a dedicated block and also added a few
> more
> > > > things that look right to be dropped.
> > > >
> > > > Please share your thoughts, probably, there are more outdated things
> we
> > > > need to add to the wishlist.
> > > >
> > > > As a side question: I think it makes sense to create tickets for such
> > > > improvements, how do we track them. Will the 3.0 version suffice or
> > > should
> > > > we add a separate label?
> > >
> >
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>

[Alexey Goncharuk]

Nikolay,

I had this thought too, but I am not too eager to implement it yet. The
reason is transaction protocol complexity/performance issues with thin
clients.

A thick client can communicate with each primary node and coordinate
prepare/commit phases. Thin client can only communicate with one node, so
the change will mean an additional network hop. Of course, we can make thin
clients implement the same protocol, but it will immediately increase the
protocol complexity for all platforms.

Plus, we do not have near cache on thin clients, we do not support p2p
class deployment, etc. Since thin clients are positioned as
platform-agnostic, I do not think it makes sense to expose all feature set
of Igntie to thin clients.

Instead, we can significantly simplify client node configuration - it
currently requires the same config as a regular Ignite node, however, in
most cases, the configuration can be reduced almost to a several host:port
pairs.

пн, 17 июн. 2019 г. в 15:58, Nikolay Izhikov <[hidden email]>:

> Alexey.
>
> I want to share a thought (just don't drop it out in one moment :) ).
>
> Do we really need "client nodes"?
>
> We have thin client protocol that is a very convenient point to interact
> with Ignite.
> So, why, we need one more entity and work mode such as "client node"?
>
> From my point of view, client nodes were required in the time without a
> thin client.
> Now, we have it.
>
> Let's simplify Ignite codebase and drop client nodes!
>
> How does it sound?
>
>
> В Пн, 17/06/2019 в 15:52 +0300, Alexey Goncharuk пишет:
> > Nikolay,
> >
> > Local caches and scalar are already in the list :) Added the outdated
> > metrics point.
> >
> > пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov <[hidden email]>:
> >
> > > * Scalar.
> > > * LOCAL caches.
> > > * Deprecated metrics.
> > >
> > > В Пн, 17/06/2019 в 15:18 +0300, Alexey Goncharuk пишет:
> > > > Igniters,
> > > >
> > > > Even though we are still planning the Ignite 2.8 release, I would
> like to
> > > > kick-off a discussion related to Ignite 3.0, because the efforts for
> AI
> > >
> > > 3.0
> > > > will be significantly larger than for AI 2.8, better to start early.
> > > >
> > > > As a first step, I would like to discuss the list of things to be
> removed
> > > > in Ignite 3.0 (partially this thread is inspired by Denis Magda's
> IGFS
> > > > removal thread). I've separated all to-be-removed points from
> existing
> > > > Ignite 3.0 wishlist [1] to a dedicated block and also added a few
> more
> > > > things that look right to be dropped.
> > > >
> > > > Please share your thoughts, probably, there are more outdated things
> we
> > > > need to add to the wishlist.
> > > >
> > > > As a side question: I think it makes sense to create tickets for such
> > > > improvements, how do we track them. Will the 3.0 version suffice or
> > >
> > > should
> > > > we add a separate label?
>

[Alexey Zinoviev]

Could we suggest here remove whole modules?

пн, 17 июн. 2019 г. в 16:28, Alexey Goncharuk <[hidden email]>:

> Nikolay,
>
> I had this thought too, but I am not too eager to implement it yet. The
> reason is transaction protocol complexity/performance issues with thin
> clients.
>
> A thick client can communicate with each primary node and coordinate
> prepare/commit phases. Thin client can only communicate with one node, so
> the change will mean an additional network hop. Of course, we can make thin
> clients implement the same protocol, but it will immediately increase the
> protocol complexity for all platforms.
>
> Plus, we do not have near cache on thin clients, we do not support p2p
> class deployment, etc. Since thin clients are positioned as
> platform-agnostic, I do not think it makes sense to expose all feature set
> of Igntie to thin clients.
>
> Instead, we can significantly simplify client node configuration - it
> currently requires the same config as a regular Ignite node, however, in
> most cases, the configuration can be reduced almost to a several host:port
> pairs.
>
> пн, 17 июн. 2019 г. в 15:58, Nikolay Izhikov <[hidden email]>:
>
> > Alexey.
> >
> > I want to share a thought (just don't drop it out in one moment :) ).
> >
> > Do we really need "client nodes"?
> >
> > We have thin client protocol that is a very convenient point to interact
> > with Ignite.
> > So, why, we need one more entity and work mode such as "client node"?
> >
> > From my point of view, client nodes were required in the time without a
> > thin client.
> > Now, we have it.
> >
> > Let's simplify Ignite codebase and drop client nodes!
> >
> > How does it sound?
> >
> >
> > В Пн, 17/06/2019 в 15:52 +0300, Alexey Goncharuk пишет:
> > > Nikolay,
> > >
> > > Local caches and scalar are already in the list :) Added the outdated
> > > metrics point.
> > >
> > > пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov <[hidden email]>:
> > >
> > > > * Scalar.
> > > > * LOCAL caches.
> > > > * Deprecated metrics.
> > > >
> > > > В Пн, 17/06/2019 в 15:18 +0300, Alexey Goncharuk пишет:
> > > > > Igniters,
> > > > >
> > > > > Even though we are still planning the Ignite 2.8 release, I would
> > like to
> > > > > kick-off a discussion related to Ignite 3.0, because the efforts
> for
> > AI
> > > >
> > > > 3.0
> > > > > will be significantly larger than for AI 2.8, better to start
> early.
> > > > >
> > > > > As a first step, I would like to discuss the list of things to be
> > removed
> > > > > in Ignite 3.0 (partially this thread is inspired by Denis Magda's
> > IGFS
> > > > > removal thread). I've separated all to-be-removed points from
> > existing
> > > > > Ignite 3.0 wishlist [1] to a dedicated block and also added a few
> > more
> > > > > things that look right to be dropped.
> > > > >
> > > > > Please share your thoughts, probably, there are more outdated
> things
> > we
> > > > > need to add to the wishlist.
> > > > >
> > > > > As a side question: I think it makes sense to create tickets for
> such
> > > > > improvements, how do we track them. Will the 3.0 version suffice or
> > > >
> > > > should
> > > > > we add a separate label?
> >
>

[Dmitry Pavlov]

Hi Nikolay,

I think client nodes removal is not possible in the near future because of
tons of usages everywhere outside Ignite code (in products, guides, books,
training, etc.)

If we have replacement we should encourage users to migrate, but we can't
remove such a core feature.

Alexey, sure we can discuss removal of modules, why not?

Sincerely,
Dmitriy Pavlov

пн, 17 июн. 2019 г. в 18:02, Alexey Zinoviev <[hidden email]>:

> Could we suggest here remove whole modules?
>
> пн, 17 июн. 2019 г. в 16:28, Alexey Goncharuk <[hidden email]
> >:
>
> > Nikolay,
> >
> > I had this thought too, but I am not too eager to implement it yet. The
> > reason is transaction protocol complexity/performance issues with thin
> > clients.
> >
> > A thick client can communicate with each primary node and coordinate
> > prepare/commit phases. Thin client can only communicate with one node, so
> > the change will mean an additional network hop. Of course, we can make
> thin
> > clients implement the same protocol, but it will immediately increase the
> > protocol complexity for all platforms.
> >
> > Plus, we do not have near cache on thin clients, we do not support p2p
> > class deployment, etc. Since thin clients are positioned as
> > platform-agnostic, I do not think it makes sense to expose all feature
> set
> > of Igntie to thin clients.
> >
> > Instead, we can significantly simplify client node configuration - it
> > currently requires the same config as a regular Ignite node, however, in
> > most cases, the configuration can be reduced almost to a several
> host:port
> > pairs.
> >
> > пн, 17 июн. 2019 г. в 15:58, Nikolay Izhikov <[hidden email]>:
> >
> > > Alexey.
> > >
> > > I want to share a thought (just don't drop it out in one moment :) ).
> > >
> > > Do we really need "client nodes"?
> > >
> > > We have thin client protocol that is a very convenient point to
> interact
> > > with Ignite.
> > > So, why, we need one more entity and work mode such as "client node"?
> > >
> > > From my point of view, client nodes were required in the time without a
> > > thin client.
> > > Now, we have it.
> > >
> > > Let's simplify Ignite codebase and drop client nodes!
> > >
> > > How does it sound?
> > >
> > >
> > > В Пн, 17/06/2019 в 15:52 +0300, Alexey Goncharuk пишет:
> > > > Nikolay,
> > > >
> > > > Local caches and scalar are already in the list :) Added the outdated
> > > > metrics point.
> > > >
> > > > пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov <[hidden email]>:
> > > >
> > > > > * Scalar.
> > > > > * LOCAL caches.
> > > > > * Deprecated metrics.
> > > > >
> > > > > В Пн, 17/06/2019 в 15:18 +0300, Alexey Goncharuk пишет:
> > > > > > Igniters,
> > > > > >
> > > > > > Even though we are still planning the Ignite 2.8 release, I would
> > > like to
> > > > > > kick-off a discussion related to Ignite 3.0, because the efforts
> > for
> > > AI
> > > > >
> > > > > 3.0
> > > > > > will be significantly larger than for AI 2.8, better to start
> > early.
> > > > > >
> > > > > > As a first step, I would like to discuss the list of things to be
> > > removed
> > > > > > in Ignite 3.0 (partially this thread is inspired by Denis Magda's
> > > IGFS
> > > > > > removal thread). I've separated all to-be-removed points from
> > > existing
> > > > > > Ignite 3.0 wishlist [1] to a dedicated block and also added a few
> > > more
> > > > > > things that look right to be dropped.
> > > > > >
> > > > > > Please share your thoughts, probably, there are more outdated
> > things
> > > we
> > > > > > need to add to the wishlist.
> > > > > >
> > > > > > As a side question: I think it makes sense to create tickets for
> > such
> > > > > > improvements, how do we track them. Will the 3.0 version suffice
> or
> > > > >
> > > > > should
> > > > > > we add a separate label?
> > >
> >
>

[Nikolay Izhikov-2]

Dmitriy,

I think the whole concept of "client" nodes is broken.
And that's why:

Ignite Client node nothing to do with "client" :)
We can deploy cache on it, we can execute compute tasks, services on it.
"client node" is a node with special join process and some rebalance/PME hacks.
And we put many(many!) efforts to support this concept and this hacks.

And I'm asking: What value client nodes bring to Ignite?

I think, Alexey, already answered correctly:

* Transactions support.
* P2P deployment.

I think we should, definitely, remove concept of "client nodes" in the future.
It's about product design decision, in the first place, not about additional materials.

The simpler core codebase we have, the more reliable product we ca build with it.


В Пн, 17/06/2019 в 18:19 +0300, Dmitriy Pavlov пишет:

> Hi Nikolay,
>
> I think client nodes removal is not possible in the near future because of
> tons of usages everywhere outside Ignite code (in products, guides, books,
> training, etc.)
>
> If we have replacement we should encourage users to migrate, but we can't
> remove such a core feature.
>
> Alexey, sure we can discuss removal of modules, why not?
>
> Sincerely,
> Dmitriy Pavlov
>
> пн, 17 июн. 2019 г. в 18:02, Alexey Zinoviev <[hidden email]>:
>
> > Could we suggest here remove whole modules?
> >
> > пн, 17 июн. 2019 г. в 16:28, Alexey Goncharuk <[hidden email]
> > > :
> > > Nikolay,
> > >
> > > I had this thought too, but I am not too eager to implement it yet. The
> > > reason is transaction protocol complexity/performance issues with thin
> > > clients.
> > >
> > > A thick client can communicate with each primary node and coordinate
> > > prepare/commit phases. Thin client can only communicate with one node, so
> > > the change will mean an additional network hop. Of course, we can make
> >
> > thin
> > > clients implement the same protocol, but it will immediately increase the
> > > protocol complexity for all platforms.
> > >
> > > Plus, we do not have near cache on thin clients, we do not support p2p
> > > class deployment, etc. Since thin clients are positioned as
> > > platform-agnostic, I do not think it makes sense to expose all feature
> >
> > set
> > > of Igntie to thin clients.
> > >
> > > Instead, we can significantly simplify client node configuration - it
> > > currently requires the same config as a regular Ignite node, however, in
> > > most cases, the configuration can be reduced almost to a several
> >
> > host:port
> > > pairs.
> > >
> > > пн, 17 июн. 2019 г. в 15:58, Nikolay Izhikov <[hidden email]>:
> > >
> > > > Alexey.
> > > >
> > > > I want to share a thought (just don't drop it out in one moment :) ).
> > > >
> > > > Do we really need "client nodes"?
> > > >
> > > > We have thin client protocol that is a very convenient point to
> >
> > interact
> > > > with Ignite.
> > > > So, why, we need one more entity and work mode such as "client node"?
> > > >
> > > > From my point of view, client nodes were required in the time without a
> > > > thin client.
> > > > Now, we have it.
> > > >
> > > > Let's simplify Ignite codebase and drop client nodes!
> > > >
> > > > How does it sound?
> > > >
> > > >
> > > > В Пн, 17/06/2019 в 15:52 +0300, Alexey Goncharuk пишет:
> > > > > Nikolay,
> > > > >
> > > > > Local caches and scalar are already in the list :) Added the outdated
> > > > > metrics point.
> > > > >
> > > > > пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov <[hidden email]>:
> > > > >
> > > > > > * Scalar.
> > > > > > * LOCAL caches.
> > > > > > * Deprecated metrics.
> > > > > >
> > > > > > В Пн, 17/06/2019 в 15:18 +0300, Alexey Goncharuk пишет:
> > > > > > > Igniters,
> > > > > > >
> > > > > > > Even though we are still planning the Ignite 2.8 release, I would
> > > >
> > > > like to
> > > > > > > kick-off a discussion related to Ignite 3.0, because the efforts
> > >
> > > for
> > > > AI
> > > > > >
> > > > > > 3.0
> > > > > > > will be significantly larger than for AI 2.8, better to start
> > >
> > > early.
> > > > > > >
> > > > > > > As a first step, I would like to discuss the list of things to be
> > > >
> > > > removed
> > > > > > > in Ignite 3.0 (partially this thread is inspired by Denis Magda's
> > > >
> > > > IGFS
> > > > > > > removal thread). I've separated all to-be-removed points from
> > > >
> > > > existing
> > > > > > > Ignite 3.0 wishlist [1] to a dedicated block and also added a few
> > > >
> > > > more
> > > > > > > things that look right to be dropped.
> > > > > > >
> > > > > > > Please share your thoughts, probably, there are more outdated
> > >
> > > things
> > > > we
> > > > > > > need to add to the wishlist.
> > > > > > >
> > > > > > > As a side question: I think it makes sense to create tickets for
> > >
> > > such
> > > > > > > improvements, how do we track them. Will the 3.0 version suffice
> >
> > or
> > > > > >
> > > > > > should
> > > > > > > we add a separate label?

[Dmitry Pavlov]

Nikolay,

we can (and probably should) discuss stop deploying caches/services to
client nodes.

But I would not name it removal of client nodes at all. Any Apache Ignite
guide I saw is starting from 2 steps: 1) start server node, 2) start client
node.

There are no reasons to write software if users are unaware of how to use
it. So I do not agree that supplementary materials are unimportant.

Sincerely,
Dmitriy Pavlov

пн, 17 июн. 2019 г. в 18:30, Nikolay Izhikov <[hidden email]>:

> Dmitriy,
>
> I think the whole concept of "client" nodes is broken.
> And that's why:
>
> Ignite Client node nothing to do with "client" :)
> We can deploy cache on it, we can execute compute tasks, services on it.
> "client node" is a node with special join process and some rebalance/PME
> hacks.
> And we put many(many!) efforts to support this concept and this hacks.
>
> And I'm asking: What value client nodes bring to Ignite?
>
> I think, Alexey, already answered correctly:
>
> * Transactions support.
> * P2P deployment.
>
> I think we should, definitely, remove concept of "client nodes" in the
> future.
> It's about product design decision, in the first place, not about
> additional materials.
>
> The simpler core codebase we have, the more reliable product we ca build
> with it.
>
>
> В Пн, 17/06/2019 в 18:19 +0300, Dmitriy Pavlov пишет:
> > Hi Nikolay,
> >
> > I think client nodes removal is not possible in the near future because
> of
> > tons of usages everywhere outside Ignite code (in products, guides,
> books,
> > training, etc.)
> >
> > If we have replacement we should encourage users to migrate, but we can't
> > remove such a core feature.
> >
> > Alexey, sure we can discuss removal of modules, why not?
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > пн, 17 июн. 2019 г. в 18:02, Alexey Zinoviev <[hidden email]>:
> >
> > > Could we suggest here remove whole modules?
> > >
> > > пн, 17 июн. 2019 г. в 16:28, Alexey Goncharuk <
> [hidden email]
> > > > :
> > > > Nikolay,
> > > >
> > > > I had this thought too, but I am not too eager to implement it yet.
> The
> > > > reason is transaction protocol complexity/performance issues with
> thin
> > > > clients.
> > > >
> > > > A thick client can communicate with each primary node and coordinate
> > > > prepare/commit phases. Thin client can only communicate with one
> node, so
> > > > the change will mean an additional network hop. Of course, we can
> make
> > >
> > > thin
> > > > clients implement the same protocol, but it will immediately
> increase the
> > > > protocol complexity for all platforms.
> > > >
> > > > Plus, we do not have near cache on thin clients, we do not support
> p2p
> > > > class deployment, etc. Since thin clients are positioned as
> > > > platform-agnostic, I do not think it makes sense to expose all
> feature
> > >
> > > set
> > > > of Igntie to thin clients.
> > > >
> > > > Instead, we can significantly simplify client node configuration - it
> > > > currently requires the same config as a regular Ignite node,
> however, in
> > > > most cases, the configuration can be reduced almost to a several
> > >
> > > host:port
> > > > pairs.
> > > >
> > > > пн, 17 июн. 2019 г. в 15:58, Nikolay Izhikov <[hidden email]>:
> > > >
> > > > > Alexey.
> > > > >
> > > > > I want to share a thought (just don't drop it out in one moment :)
> ).
> > > > >
> > > > > Do we really need "client nodes"?
> > > > >
> > > > > We have thin client protocol that is a very convenient point to
> > >
> > > interact
> > > > > with Ignite.
> > > > > So, why, we need one more entity and work mode such as "client
> node"?
> > > > >
> > > > > From my point of view, client nodes were required in the time
> without a
> > > > > thin client.
> > > > > Now, we have it.
> > > > >
> > > > > Let's simplify Ignite codebase and drop client nodes!
> > > > >
> > > > > How does it sound?
> > > > >
> > > > >
> > > > > В Пн, 17/06/2019 в 15:52 +0300, Alexey Goncharuk пишет:
> > > > > > Nikolay,
> > > > > >
> > > > > > Local caches and scalar are already in the list :) Added the
> outdated
> > > > > > metrics point.
> > > > > >
> > > > > > пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov <
> [hidden email]>:
> > > > > >
> > > > > > > * Scalar.
> > > > > > > * LOCAL caches.
> > > > > > > * Deprecated metrics.
> > > > > > >
> > > > > > > В Пн, 17/06/2019 в 15:18 +0300, Alexey Goncharuk пишет:
> > > > > > > > Igniters,
> > > > > > > >
> > > > > > > > Even though we are still planning the Ignite 2.8 release, I
> would
> > > > >
> > > > > like to
> > > > > > > > kick-off a discussion related to Ignite 3.0, because the
> efforts
> > > >
> > > > for
> > > > > AI
> > > > > > >
> > > > > > > 3.0
> > > > > > > > will be significantly larger than for AI 2.8, better to start
> > > >
> > > > early.
> > > > > > > >
> > > > > > > > As a first step, I would like to discuss the list of things
> to be
> > > > >
> > > > > removed
> > > > > > > > in Ignite 3.0 (partially this thread is inspired by Denis
> Magda's
> > > > >
> > > > > IGFS
> > > > > > > > removal thread). I've separated all to-be-removed points from
> > > > >
> > > > > existing
> > > > > > > > Ignite 3.0 wishlist [1] to a dedicated block and also added
> a few
> > > > >
> > > > > more
> > > > > > > > things that look right to be dropped.
> > > > > > > >
> > > > > > > > Please share your thoughts, probably, there are more outdated
> > > >
> > > > things
> > > > > we
> > > > > > > > need to add to the wishlist.
> > > > > > > >
> > > > > > > > As a side question: I think it makes sense to create tickets
> for
> > > >
> > > > such
> > > > > > > > improvements, how do we track them. Will the 3.0 version
> suffice
> > >
> > > or
> > > > > > >
> > > > > > > should
> > > > > > > > we add a separate label?
>

[Pavel Kovalenko]

I would like to add to the list following:

1. Remove ForceKeyRequests and related code. Since we have Late affinity
assignment and primary node partitions are always up to date we don't need
to request actual data from backups.
2. Remove @CentralizedAffinityFunction and related code. I don't see any
real usages of custom affinity functions that use this annotation.
3. Leave Exchanges Merge + Late Affinity assignment as the only PME
protocol. Remove centralized affinity distribution in case of node left and
no merge exchange legacy modes.
4. Remove CacheRebalanceMode.NONE and Rebalance Delay as it can break data
consistency in a cluster. Also, remove force rebalance mode as it can be
used only if rebalance delay is set.

пн, 17 июн. 2019 г. в 18:39, Dmitriy Pavlov <[hidden email]>:

> Nikolay,
>
> we can (and probably should) discuss stop deploying caches/services to
> client nodes.
>
> But I would not name it removal of client nodes at all. Any Apache Ignite
> guide I saw is starting from 2 steps: 1) start server node, 2) start client
> node.
>
> There are no reasons to write software if users are unaware of how to use
> it. So I do not agree that supplementary materials are unimportant.
>
> Sincerely,
> Dmitriy Pavlov
>
> пн, 17 июн. 2019 г. в 18:30, Nikolay Izhikov <[hidden email]>:
>
> > Dmitriy,
> >
> > I think the whole concept of "client" nodes is broken.
> > And that's why:
> >
> > Ignite Client node nothing to do with "client" :)
> > We can deploy cache on it, we can execute compute tasks, services on it.
> > "client node" is a node with special join process and some rebalance/PME
> > hacks.
> > And we put many(many!) efforts to support this concept and this hacks.
> >
> > And I'm asking: What value client nodes bring to Ignite?
> >
> > I think, Alexey, already answered correctly:
> >
> > * Transactions support.
> > * P2P deployment.
> >
> > I think we should, definitely, remove concept of "client nodes" in the
> > future.
> > It's about product design decision, in the first place, not about
> > additional materials.
> >
> > The simpler core codebase we have, the more reliable product we ca build
> > with it.
> >
> >
> > В Пн, 17/06/2019 в 18:19 +0300, Dmitriy Pavlov пишет:
> > > Hi Nikolay,
> > >
> > > I think client nodes removal is not possible in the near future because
> > of
> > > tons of usages everywhere outside Ignite code (in products, guides,
> > books,
> > > training, etc.)
> > >
> > > If we have replacement we should encourage users to migrate, but we
> can't
> > > remove such a core feature.
> > >
> > > Alexey, sure we can discuss removal of modules, why not?
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > пн, 17 июн. 2019 г. в 18:02, Alexey Zinoviev <[hidden email]>:
> > >
> > > > Could we suggest here remove whole modules?
> > > >
> > > > пн, 17 июн. 2019 г. в 16:28, Alexey Goncharuk <
> > [hidden email]
> > > > > :
> > > > > Nikolay,
> > > > >
> > > > > I had this thought too, but I am not too eager to implement it yet.
> > The
> > > > > reason is transaction protocol complexity/performance issues with
> > thin
> > > > > clients.
> > > > >
> > > > > A thick client can communicate with each primary node and
> coordinate
> > > > > prepare/commit phases. Thin client can only communicate with one
> > node, so
> > > > > the change will mean an additional network hop. Of course, we can
> > make
> > > >
> > > > thin
> > > > > clients implement the same protocol, but it will immediately
> > increase the
> > > > > protocol complexity for all platforms.
> > > > >
> > > > > Plus, we do not have near cache on thin clients, we do not support
> > p2p
> > > > > class deployment, etc. Since thin clients are positioned as
> > > > > platform-agnostic, I do not think it makes sense to expose all
> > feature
> > > >
> > > > set
> > > > > of Igntie to thin clients.
> > > > >
> > > > > Instead, we can significantly simplify client node configuration -
> it
> > > > > currently requires the same config as a regular Ignite node,
> > however, in
> > > > > most cases, the configuration can be reduced almost to a several
> > > >
> > > > host:port
> > > > > pairs.
> > > > >
> > > > > пн, 17 июн. 2019 г. в 15:58, Nikolay Izhikov <[hidden email]
> >:
> > > > >
> > > > > > Alexey.
> > > > > >
> > > > > > I want to share a thought (just don't drop it out in one moment
> :)
> > ).
> > > > > >
> > > > > > Do we really need "client nodes"?
> > > > > >
> > > > > > We have thin client protocol that is a very convenient point to
> > > >
> > > > interact
> > > > > > with Ignite.
> > > > > > So, why, we need one more entity and work mode such as "client
> > node"?
> > > > > >
> > > > > > From my point of view, client nodes were required in the time
> > without a
> > > > > > thin client.
> > > > > > Now, we have it.
> > > > > >
> > > > > > Let's simplify Ignite codebase and drop client nodes!
> > > > > >
> > > > > > How does it sound?
> > > > > >
> > > > > >
> > > > > > В Пн, 17/06/2019 в 15:52 +0300, Alexey Goncharuk пишет:
> > > > > > > Nikolay,
> > > > > > >
> > > > > > > Local caches and scalar are already in the list :) Added the
> > outdated
> > > > > > > metrics point.
> > > > > > >
> > > > > > > пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov <
> > [hidden email]>:
> > > > > > >
> > > > > > > > * Scalar.
> > > > > > > > * LOCAL caches.
> > > > > > > > * Deprecated metrics.
> > > > > > > >
> > > > > > > > В Пн, 17/06/2019 в 15:18 +0300, Alexey Goncharuk пишет:
> > > > > > > > > Igniters,
> > > > > > > > >
> > > > > > > > > Even though we are still planning the Ignite 2.8 release, I
> > would
> > > > > >
> > > > > > like to
> > > > > > > > > kick-off a discussion related to Ignite 3.0, because the
> > efforts
> > > > >
> > > > > for
> > > > > > AI
> > > > > > > >
> > > > > > > > 3.0
> > > > > > > > > will be significantly larger than for AI 2.8, better to
> start
> > > > >
> > > > > early.
> > > > > > > > >
> > > > > > > > > As a first step, I would like to discuss the list of things
> > to be
> > > > > >
> > > > > > removed
> > > > > > > > > in Ignite 3.0 (partially this thread is inspired by Denis
> > Magda's
> > > > > >
> > > > > > IGFS
> > > > > > > > > removal thread). I've separated all to-be-removed points
> from
> > > > > >
> > > > > > existing
> > > > > > > > > Ignite 3.0 wishlist [1] to a dedicated block and also added
> > a few
> > > > > >
> > > > > > more
> > > > > > > > > things that look right to be dropped.
> > > > > > > > >
> > > > > > > > > Please share your thoughts, probably, there are more
> outdated
> > > > >
> > > > > things
> > > > > > we
> > > > > > > > > need to add to the wishlist.
> > > > > > > > >
> > > > > > > > > As a side question: I think it makes sense to create
> tickets
> > for
> > > > >
> > > > > such
> > > > > > > > > improvements, how do we track them. Will the 3.0 version
> > suffice
> > > >
> > > > or
> > > > > > > >
> > > > > > > > should
> > > > > > > > > we add a separate label?
> >
>

[Igor Sapego]

For the C++ I propose to drop support of VS 2010 and move to
at least 2012 (or, better yet 2013).

Also, I'd drop x86 support for everything except for maybe ODBC.

Best Regards,
Igor

On Mon, Jun 17, 2019 at 7:12 PM Pavel Kovalenko <[hidden email]> wrote:

> I would like to add to the list following:
>
> 1. Remove ForceKeyRequests and related code. Since we have Late affinity
> assignment and primary node partitions are always up to date we don't need
> to request actual data from backups.
> 2. Remove @CentralizedAffinityFunction and related code. I don't see any
> real usages of custom affinity functions that use this annotation.
> 3. Leave Exchanges Merge + Late Affinity assignment as the only PME
> protocol. Remove centralized affinity distribution in case of node left and
> no merge exchange legacy modes.
> 4. Remove CacheRebalanceMode.NONE and Rebalance Delay as it can break data
> consistency in a cluster. Also, remove force rebalance mode as it can be
> used only if rebalance delay is set.
>
> пн, 17 июн. 2019 г. в 18:39, Dmitriy Pavlov <[hidden email]>:
>
> > Nikolay,
> >
> > we can (and probably should) discuss stop deploying caches/services to
> > client nodes.
> >
> > But I would not name it removal of client nodes at all. Any Apache Ignite
> > guide I saw is starting from 2 steps: 1) start server node, 2) start
> client
> > node.
> >
> > There are no reasons to write software if users are unaware of how to use
> > it. So I do not agree that supplementary materials are unimportant.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > пн, 17 июн. 2019 г. в 18:30, Nikolay Izhikov <[hidden email]>:
> >
> > > Dmitriy,
> > >
> > > I think the whole concept of "client" nodes is broken.
> > > And that's why:
> > >
> > > Ignite Client node nothing to do with "client" :)
> > > We can deploy cache on it, we can execute compute tasks, services on
> it.
> > > "client node" is a node with special join process and some
> rebalance/PME
> > > hacks.
> > > And we put many(many!) efforts to support this concept and this hacks.
> > >
> > > And I'm asking: What value client nodes bring to Ignite?
> > >
> > > I think, Alexey, already answered correctly:
> > >
> > > * Transactions support.
> > > * P2P deployment.
> > >
> > > I think we should, definitely, remove concept of "client nodes" in the
> > > future.
> > > It's about product design decision, in the first place, not about
> > > additional materials.
> > >
> > > The simpler core codebase we have, the more reliable product we ca
> build
> > > with it.
> > >
> > >
> > > В Пн, 17/06/2019 в 18:19 +0300, Dmitriy Pavlov пишет:
> > > > Hi Nikolay,
> > > >
> > > > I think client nodes removal is not possible in the near future
> because
> > > of
> > > > tons of usages everywhere outside Ignite code (in products, guides,
> > > books,
> > > > training, etc.)
> > > >
> > > > If we have replacement we should encourage users to migrate, but we
> > can't
> > > > remove such a core feature.
> > > >
> > > > Alexey, sure we can discuss removal of modules, why not?
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > пн, 17 июн. 2019 г. в 18:02, Alexey Zinoviev <[hidden email]
> >:
> > > >
> > > > > Could we suggest here remove whole modules?
> > > > >
> > > > > пн, 17 июн. 2019 г. в 16:28, Alexey Goncharuk <
> > > [hidden email]
> > > > > > :
> > > > > > Nikolay,
> > > > > >
> > > > > > I had this thought too, but I am not too eager to implement it
> yet.
> > > The
> > > > > > reason is transaction protocol complexity/performance issues with
> > > thin
> > > > > > clients.
> > > > > >
> > > > > > A thick client can communicate with each primary node and
> > coordinate
> > > > > > prepare/commit phases. Thin client can only communicate with one
> > > node, so
> > > > > > the change will mean an additional network hop. Of course, we can
> > > make
> > > > >
> > > > > thin
> > > > > > clients implement the same protocol, but it will immediately
> > > increase the
> > > > > > protocol complexity for all platforms.
> > > > > >
> > > > > > Plus, we do not have near cache on thin clients, we do not
> support
> > > p2p
> > > > > > class deployment, etc. Since thin clients are positioned as
> > > > > > platform-agnostic, I do not think it makes sense to expose all
> > > feature
> > > > >
> > > > > set
> > > > > > of Igntie to thin clients.
> > > > > >
> > > > > > Instead, we can significantly simplify client node configuration
> -
> > it
> > > > > > currently requires the same config as a regular Ignite node,
> > > however, in
> > > > > > most cases, the configuration can be reduced almost to a several
> > > > >
> > > > > host:port
> > > > > > pairs.
> > > > > >
> > > > > > пн, 17 июн. 2019 г. в 15:58, Nikolay Izhikov <
> [hidden email]
> > >:
> > > > > >
> > > > > > > Alexey.
> > > > > > >
> > > > > > > I want to share a thought (just don't drop it out in one moment
> > :)
> > > ).
> > > > > > >
> > > > > > > Do we really need "client nodes"?
> > > > > > >
> > > > > > > We have thin client protocol that is a very convenient point to
> > > > >
> > > > > interact
> > > > > > > with Ignite.
> > > > > > > So, why, we need one more entity and work mode such as "client
> > > node"?
> > > > > > >
> > > > > > > From my point of view, client nodes were required in the time
> > > without a
> > > > > > > thin client.
> > > > > > > Now, we have it.
> > > > > > >
> > > > > > > Let's simplify Ignite codebase and drop client nodes!
> > > > > > >
> > > > > > > How does it sound?
> > > > > > >
> > > > > > >
> > > > > > > В Пн, 17/06/2019 в 15:52 +0300, Alexey Goncharuk пишет:
> > > > > > > > Nikolay,
> > > > > > > >
> > > > > > > > Local caches and scalar are already in the list :) Added the
> > > outdated
> > > > > > > > metrics point.
> > > > > > > >
> > > > > > > > пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov <
> > > [hidden email]>:
> > > > > > > >
> > > > > > > > > * Scalar.
> > > > > > > > > * LOCAL caches.
> > > > > > > > > * Deprecated metrics.
> > > > > > > > >
> > > > > > > > > В Пн, 17/06/2019 в 15:18 +0300, Alexey Goncharuk пишет:
> > > > > > > > > > Igniters,
> > > > > > > > > >
> > > > > > > > > > Even though we are still planning the Ignite 2.8
> release, I
> > > would
> > > > > > >
> > > > > > > like to
> > > > > > > > > > kick-off a discussion related to Ignite 3.0, because the
> > > efforts
> > > > > >
> > > > > > for
> > > > > > > AI
> > > > > > > > >
> > > > > > > > > 3.0
> > > > > > > > > > will be significantly larger than for AI 2.8, better to
> > start
> > > > > >
> > > > > > early.
> > > > > > > > > >
> > > > > > > > > > As a first step, I would like to discuss the list of
> things
> > > to be
> > > > > > >
> > > > > > > removed
> > > > > > > > > > in Ignite 3.0 (partially this thread is inspired by Denis
> > > Magda's
> > > > > > >
> > > > > > > IGFS
> > > > > > > > > > removal thread). I've separated all to-be-removed points
> > from
> > > > > > >
> > > > > > > existing
> > > > > > > > > > Ignite 3.0 wishlist [1] to a dedicated block and also
> added
> > > a few
> > > > > > >
> > > > > > > more
> > > > > > > > > > things that look right to be dropped.
> > > > > > > > > >
> > > > > > > > > > Please share your thoughts, probably, there are more
> > outdated
> > > > > >
> > > > > > things
> > > > > > > we
> > > > > > > > > > need to add to the wishlist.
> > > > > > > > > >
> > > > > > > > > > As a side question: I think it makes sense to create
> > tickets
> > > for
> > > > > >
> > > > > > such
> > > > > > > > > > improvements, how do we track them. Will the 3.0 version
> > > suffice
> > > > >
> > > > > or
> > > > > > > > >
> > > > > > > > > should
> > > > > > > > > > we add a separate label?
> > >
> >
>

[Nikolay Izhikov-2]

Dmitriy.

When we remove all "features" that is uncommon for the term "client node" what will remain?
Thin client protocol with transactions and P2P feature.

I'm talking about design and naming, not about "documentation and supplementary materials".
We should have clear and consistent design and then explain it to users.

> There are no reasons to write software if users are unaware of how to use
> it. So I do not agree that supplementary materials are unimportant.

I don't say they are unimportant.
I'm saying that we lie to our users with naming in the configuration.
For now, "client node" is not client from any point of view.


В Пн, 17/06/2019 в 18:38 +0300, Dmitriy Pavlov пишет:

> Nikolay,
>
> we can (and probably should) discuss stop deploying caches/services to
> client nodes.
>
> But I would not name it removal of client nodes at all. Any Apache Ignite
> guide I saw is starting from 2 steps: 1) start server node, 2) start client
> node.
>
> There are no reasons to write software if users are unaware of how to use
> it. So I do not agree that supplementary materials are unimportant.
>
> Sincerely,
> Dmitriy Pavlov
>
> пн, 17 июн. 2019 г. в 18:30, Nikolay Izhikov <[hidden email]>:
>
> > Dmitriy,
> >
> > I think the whole concept of "client" nodes is broken.
> > And that's why:
> >
> > Ignite Client node nothing to do with "client" :)
> > We can deploy cache on it, we can execute compute tasks, services on it.
> > "client node" is a node with special join process and some rebalance/PME
> > hacks.
> > And we put many(many!) efforts to support this concept and this hacks.
> >
> > And I'm asking: What value client nodes bring to Ignite?
> >
> > I think, Alexey, already answered correctly:
> >
> > * Transactions support.
> > * P2P deployment.
> >
> > I think we should, definitely, remove concept of "client nodes" in the
> > future.
> > It's about product design decision, in the first place, not about
> > additional materials.
> >
> > The simpler core codebase we have, the more reliable product we ca build
> > with it.
> >
> >
> > В Пн, 17/06/2019 в 18:19 +0300, Dmitriy Pavlov пишет:
> > > Hi Nikolay,
> > >
> > > I think client nodes removal is not possible in the near future because
> >
> > of
> > > tons of usages everywhere outside Ignite code (in products, guides,
> >
> > books,
> > > training, etc.)
> > >
> > > If we have replacement we should encourage users to migrate, but we can't
> > > remove such a core feature.
> > >
> > > Alexey, sure we can discuss removal of modules, why not?
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > пн, 17 июн. 2019 г. в 18:02, Alexey Zinoviev <[hidden email]>:
> > >
> > > > Could we suggest here remove whole modules?
> > > >
> > > > пн, 17 июн. 2019 г. в 16:28, Alexey Goncharuk <
> >
> > [hidden email]
> > > > > :
> > > > > Nikolay,
> > > > >
> > > > > I had this thought too, but I am not too eager to implement it yet.
> >
> > The
> > > > > reason is transaction protocol complexity/performance issues with
> >
> > thin
> > > > > clients.
> > > > >
> > > > > A thick client can communicate with each primary node and coordinate
> > > > > prepare/commit phases. Thin client can only communicate with one
> >
> > node, so
> > > > > the change will mean an additional network hop. Of course, we can
> >
> > make
> > > >
> > > > thin
> > > > > clients implement the same protocol, but it will immediately
> >
> > increase the
> > > > > protocol complexity for all platforms.
> > > > >
> > > > > Plus, we do not have near cache on thin clients, we do not support
> >
> > p2p
> > > > > class deployment, etc. Since thin clients are positioned as
> > > > > platform-agnostic, I do not think it makes sense to expose all
> >
> > feature
> > > >
> > > > set
> > > > > of Igntie to thin clients.
> > > > >
> > > > > Instead, we can significantly simplify client node configuration - it
> > > > > currently requires the same config as a regular Ignite node,
> >
> > however, in
> > > > > most cases, the configuration can be reduced almost to a several
> > > >
> > > > host:port
> > > > > pairs.
> > > > >
> > > > > пн, 17 июн. 2019 г. в 15:58, Nikolay Izhikov <[hidden email]>:
> > > > >
> > > > > > Alexey.
> > > > > >
> > > > > > I want to share a thought (just don't drop it out in one moment :)
> >
> > ).
> > > > > >
> > > > > > Do we really need "client nodes"?
> > > > > >
> > > > > > We have thin client protocol that is a very convenient point to
> > > >
> > > > interact
> > > > > > with Ignite.
> > > > > > So, why, we need one more entity and work mode such as "client
> >
> > node"?
> > > > > >
> > > > > > From my point of view, client nodes were required in the time
> >
> > without a
> > > > > > thin client.
> > > > > > Now, we have it.
> > > > > >
> > > > > > Let's simplify Ignite codebase and drop client nodes!
> > > > > >
> > > > > > How does it sound?
> > > > > >
> > > > > >
> > > > > > В Пн, 17/06/2019 в 15:52 +0300, Alexey Goncharuk пишет:
> > > > > > > Nikolay,
> > > > > > >
> > > > > > > Local caches and scalar are already in the list :) Added the
> >
> > outdated
> > > > > > > metrics point.
> > > > > > >
> > > > > > > пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov <
> >
> > [hidden email]>:
> > > > > > >
> > > > > > > > * Scalar.
> > > > > > > > * LOCAL caches.
> > > > > > > > * Deprecated metrics.
> > > > > > > >
> > > > > > > > В Пн, 17/06/2019 в 15:18 +0300, Alexey Goncharuk пишет:
> > > > > > > > > Igniters,
> > > > > > > > >
> > > > > > > > > Even though we are still planning the Ignite 2.8 release, I
> >
> > would
> > > > > >
> > > > > > like to
> > > > > > > > > kick-off a discussion related to Ignite 3.0, because the
> >
> > efforts
> > > > >
> > > > > for
> > > > > > AI
> > > > > > > >
> > > > > > > > 3.0
> > > > > > > > > will be significantly larger than for AI 2.8, better to start
> > > > >
> > > > > early.
> > > > > > > > >
> > > > > > > > > As a first step, I would like to discuss the list of things
> >
> > to be
> > > > > >
> > > > > > removed
> > > > > > > > > in Ignite 3.0 (partially this thread is inspired by Denis
> >
> > Magda's
> > > > > >
> > > > > > IGFS
> > > > > > > > > removal thread). I've separated all to-be-removed points from
> > > > > >
> > > > > > existing
> > > > > > > > > Ignite 3.0 wishlist [1] to a dedicated block and also added
> >
> > a few
> > > > > >
> > > > > > more
> > > > > > > > > things that look right to be dropped.
> > > > > > > > >
> > > > > > > > > Please share your thoughts, probably, there are more outdated
> > > > >
> > > > > things
> > > > > > we
> > > > > > > > > need to add to the wishlist.
> > > > > > > > >
> > > > > > > > > As a side question: I think it makes sense to create tickets
> >
> > for
> > > > >
> > > > > such
> > > > > > > > > improvements, how do we track them. Will the 3.0 version
> >
> > suffice
> > > >
> > > > or
> > > > > > > >
> > > > > > > > should
> > > > > > > > > we add a separate label?

[Pavel Tupitsyn]

Big changes for .NET:
* Remove legacy Entity Framework integration
* Remove legacy ASP.NET integration
* Move from .NET Framework 4.0 (released in 2010) to .NET Standard 2.0
(modern way to build libraries)

Thanks,
Pavel

On Mon, Jun 17, 2019 at 7:14 PM Igor Sapego <[hidden email]> wrote:

> For the C++ I propose to drop support of VS 2010 and move to
> at least 2012 (or, better yet 2013).
>
> Also, I'd drop x86 support for everything except for maybe ODBC.
>
> Best Regards,
> Igor
>
> On Mon, Jun 17, 2019 at 7:12 PM Pavel Kovalenko <[hidden email]>
> wrote:
>
> > I would like to add to the list following:
> >
> > 1. Remove ForceKeyRequests and related code. Since we have Late affinity
> > assignment and primary node partitions are always up to date we don't
> need
> > to request actual data from backups.
> > 2. Remove @CentralizedAffinityFunction and related code. I don't see any
> > real usages of custom affinity functions that use this annotation.
> > 3. Leave Exchanges Merge + Late Affinity assignment as the only PME
> > protocol. Remove centralized affinity distribution in case of node left
> and
> > no merge exchange legacy modes.
> > 4. Remove CacheRebalanceMode.NONE and Rebalance Delay as it can break
> data
> > consistency in a cluster. Also, remove force rebalance mode as it can be
> > used only if rebalance delay is set.
> >
> > пн, 17 июн. 2019 г. в 18:39, Dmitriy Pavlov <[hidden email]>:
> >
> > > Nikolay,
> > >
> > > we can (and probably should) discuss stop deploying caches/services to
> > > client nodes.
> > >
> > > But I would not name it removal of client nodes at all. Any Apache
> Ignite
> > > guide I saw is starting from 2 steps: 1) start server node, 2) start
> > client
> > > node.
> > >
> > > There are no reasons to write software if users are unaware of how to
> use
> > > it. So I do not agree that supplementary materials are unimportant.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > пн, 17 июн. 2019 г. в 18:30, Nikolay Izhikov <[hidden email]>:
> > >
> > > > Dmitriy,
> > > >
> > > > I think the whole concept of "client" nodes is broken.
> > > > And that's why:
> > > >
> > > > Ignite Client node nothing to do with "client" :)
> > > > We can deploy cache on it, we can execute compute tasks, services on
> > it.
> > > > "client node" is a node with special join process and some
> > rebalance/PME
> > > > hacks.
> > > > And we put many(many!) efforts to support this concept and this
> hacks.
> > > >
> > > > And I'm asking: What value client nodes bring to Ignite?
> > > >
> > > > I think, Alexey, already answered correctly:
> > > >
> > > > * Transactions support.
> > > > * P2P deployment.
> > > >
> > > > I think we should, definitely, remove concept of "client nodes" in
> the
> > > > future.
> > > > It's about product design decision, in the first place, not about
> > > > additional materials.
> > > >
> > > > The simpler core codebase we have, the more reliable product we ca
> > build
> > > > with it.
> > > >
> > > >
> > > > В Пн, 17/06/2019 в 18:19 +0300, Dmitriy Pavlov пишет:
> > > > > Hi Nikolay,
> > > > >
> > > > > I think client nodes removal is not possible in the near future
> > because
> > > > of
> > > > > tons of usages everywhere outside Ignite code (in products, guides,
> > > > books,
> > > > > training, etc.)
> > > > >
> > > > > If we have replacement we should encourage users to migrate, but we
> > > can't
> > > > > remove such a core feature.
> > > > >
> > > > > Alexey, sure we can discuss removal of modules, why not?
> > > > >
> > > > > Sincerely,
> > > > > Dmitriy Pavlov
> > > > >
> > > > > пн, 17 июн. 2019 г. в 18:02, Alexey Zinoviev <
> [hidden email]
> > >:
> > > > >
> > > > > > Could we suggest here remove whole modules?
> > > > > >
> > > > > > пн, 17 июн. 2019 г. в 16:28, Alexey Goncharuk <
> > > > [hidden email]
> > > > > > > :
> > > > > > > Nikolay,
> > > > > > >
> > > > > > > I had this thought too, but I am not too eager to implement it
> > yet.
> > > > The
> > > > > > > reason is transaction protocol complexity/performance issues
> with
> > > > thin
> > > > > > > clients.
> > > > > > >
> > > > > > > A thick client can communicate with each primary node and
> > > coordinate
> > > > > > > prepare/commit phases. Thin client can only communicate with
> one
> > > > node, so
> > > > > > > the change will mean an additional network hop. Of course, we
> can
> > > > make
> > > > > >
> > > > > > thin
> > > > > > > clients implement the same protocol, but it will immediately
> > > > increase the
> > > > > > > protocol complexity for all platforms.
> > > > > > >
> > > > > > > Plus, we do not have near cache on thin clients, we do not
> > support
> > > > p2p
> > > > > > > class deployment, etc. Since thin clients are positioned as
> > > > > > > platform-agnostic, I do not think it makes sense to expose all
> > > > feature
> > > > > >
> > > > > > set
> > > > > > > of Igntie to thin clients.
> > > > > > >
> > > > > > > Instead, we can significantly simplify client node
> configuration
> > -
> > > it
> > > > > > > currently requires the same config as a regular Ignite node,
> > > > however, in
> > > > > > > most cases, the configuration can be reduced almost to a
> several
> > > > > >
> > > > > > host:port
> > > > > > > pairs.
> > > > > > >
> > > > > > > пн, 17 июн. 2019 г. в 15:58, Nikolay Izhikov <
> > [hidden email]
> > > >:
> > > > > > >
> > > > > > > > Alexey.
> > > > > > > >
> > > > > > > > I want to share a thought (just don't drop it out in one
> moment
> > > :)
> > > > ).
> > > > > > > >
> > > > > > > > Do we really need "client nodes"?
> > > > > > > >
> > > > > > > > We have thin client protocol that is a very convenient point
> to
> > > > > >
> > > > > > interact
> > > > > > > > with Ignite.
> > > > > > > > So, why, we need one more entity and work mode such as
> "client
> > > > node"?
> > > > > > > >
> > > > > > > > From my point of view, client nodes were required in the time
> > > > without a
> > > > > > > > thin client.
> > > > > > > > Now, we have it.
> > > > > > > >
> > > > > > > > Let's simplify Ignite codebase and drop client nodes!
> > > > > > > >
> > > > > > > > How does it sound?
> > > > > > > >
> > > > > > > >
> > > > > > > > В Пн, 17/06/2019 в 15:52 +0300, Alexey Goncharuk пишет:
> > > > > > > > > Nikolay,
> > > > > > > > >
> > > > > > > > > Local caches and scalar are already in the list :) Added
> the
> > > > outdated
> > > > > > > > > metrics point.
> > > > > > > > >
> > > > > > > > > пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov <
> > > > [hidden email]>:
> > > > > > > > >
> > > > > > > > > > * Scalar.
> > > > > > > > > > * LOCAL caches.
> > > > > > > > > > * Deprecated metrics.
> > > > > > > > > >
> > > > > > > > > > В Пн, 17/06/2019 в 15:18 +0300, Alexey Goncharuk пишет:
> > > > > > > > > > > Igniters,
> > > > > > > > > > >
> > > > > > > > > > > Even though we are still planning the Ignite 2.8
> > release, I
> > > > would
> > > > > > > >
> > > > > > > > like to
> > > > > > > > > > > kick-off a discussion related to Ignite 3.0, because
> the
> > > > efforts
> > > > > > >
> > > > > > > for
> > > > > > > > AI
> > > > > > > > > >
> > > > > > > > > > 3.0
> > > > > > > > > > > will be significantly larger than for AI 2.8, better to
> > > start
> > > > > > >
> > > > > > > early.
> > > > > > > > > > >
> > > > > > > > > > > As a first step, I would like to discuss the list of
> > things
> > > > to be
> > > > > > > >
> > > > > > > > removed
> > > > > > > > > > > in Ignite 3.0 (partially this thread is inspired by
> Denis
> > > > Magda's
> > > > > > > >
> > > > > > > > IGFS
> > > > > > > > > > > removal thread). I've separated all to-be-removed
> points
> > > from
> > > > > > > >
> > > > > > > > existing
> > > > > > > > > > > Ignite 3.0 wishlist [1] to a dedicated block and also
> > added
> > > > a few
> > > > > > > >
> > > > > > > > more
> > > > > > > > > > > things that look right to be dropped.
> > > > > > > > > > >
> > > > > > > > > > > Please share your thoughts, probably, there are more
> > > outdated
> > > > > > >
> > > > > > > things
> > > > > > > > we
> > > > > > > > > > > need to add to the wishlist.
> > > > > > > > > > >
> > > > > > > > > > > As a side question: I think it makes sense to create
> > > tickets
> > > > for
> > > > > > >
> > > > > > > such
> > > > > > > > > > > improvements, how do we track them. Will the 3.0
> version
> > > > suffice
> > > > > >
> > > > > > or
> > > > > > > > > >
> > > > > > > > > > should
> > > > > > > > > > > we add a separate label?
> > > >
> > >
> >
>

[Alexey Plekhanov]

Remove "force server mode" for client nodes (already was discussed on dev
list earlier [1]).

[1] :
http://apache-ignite-developers.2346864.n4.nabble.com/Deprecate-force-server-mode-for-clients-td33614.html

пн, 17 июн. 2019 г. в 19:22, Pavel Tupitsyn <[hidden email]>:

> Big changes for .NET:
> * Remove legacy Entity Framework integration
> * Remove legacy ASP.NET integration
> * Move from .NET Framework 4.0 (released in 2010) to .NET Standard 2.0
> (modern way to build libraries)
>
> Thanks,
> Pavel
>
> On Mon, Jun 17, 2019 at 7:14 PM Igor Sapego <[hidden email]> wrote:
>
> > For the C++ I propose to drop support of VS 2010 and move to
> > at least 2012 (or, better yet 2013).
> >
> > Also, I'd drop x86 support for everything except for maybe ODBC.
> >
> > Best Regards,
> > Igor
> >
> > On Mon, Jun 17, 2019 at 7:12 PM Pavel Kovalenko <[hidden email]>
> > wrote:
> >
> > > I would like to add to the list following:
> > >
> > > 1. Remove ForceKeyRequests and related code. Since we have Late
> affinity
> > > assignment and primary node partitions are always up to date we don't
> > need
> > > to request actual data from backups.
> > > 2. Remove @CentralizedAffinityFunction and related code. I don't see
> any
> > > real usages of custom affinity functions that use this annotation.
> > > 3. Leave Exchanges Merge + Late Affinity assignment as the only PME
> > > protocol. Remove centralized affinity distribution in case of node left
> > and
> > > no merge exchange legacy modes.
> > > 4. Remove CacheRebalanceMode.NONE and Rebalance Delay as it can break
> > data
> > > consistency in a cluster. Also, remove force rebalance mode as it can
> be
> > > used only if rebalance delay is set.
> > >
> > > пн, 17 июн. 2019 г. в 18:39, Dmitriy Pavlov <[hidden email]>:
> > >
> > > > Nikolay,
> > > >
> > > > we can (and probably should) discuss stop deploying caches/services
> to
> > > > client nodes.
> > > >
> > > > But I would not name it removal of client nodes at all. Any Apache
> > Ignite
> > > > guide I saw is starting from 2 steps: 1) start server node, 2) start
> > > client
> > > > node.
> > > >
> > > > There are no reasons to write software if users are unaware of how to
> > use
> > > > it. So I do not agree that supplementary materials are unimportant.
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > пн, 17 июн. 2019 г. в 18:30, Nikolay Izhikov <[hidden email]>:
> > > >
> > > > > Dmitriy,
> > > > >
> > > > > I think the whole concept of "client" nodes is broken.
> > > > > And that's why:
> > > > >
> > > > > Ignite Client node nothing to do with "client" :)
> > > > > We can deploy cache on it, we can execute compute tasks, services
> on
> > > it.
> > > > > "client node" is a node with special join process and some
> > > rebalance/PME
> > > > > hacks.
> > > > > And we put many(many!) efforts to support this concept and this
> > hacks.
> > > > >
> > > > > And I'm asking: What value client nodes bring to Ignite?
> > > > >
> > > > > I think, Alexey, already answered correctly:
> > > > >
> > > > > * Transactions support.
> > > > > * P2P deployment.
> > > > >
> > > > > I think we should, definitely, remove concept of "client nodes" in
> > the
> > > > > future.
> > > > > It's about product design decision, in the first place, not about
> > > > > additional materials.
> > > > >
> > > > > The simpler core codebase we have, the more reliable product we ca
> > > build
> > > > > with it.
> > > > >
> > > > >
> > > > > В Пн, 17/06/2019 в 18:19 +0300, Dmitriy Pavlov пишет:
> > > > > > Hi Nikolay,
> > > > > >
> > > > > > I think client nodes removal is not possible in the near future
> > > because
> > > > > of
> > > > > > tons of usages everywhere outside Ignite code (in products,
> guides,
> > > > > books,
> > > > > > training, etc.)
> > > > > >
> > > > > > If we have replacement we should encourage users to migrate, but
> we
> > > > can't
> > > > > > remove such a core feature.
> > > > > >
> > > > > > Alexey, sure we can discuss removal of modules, why not?
> > > > > >
> > > > > > Sincerely,
> > > > > > Dmitriy Pavlov
> > > > > >
> > > > > > пн, 17 июн. 2019 г. в 18:02, Alexey Zinoviev <
> > [hidden email]
> > > >:
> > > > > >
> > > > > > > Could we suggest here remove whole modules?
> > > > > > >
> > > > > > > пн, 17 июн. 2019 г. в 16:28, Alexey Goncharuk <
> > > > > [hidden email]
> > > > > > > > :
> > > > > > > > Nikolay,
> > > > > > > >
> > > > > > > > I had this thought too, but I am not too eager to implement
> it
> > > yet.
> > > > > The
> > > > > > > > reason is transaction protocol complexity/performance issues
> > with
> > > > > thin
> > > > > > > > clients.
> > > > > > > >
> > > > > > > > A thick client can communicate with each primary node and
> > > > coordinate
> > > > > > > > prepare/commit phases. Thin client can only communicate with
> > one
> > > > > node, so
> > > > > > > > the change will mean an additional network hop. Of course, we
> > can
> > > > > make
> > > > > > >
> > > > > > > thin
> > > > > > > > clients implement the same protocol, but it will immediately
> > > > > increase the
> > > > > > > > protocol complexity for all platforms.
> > > > > > > >
> > > > > > > > Plus, we do not have near cache on thin clients, we do not
> > > support
> > > > > p2p
> > > > > > > > class deployment, etc. Since thin clients are positioned as
> > > > > > > > platform-agnostic, I do not think it makes sense to expose
> all
> > > > > feature
> > > > > > >
> > > > > > > set
> > > > > > > > of Igntie to thin clients.
> > > > > > > >
> > > > > > > > Instead, we can significantly simplify client node
> > configuration
> > > -
> > > > it
> > > > > > > > currently requires the same config as a regular Ignite node,
> > > > > however, in
> > > > > > > > most cases, the configuration can be reduced almost to a
> > several
> > > > > > >
> > > > > > > host:port
> > > > > > > > pairs.
> > > > > > > >
> > > > > > > > пн, 17 июн. 2019 г. в 15:58, Nikolay Izhikov <
> > > [hidden email]
> > > > >:
> > > > > > > >
> > > > > > > > > Alexey.
> > > > > > > > >
> > > > > > > > > I want to share a thought (just don't drop it out in one
> > moment
> > > > :)
> > > > > ).
> > > > > > > > >
> > > > > > > > > Do we really need "client nodes"?
> > > > > > > > >
> > > > > > > > > We have thin client protocol that is a very convenient
> point
> > to
> > > > > > >
> > > > > > > interact
> > > > > > > > > with Ignite.
> > > > > > > > > So, why, we need one more entity and work mode such as
> > "client
> > > > > node"?
> > > > > > > > >
> > > > > > > > > From my point of view, client nodes were required in the
> time
> > > > > without a
> > > > > > > > > thin client.
> > > > > > > > > Now, we have it.
> > > > > > > > >
> > > > > > > > > Let's simplify Ignite codebase and drop client nodes!
> > > > > > > > >
> > > > > > > > > How does it sound?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > В Пн, 17/06/2019 в 15:52 +0300, Alexey Goncharuk пишет:
> > > > > > > > > > Nikolay,
> > > > > > > > > >
> > > > > > > > > > Local caches and scalar are already in the list :) Added
> > the
> > > > > outdated
> > > > > > > > > > metrics point.
> > > > > > > > > >
> > > > > > > > > > пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov <
> > > > > [hidden email]>:
> > > > > > > > > >
> > > > > > > > > > > * Scalar.
> > > > > > > > > > > * LOCAL caches.
> > > > > > > > > > > * Deprecated metrics.
> > > > > > > > > > >
> > > > > > > > > > > В Пн, 17/06/2019 в 15:18 +0300, Alexey Goncharuk пишет:
> > > > > > > > > > > > Igniters,
> > > > > > > > > > > >
> > > > > > > > > > > > Even though we are still planning the Ignite 2.8
> > > release, I
> > > > > would
> > > > > > > > >
> > > > > > > > > like to
> > > > > > > > > > > > kick-off a discussion related to Ignite 3.0, because
> > the
> > > > > efforts
> > > > > > > >
> > > > > > > > for
> > > > > > > > > AI
> > > > > > > > > > >
> > > > > > > > > > > 3.0
> > > > > > > > > > > > will be significantly larger than for AI 2.8, better
> to
> > > > start
> > > > > > > >
> > > > > > > > early.
> > > > > > > > > > > >
> > > > > > > > > > > > As a first step, I would like to discuss the list of
> > > things
> > > > > to be
> > > > > > > > >
> > > > > > > > > removed
> > > > > > > > > > > > in Ignite 3.0 (partially this thread is inspired by
> > Denis
> > > > > Magda's
> > > > > > > > >
> > > > > > > > > IGFS
> > > > > > > > > > > > removal thread). I've separated all to-be-removed
> > points
> > > > from
> > > > > > > > >
> > > > > > > > > existing
> > > > > > > > > > > > Ignite 3.0 wishlist [1] to a dedicated block and also
> > > added
> > > > > a few
> > > > > > > > >
> > > > > > > > > more
> > > > > > > > > > > > things that look right to be dropped.
> > > > > > > > > > > >
> > > > > > > > > > > > Please share your thoughts, probably, there are more
> > > > outdated
> > > > > > > >
> > > > > > > > things
> > > > > > > > > we
> > > > > > > > > > > > need to add to the wishlist.
> > > > > > > > > > > >
> > > > > > > > > > > > As a side question: I think it makes sense to create
> > > > tickets
> > > > > for
> > > > > > > >
> > > > > > > > such
> > > > > > > > > > > > improvements, how do we track them. Will the 3.0
> > version
> > > > > suffice
> > > > > > >
> > > > > > > or
> > > > > > > > > > >
> > > > > > > > > > > should
> > > > > > > > > > > > we add a separate label?
> > > > >
> > > >
> > >
> >
>

[Alexey Goncharuk]

Folks,

May I ask you to add the mentioned points to the wishlist to keep them in
one place for convenience?

вт, 18 июн. 2019 г. в 00:19, Alex Plehanov <[hidden email]>:

> Remove "force server mode" for client nodes (already was discussed on dev
> list earlier [1]).
>
> [1] :
>
> http://apache-ignite-developers.2346864.n4.nabble.com/Deprecate-force-server-mode-for-clients-td33614.html
>
> пн, 17 июн. 2019 г. в 19:22, Pavel Tupitsyn <[hidden email]>:
>
> > Big changes for .NET:
> > * Remove legacy Entity Framework integration
> > * Remove legacy ASP.NET integration
> > * Move from .NET Framework 4.0 (released in 2010) to .NET Standard 2.0
> > (modern way to build libraries)
> >
> > Thanks,
> > Pavel
> >
> > On Mon, Jun 17, 2019 at 7:14 PM Igor Sapego <[hidden email]>
> wrote:
> >
> > > For the C++ I propose to drop support of VS 2010 and move to
> > > at least 2012 (or, better yet 2013).
> > >
> > > Also, I'd drop x86 support for everything except for maybe ODBC.
> > >
> > > Best Regards,
> > > Igor
> > >
> > > On Mon, Jun 17, 2019 at 7:12 PM Pavel Kovalenko <[hidden email]>
> > > wrote:
> > >
> > > > I would like to add to the list following:
> > > >
> > > > 1. Remove ForceKeyRequests and related code. Since we have Late
> > affinity
> > > > assignment and primary node partitions are always up to date we don't
> > > need
> > > > to request actual data from backups.
> > > > 2. Remove @CentralizedAffinityFunction and related code. I don't see
> > any
> > > > real usages of custom affinity functions that use this annotation.
> > > > 3. Leave Exchanges Merge + Late Affinity assignment as the only PME
> > > > protocol. Remove centralized affinity distribution in case of node
> left
> > > and
> > > > no merge exchange legacy modes.
> > > > 4. Remove CacheRebalanceMode.NONE and Rebalance Delay as it can break
> > > data
> > > > consistency in a cluster. Also, remove force rebalance mode as it can
> > be
> > > > used only if rebalance delay is set.
> > > >
> > > > пн, 17 июн. 2019 г. в 18:39, Dmitriy Pavlov <[hidden email]>:
> > > >
> > > > > Nikolay,
> > > > >
> > > > > we can (and probably should) discuss stop deploying caches/services
> > to
> > > > > client nodes.
> > > > >
> > > > > But I would not name it removal of client nodes at all. Any Apache
> > > Ignite
> > > > > guide I saw is starting from 2 steps: 1) start server node, 2)
> start
> > > > client
> > > > > node.
> > > > >
> > > > > There are no reasons to write software if users are unaware of how
> to
> > > use
> > > > > it. So I do not agree that supplementary materials are unimportant.
> > > > >
> > > > > Sincerely,
> > > > > Dmitriy Pavlov
> > > > >
> > > > > пн, 17 июн. 2019 г. в 18:30, Nikolay Izhikov <[hidden email]
> >:
> > > > >
> > > > > > Dmitriy,
> > > > > >
> > > > > > I think the whole concept of "client" nodes is broken.
> > > > > > And that's why:
> > > > > >
> > > > > > Ignite Client node nothing to do with "client" :)
> > > > > > We can deploy cache on it, we can execute compute tasks, services
> > on
> > > > it.
> > > > > > "client node" is a node with special join process and some
> > > > rebalance/PME
> > > > > > hacks.
> > > > > > And we put many(many!) efforts to support this concept and this
> > > hacks.
> > > > > >
> > > > > > And I'm asking: What value client nodes bring to Ignite?
> > > > > >
> > > > > > I think, Alexey, already answered correctly:
> > > > > >
> > > > > > * Transactions support.
> > > > > > * P2P deployment.
> > > > > >
> > > > > > I think we should, definitely, remove concept of "client nodes"
> in
> > > the
> > > > > > future.
> > > > > > It's about product design decision, in the first place, not about
> > > > > > additional materials.
> > > > > >
> > > > > > The simpler core codebase we have, the more reliable product we
> ca
> > > > build
> > > > > > with it.
> > > > > >
> > > > > >
> > > > > > В Пн, 17/06/2019 в 18:19 +0300, Dmitriy Pavlov пишет:
> > > > > > > Hi Nikolay,
> > > > > > >
> > > > > > > I think client nodes removal is not possible in the near future
> > > > because
> > > > > > of
> > > > > > > tons of usages everywhere outside Ignite code (in products,
> > guides,
> > > > > > books,
> > > > > > > training, etc.)
> > > > > > >
> > > > > > > If we have replacement we should encourage users to migrate,
> but
> > we
> > > > > can't
> > > > > > > remove such a core feature.
> > > > > > >
> > > > > > > Alexey, sure we can discuss removal of modules, why not?
> > > > > > >
> > > > > > > Sincerely,
> > > > > > > Dmitriy Pavlov
> > > > > > >
> > > > > > > пн, 17 июн. 2019 г. в 18:02, Alexey Zinoviev <
> > > [hidden email]
> > > > >:
> > > > > > >
> > > > > > > > Could we suggest here remove whole modules?
> > > > > > > >
> > > > > > > > пн, 17 июн. 2019 г. в 16:28, Alexey Goncharuk <
> > > > > > [hidden email]
> > > > > > > > > :
> > > > > > > > > Nikolay,
> > > > > > > > >
> > > > > > > > > I had this thought too, but I am not too eager to implement
> > it
> > > > yet.
> > > > > > The
> > > > > > > > > reason is transaction protocol complexity/performance
> issues
> > > with
> > > > > > thin
> > > > > > > > > clients.
> > > > > > > > >
> > > > > > > > > A thick client can communicate with each primary node and
> > > > > coordinate
> > > > > > > > > prepare/commit phases. Thin client can only communicate
> with
> > > one
> > > > > > node, so
> > > > > > > > > the change will mean an additional network hop. Of course,
> we
> > > can
> > > > > > make
> > > > > > > >
> > > > > > > > thin
> > > > > > > > > clients implement the same protocol, but it will
> immediately
> > > > > > increase the
> > > > > > > > > protocol complexity for all platforms.
> > > > > > > > >
> > > > > > > > > Plus, we do not have near cache on thin clients, we do not
> > > > support
> > > > > > p2p
> > > > > > > > > class deployment, etc. Since thin clients are positioned as
> > > > > > > > > platform-agnostic, I do not think it makes sense to expose
> > all
> > > > > > feature
> > > > > > > >
> > > > > > > > set
> > > > > > > > > of Igntie to thin clients.
> > > > > > > > >
> > > > > > > > > Instead, we can significantly simplify client node
> > > configuration
> > > > -
> > > > > it
> > > > > > > > > currently requires the same config as a regular Ignite
> node,
> > > > > > however, in
> > > > > > > > > most cases, the configuration can be reduced almost to a
> > > several
> > > > > > > >
> > > > > > > > host:port
> > > > > > > > > pairs.
> > > > > > > > >
> > > > > > > > > пн, 17 июн. 2019 г. в 15:58, Nikolay Izhikov <
> > > > [hidden email]
> > > > > >:
> > > > > > > > >
> > > > > > > > > > Alexey.
> > > > > > > > > >
> > > > > > > > > > I want to share a thought (just don't drop it out in one
> > > moment
> > > > > :)
> > > > > > ).
> > > > > > > > > >
> > > > > > > > > > Do we really need "client nodes"?
> > > > > > > > > >
> > > > > > > > > > We have thin client protocol that is a very convenient
> > point
> > > to
> > > > > > > >
> > > > > > > > interact
> > > > > > > > > > with Ignite.
> > > > > > > > > > So, why, we need one more entity and work mode such as
> > > "client
> > > > > > node"?
> > > > > > > > > >
> > > > > > > > > > From my point of view, client nodes were required in the
> > time
> > > > > > without a
> > > > > > > > > > thin client.
> > > > > > > > > > Now, we have it.
> > > > > > > > > >
> > > > > > > > > > Let's simplify Ignite codebase and drop client nodes!
> > > > > > > > > >
> > > > > > > > > > How does it sound?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > В Пн, 17/06/2019 в 15:52 +0300, Alexey Goncharuk пишет:
> > > > > > > > > > > Nikolay,
> > > > > > > > > > >
> > > > > > > > > > > Local caches and scalar are already in the list :)
> Added
> > > the
> > > > > > outdated
> > > > > > > > > > > metrics point.
> > > > > > > > > > >
> > > > > > > > > > > пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov <
> > > > > > [hidden email]>:
> > > > > > > > > > >
> > > > > > > > > > > > * Scalar.
> > > > > > > > > > > > * LOCAL caches.
> > > > > > > > > > > > * Deprecated metrics.
> > > > > > > > > > > >
> > > > > > > > > > > > В Пн, 17/06/2019 в 15:18 +0300, Alexey Goncharuk
> пишет:
> > > > > > > > > > > > > Igniters,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Even though we are still planning the Ignite 2.8
> > > > release, I
> > > > > > would
> > > > > > > > > >
> > > > > > > > > > like to
> > > > > > > > > > > > > kick-off a discussion related to Ignite 3.0,
> because
> > > the
> > > > > > efforts
> > > > > > > > >
> > > > > > > > > for
> > > > > > > > > > AI
> > > > > > > > > > > >
> > > > > > > > > > > > 3.0
> > > > > > > > > > > > > will be significantly larger than for AI 2.8,
> better
> > to
> > > > > start
> > > > > > > > >
> > > > > > > > > early.
> > > > > > > > > > > > >
> > > > > > > > > > > > > As a first step, I would like to discuss the list
> of
> > > > things
> > > > > > to be
> > > > > > > > > >
> > > > > > > > > > removed
> > > > > > > > > > > > > in Ignite 3.0 (partially this thread is inspired by
> > > Denis
> > > > > > Magda's
> > > > > > > > > >
> > > > > > > > > > IGFS
> > > > > > > > > > > > > removal thread). I've separated all to-be-removed
> > > points
> > > > > from
> > > > > > > > > >
> > > > > > > > > > existing
> > > > > > > > > > > > > Ignite 3.0 wishlist [1] to a dedicated block and
> also
> > > > added
> > > > > > a few
> > > > > > > > > >
> > > > > > > > > > more
> > > > > > > > > > > > > things that look right to be dropped.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Please share your thoughts, probably, there are
> more
> > > > > outdated
> > > > > > > > >
> > > > > > > > > things
> > > > > > > > > > we
> > > > > > > > > > > > > need to add to the wishlist.
> > > > > > > > > > > > >
> > > > > > > > > > > > > As a side question: I think it makes sense to
> create
> > > > > tickets
> > > > > > for
> > > > > > > > >
> > > > > > > > > such
> > > > > > > > > > > > > improvements, how do we track them. Will the 3.0
> > > version
> > > > > > suffice
> > > > > > > >
> > > > > > > > or
> > > > > > > > > > > >
> > > > > > > > > > > > should
> > > > > > > > > > > > > we add a separate label?
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Andrew Mashenkov]

Also,
* Get rid of old services.
* Make system cache non-persistent or even more - drop it. Discussion on
dev list [1].

I have no permissions to edit wiki page and would glad if someone add all
thoughts from this thread.

[1]
http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-System-cache-persistence-td41158.html

On Tue, Jun 18, 2019 at 10:33 AM Alexey Goncharuk <
[hidden email]> wrote:

> Folks,
>
> May I ask you to add the mentioned points to the wishlist to keep them in
> one place for convenience?
>
> вт, 18 июн. 2019 г. в 00:19, Alex Plehanov <[hidden email]>:
>
> > Remove "force server mode" for client nodes (already was discussed on dev
> > list earlier [1]).
> >
> > [1] :
> >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Deprecate-force-server-mode-for-clients-td33614.html
> >
> > пн, 17 июн. 2019 г. в 19:22, Pavel Tupitsyn <[hidden email]>:
> >
> > > Big changes for .NET:
> > > * Remove legacy Entity Framework integration
> > > * Remove legacy ASP.NET integration
> > > * Move from .NET Framework 4.0 (released in 2010) to .NET Standard 2.0
> > > (modern way to build libraries)
> > >
> > > Thanks,
> > > Pavel
> > >
> > > On Mon, Jun 17, 2019 at 7:14 PM Igor Sapego <[hidden email]>
> > wrote:
> > >
> > > > For the C++ I propose to drop support of VS 2010 and move to
> > > > at least 2012 (or, better yet 2013).
> > > >
> > > > Also, I'd drop x86 support for everything except for maybe ODBC.
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > > On Mon, Jun 17, 2019 at 7:12 PM Pavel Kovalenko <[hidden email]>
> > > > wrote:
> > > >
> > > > > I would like to add to the list following:
> > > > >
> > > > > 1. Remove ForceKeyRequests and related code. Since we have Late
> > > affinity
> > > > > assignment and primary node partitions are always up to date we
> don't
> > > > need
> > > > > to request actual data from backups.
> > > > > 2. Remove @CentralizedAffinityFunction and related code. I don't
> see
> > > any
> > > > > real usages of custom affinity functions that use this annotation.
> > > > > 3. Leave Exchanges Merge + Late Affinity assignment as the only PME
> > > > > protocol. Remove centralized affinity distribution in case of node
> > left
> > > > and
> > > > > no merge exchange legacy modes.
> > > > > 4. Remove CacheRebalanceMode.NONE and Rebalance Delay as it can
> break
> > > > data
> > > > > consistency in a cluster. Also, remove force rebalance mode as it
> can
> > > be
> > > > > used only if rebalance delay is set.
> > > > >
> > > > > пн, 17 июн. 2019 г. в 18:39, Dmitriy Pavlov <[hidden email]>:
> > > > >
> > > > > > Nikolay,
> > > > > >
> > > > > > we can (and probably should) discuss stop deploying
> caches/services
> > > to
> > > > > > client nodes.
> > > > > >
> > > > > > But I would not name it removal of client nodes at all. Any
> Apache
> > > > Ignite
> > > > > > guide I saw is starting from 2 steps: 1) start server node, 2)
> > start
> > > > > client
> > > > > > node.
> > > > > >
> > > > > > There are no reasons to write software if users are unaware of
> how
> > to
> > > > use
> > > > > > it. So I do not agree that supplementary materials are
> unimportant.
> > > > > >
> > > > > > Sincerely,
> > > > > > Dmitriy Pavlov
> > > > > >
> > > > > > пн, 17 июн. 2019 г. в 18:30, Nikolay Izhikov <
> [hidden email]
> > >:
> > > > > >
> > > > > > > Dmitriy,
> > > > > > >
> > > > > > > I think the whole concept of "client" nodes is broken.
> > > > > > > And that's why:
> > > > > > >
> > > > > > > Ignite Client node nothing to do with "client" :)
> > > > > > > We can deploy cache on it, we can execute compute tasks,
> services
> > > on
> > > > > it.
> > > > > > > "client node" is a node with special join process and some
> > > > > rebalance/PME
> > > > > > > hacks.
> > > > > > > And we put many(many!) efforts to support this concept and this
> > > > hacks.
> > > > > > >
> > > > > > > And I'm asking: What value client nodes bring to Ignite?
> > > > > > >
> > > > > > > I think, Alexey, already answered correctly:
> > > > > > >
> > > > > > > * Transactions support.
> > > > > > > * P2P deployment.
> > > > > > >
> > > > > > > I think we should, definitely, remove concept of "client nodes"
> > in
> > > > the
> > > > > > > future.
> > > > > > > It's about product design decision, in the first place, not
> about
> > > > > > > additional materials.
> > > > > > >
> > > > > > > The simpler core codebase we have, the more reliable product we
> > ca
> > > > > build
> > > > > > > with it.
> > > > > > >
> > > > > > >
> > > > > > > В Пн, 17/06/2019 в 18:19 +0300, Dmitriy Pavlov пишет:
> > > > > > > > Hi Nikolay,
> > > > > > > >
> > > > > > > > I think client nodes removal is not possible in the near
> future
> > > > > because
> > > > > > > of
> > > > > > > > tons of usages everywhere outside Ignite code (in products,
> > > guides,
> > > > > > > books,
> > > > > > > > training, etc.)
> > > > > > > >
> > > > > > > > If we have replacement we should encourage users to migrate,
> > but
> > > we
> > > > > > can't
> > > > > > > > remove such a core feature.
> > > > > > > >
> > > > > > > > Alexey, sure we can discuss removal of modules, why not?
> > > > > > > >
> > > > > > > > Sincerely,
> > > > > > > > Dmitriy Pavlov
> > > > > > > >
> > > > > > > > пн, 17 июн. 2019 г. в 18:02, Alexey Zinoviev <
> > > > [hidden email]
> > > > > >:
> > > > > > > >
> > > > > > > > > Could we suggest here remove whole modules?
> > > > > > > > >
> > > > > > > > > пн, 17 июн. 2019 г. в 16:28, Alexey Goncharuk <
> > > > > > > [hidden email]
> > > > > > > > > > :
> > > > > > > > > > Nikolay,
> > > > > > > > > >
> > > > > > > > > > I had this thought too, but I am not too eager to
> implement
> > > it
> > > > > yet.
> > > > > > > The
> > > > > > > > > > reason is transaction protocol complexity/performance
> > issues
> > > > with
> > > > > > > thin
> > > > > > > > > > clients.
> > > > > > > > > >
> > > > > > > > > > A thick client can communicate with each primary node and
> > > > > > coordinate
> > > > > > > > > > prepare/commit phases. Thin client can only communicate
> > with
> > > > one
> > > > > > > node, so
> > > > > > > > > > the change will mean an additional network hop. Of
> course,
> > we
> > > > can
> > > > > > > make
> > > > > > > > >
> > > > > > > > > thin
> > > > > > > > > > clients implement the same protocol, but it will
> > immediately
> > > > > > > increase the
> > > > > > > > > > protocol complexity for all platforms.
> > > > > > > > > >
> > > > > > > > > > Plus, we do not have near cache on thin clients, we do
> not
> > > > > support
> > > > > > > p2p
> > > > > > > > > > class deployment, etc. Since thin clients are positioned
> as
> > > > > > > > > > platform-agnostic, I do not think it makes sense to
> expose
> > > all
> > > > > > > feature
> > > > > > > > >
> > > > > > > > > set
> > > > > > > > > > of Igntie to thin clients.
> > > > > > > > > >
> > > > > > > > > > Instead, we can significantly simplify client node
> > > > configuration
> > > > > -
> > > > > > it
> > > > > > > > > > currently requires the same config as a regular Ignite
> > node,
> > > > > > > however, in
> > > > > > > > > > most cases, the configuration can be reduced almost to a
> > > > several
> > > > > > > > >
> > > > > > > > > host:port
> > > > > > > > > > pairs.
> > > > > > > > > >
> > > > > > > > > > пн, 17 июн. 2019 г. в 15:58, Nikolay Izhikov <
> > > > > [hidden email]
> > > > > > >:
> > > > > > > > > >
> > > > > > > > > > > Alexey.
> > > > > > > > > > >
> > > > > > > > > > > I want to share a thought (just don't drop it out in
> one
> > > > moment
> > > > > > :)
> > > > > > > ).
> > > > > > > > > > >
> > > > > > > > > > > Do we really need "client nodes"?
> > > > > > > > > > >
> > > > > > > > > > > We have thin client protocol that is a very convenient
> > > point
> > > > to
> > > > > > > > >
> > > > > > > > > interact
> > > > > > > > > > > with Ignite.
> > > > > > > > > > > So, why, we need one more entity and work mode such as
> > > > "client
> > > > > > > node"?
> > > > > > > > > > >
> > > > > > > > > > > From my point of view, client nodes were required in
> the
> > > time
> > > > > > > without a
> > > > > > > > > > > thin client.
> > > > > > > > > > > Now, we have it.
> > > > > > > > > > >
> > > > > > > > > > > Let's simplify Ignite codebase and drop client nodes!
> > > > > > > > > > >
> > > > > > > > > > > How does it sound?
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > В Пн, 17/06/2019 в 15:52 +0300, Alexey Goncharuk пишет:
> > > > > > > > > > > > Nikolay,
> > > > > > > > > > > >
> > > > > > > > > > > > Local caches and scalar are already in the list :)
> > Added
> > > > the
> > > > > > > outdated
> > > > > > > > > > > > metrics point.
> > > > > > > > > > > >
> > > > > > > > > > > > пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov <
> > > > > > > [hidden email]>:
> > > > > > > > > > > >
> > > > > > > > > > > > > * Scalar.
> > > > > > > > > > > > > * LOCAL caches.
> > > > > > > > > > > > > * Deprecated metrics.
> > > > > > > > > > > > >
> > > > > > > > > > > > > В Пн, 17/06/2019 в 15:18 +0300, Alexey Goncharuk
> > пишет:
> > > > > > > > > > > > > > Igniters,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Even though we are still planning the Ignite 2.8
> > > > > release, I
> > > > > > > would
> > > > > > > > > > >
> > > > > > > > > > > like to
> > > > > > > > > > > > > > kick-off a discussion related to Ignite 3.0,
> > because
> > > > the
> > > > > > > efforts
> > > > > > > > > >
> > > > > > > > > > for
> > > > > > > > > > > AI
> > > > > > > > > > > > >
> > > > > > > > > > > > > 3.0
> > > > > > > > > > > > > > will be significantly larger than for AI 2.8,
> > better
> > > to
> > > > > > start
> > > > > > > > > >
> > > > > > > > > > early.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > As a first step, I would like to discuss the list
> > of
> > > > > things
> > > > > > > to be
> > > > > > > > > > >
> > > > > > > > > > > removed
> > > > > > > > > > > > > > in Ignite 3.0 (partially this thread is inspired
> by
> > > > Denis
> > > > > > > Magda's
> > > > > > > > > > >
> > > > > > > > > > > IGFS
> > > > > > > > > > > > > > removal thread). I've separated all to-be-removed
> > > > points
> > > > > > from
> > > > > > > > > > >
> > > > > > > > > > > existing
> > > > > > > > > > > > > > Ignite 3.0 wishlist [1] to a dedicated block and
> > also
> > > > > added
> > > > > > > a few
> > > > > > > > > > >
> > > > > > > > > > > more
> > > > > > > > > > > > > > things that look right to be dropped.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Please share your thoughts, probably, there are
> > more
> > > > > > outdated
> > > > > > > > > >
> > > > > > > > > > things
> > > > > > > > > > > we
> > > > > > > > > > > > > > need to add to the wishlist.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > As a side question: I think it makes sense to
> > create
> > > > > > tickets
> > > > > > > for
> > > > > > > > > >
> > > > > > > > > > such
> > > > > > > > > > > > > > improvements, how do we track them. Will the 3.0
> > > > version
> > > > > > > suffice
> > > > > > > > >
> > > > > > > > > or
> > > > > > > > > > > > >
> > > > > > > > > > > > > should
> > > > > > > > > > > > > > we add a separate label?
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

--
Best regards,
Andrey V. Mashenkov

[Ivan Pavlukhin]

Nikolay, Dmitriy,

Should we have a separate thread devoted to client nodes?

Also, my cent here is from a Hazelcast history. Once they removed
their thick client (called LiteMember), but after a while they brought
it back. I think we need to learn this lesson in more details.

вт, 18 июн. 2019 г. в 11:42, Andrey Mashenkov <[hidden email]>:

>
> Also,
> * Get rid of old services.
> * Make system cache non-persistent or even more - drop it. Discussion on
> dev list [1].
>
> I have no permissions to edit wiki page and would glad if someone add all
> thoughts from this thread.
>
> [1]
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-System-cache-persistence-td41158.html
>
> On Tue, Jun 18, 2019 at 10:33 AM Alexey Goncharuk <
> [hidden email]> wrote:
>
> > Folks,
> >
> > May I ask you to add the mentioned points to the wishlist to keep them in
> > one place for convenience?
> >
> > вт, 18 июн. 2019 г. в 00:19, Alex Plehanov <[hidden email]>:
> >
> > > Remove "force server mode" for client nodes (already was discussed on dev
> > > list earlier [1]).
> > >
> > > [1] :
> > >
> > >
> > http://apache-ignite-developers.2346864.n4.nabble.com/Deprecate-force-server-mode-for-clients-td33614.html
> > >
> > > пн, 17 июн. 2019 г. в 19:22, Pavel Tupitsyn <[hidden email]>:
> > >
> > > > Big changes for .NET:
> > > > * Remove legacy Entity Framework integration
> > > > * Remove legacy ASP.NET integration
> > > > * Move from .NET Framework 4.0 (released in 2010) to .NET Standard 2.0
> > > > (modern way to build libraries)
> > > >
> > > > Thanks,
> > > > Pavel
> > > >
> > > > On Mon, Jun 17, 2019 at 7:14 PM Igor Sapego <[hidden email]>
> > > wrote:
> > > >
> > > > > For the C++ I propose to drop support of VS 2010 and move to
> > > > > at least 2012 (or, better yet 2013).
> > > > >
> > > > > Also, I'd drop x86 support for everything except for maybe ODBC.
> > > > >
> > > > > Best Regards,
> > > > > Igor
> > > > >
> > > > > On Mon, Jun 17, 2019 at 7:12 PM Pavel Kovalenko <[hidden email]>
> > > > > wrote:
> > > > >
> > > > > > I would like to add to the list following:
> > > > > >
> > > > > > 1. Remove ForceKeyRequests and related code. Since we have Late
> > > > affinity
> > > > > > assignment and primary node partitions are always up to date we
> > don't
> > > > > need
> > > > > > to request actual data from backups.
> > > > > > 2. Remove @CentralizedAffinityFunction and related code. I don't
> > see
> > > > any
> > > > > > real usages of custom affinity functions that use this annotation.
> > > > > > 3. Leave Exchanges Merge + Late Affinity assignment as the only PME
> > > > > > protocol. Remove centralized affinity distribution in case of node
> > > left
> > > > > and
> > > > > > no merge exchange legacy modes.
> > > > > > 4. Remove CacheRebalanceMode.NONE and Rebalance Delay as it can
> > break
> > > > > data
> > > > > > consistency in a cluster. Also, remove force rebalance mode as it
> > can
> > > > be
> > > > > > used only if rebalance delay is set.
> > > > > >
> > > > > > пн, 17 июн. 2019 г. в 18:39, Dmitriy Pavlov <[hidden email]>:
> > > > > >
> > > > > > > Nikolay,
> > > > > > >
> > > > > > > we can (and probably should) discuss stop deploying
> > caches/services
> > > > to
> > > > > > > client nodes.
> > > > > > >
> > > > > > > But I would not name it removal of client nodes at all. Any
> > Apache
> > > > > Ignite
> > > > > > > guide I saw is starting from 2 steps: 1) start server node, 2)
> > > start
> > > > > > client
> > > > > > > node.
> > > > > > >
> > > > > > > There are no reasons to write software if users are unaware of
> > how
> > > to
> > > > > use
> > > > > > > it. So I do not agree that supplementary materials are
> > unimportant.
> > > > > > >
> > > > > > > Sincerely,
> > > > > > > Dmitriy Pavlov
> > > > > > >
> > > > > > > пн, 17 июн. 2019 г. в 18:30, Nikolay Izhikov <
> > [hidden email]
> > > >:
> > > > > > >
> > > > > > > > Dmitriy,
> > > > > > > >
> > > > > > > > I think the whole concept of "client" nodes is broken.
> > > > > > > > And that's why:
> > > > > > > >
> > > > > > > > Ignite Client node nothing to do with "client" :)
> > > > > > > > We can deploy cache on it, we can execute compute tasks,
> > services
> > > > on
> > > > > > it.
> > > > > > > > "client node" is a node with special join process and some
> > > > > > rebalance/PME
> > > > > > > > hacks.
> > > > > > > > And we put many(many!) efforts to support this concept and this
> > > > > hacks.
> > > > > > > >
> > > > > > > > And I'm asking: What value client nodes bring to Ignite?
> > > > > > > >
> > > > > > > > I think, Alexey, already answered correctly:
> > > > > > > >
> > > > > > > > * Transactions support.
> > > > > > > > * P2P deployment.
> > > > > > > >
> > > > > > > > I think we should, definitely, remove concept of "client nodes"
> > > in
> > > > > the
> > > > > > > > future.
> > > > > > > > It's about product design decision, in the first place, not
> > about
> > > > > > > > additional materials.
> > > > > > > >
> > > > > > > > The simpler core codebase we have, the more reliable product we
> > > ca
> > > > > > build
> > > > > > > > with it.
> > > > > > > >
> > > > > > > >
> > > > > > > > В Пн, 17/06/2019 в 18:19 +0300, Dmitriy Pavlov пишет:
> > > > > > > > > Hi Nikolay,
> > > > > > > > >
> > > > > > > > > I think client nodes removal is not possible in the near
> > future
> > > > > > because
> > > > > > > > of
> > > > > > > > > tons of usages everywhere outside Ignite code (in products,
> > > > guides,
> > > > > > > > books,
> > > > > > > > > training, etc.)
> > > > > > > > >
> > > > > > > > > If we have replacement we should encourage users to migrate,
> > > but
> > > > we
> > > > > > > can't
> > > > > > > > > remove such a core feature.
> > > > > > > > >
> > > > > > > > > Alexey, sure we can discuss removal of modules, why not?
> > > > > > > > >
> > > > > > > > > Sincerely,
> > > > > > > > > Dmitriy Pavlov
> > > > > > > > >
> > > > > > > > > пн, 17 июн. 2019 г. в 18:02, Alexey Zinoviev <
> > > > > [hidden email]
> > > > > > >:
> > > > > > > > >
> > > > > > > > > > Could we suggest here remove whole modules?
> > > > > > > > > >
> > > > > > > > > > пн, 17 июн. 2019 г. в 16:28, Alexey Goncharuk <
> > > > > > > > [hidden email]
> > > > > > > > > > > :
> > > > > > > > > > > Nikolay,
> > > > > > > > > > >
> > > > > > > > > > > I had this thought too, but I am not too eager to
> > implement
> > > > it
> > > > > > yet.
> > > > > > > > The
> > > > > > > > > > > reason is transaction protocol complexity/performance
> > > issues
> > > > > with
> > > > > > > > thin
> > > > > > > > > > > clients.
> > > > > > > > > > >
> > > > > > > > > > > A thick client can communicate with each primary node and
> > > > > > > coordinate
> > > > > > > > > > > prepare/commit phases. Thin client can only communicate
> > > with
> > > > > one
> > > > > > > > node, so
> > > > > > > > > > > the change will mean an additional network hop. Of
> > course,
> > > we
> > > > > can
> > > > > > > > make
> > > > > > > > > >
> > > > > > > > > > thin
> > > > > > > > > > > clients implement the same protocol, but it will
> > > immediately
> > > > > > > > increase the
> > > > > > > > > > > protocol complexity for all platforms.
> > > > > > > > > > >
> > > > > > > > > > > Plus, we do not have near cache on thin clients, we do
> > not
> > > > > > support
> > > > > > > > p2p
> > > > > > > > > > > class deployment, etc. Since thin clients are positioned
> > as
> > > > > > > > > > > platform-agnostic, I do not think it makes sense to
> > expose
> > > > all
> > > > > > > > feature
> > > > > > > > > >
> > > > > > > > > > set
> > > > > > > > > > > of Igntie to thin clients.
> > > > > > > > > > >
> > > > > > > > > > > Instead, we can significantly simplify client node
> > > > > configuration
> > > > > > -
> > > > > > > it
> > > > > > > > > > > currently requires the same config as a regular Ignite
> > > node,
> > > > > > > > however, in
> > > > > > > > > > > most cases, the configuration can be reduced almost to a
> > > > > several
> > > > > > > > > >
> > > > > > > > > > host:port
> > > > > > > > > > > pairs.
> > > > > > > > > > >
> > > > > > > > > > > пн, 17 июн. 2019 г. в 15:58, Nikolay Izhikov <
> > > > > > [hidden email]
> > > > > > > >:
> > > > > > > > > > >
> > > > > > > > > > > > Alexey.
> > > > > > > > > > > >
> > > > > > > > > > > > I want to share a thought (just don't drop it out in
> > one
> > > > > moment
> > > > > > > :)
> > > > > > > > ).
> > > > > > > > > > > >
> > > > > > > > > > > > Do we really need "client nodes"?
> > > > > > > > > > > >
> > > > > > > > > > > > We have thin client protocol that is a very convenient
> > > > point
> > > > > to
> > > > > > > > > >
> > > > > > > > > > interact
> > > > > > > > > > > > with Ignite.
> > > > > > > > > > > > So, why, we need one more entity and work mode such as
> > > > > "client
> > > > > > > > node"?
> > > > > > > > > > > >
> > > > > > > > > > > > From my point of view, client nodes were required in
> > the
> > > > time
> > > > > > > > without a
> > > > > > > > > > > > thin client.
> > > > > > > > > > > > Now, we have it.
> > > > > > > > > > > >
> > > > > > > > > > > > Let's simplify Ignite codebase and drop client nodes!
> > > > > > > > > > > >
> > > > > > > > > > > > How does it sound?
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > В Пн, 17/06/2019 в 15:52 +0300, Alexey Goncharuk пишет:
> > > > > > > > > > > > > Nikolay,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Local caches and scalar are already in the list :)
> > > Added
> > > > > the
> > > > > > > > outdated
> > > > > > > > > > > > > metrics point.
> > > > > > > > > > > > >
> > > > > > > > > > > > > пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov <
> > > > > > > > [hidden email]>:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > * Scalar.
> > > > > > > > > > > > > > * LOCAL caches.
> > > > > > > > > > > > > > * Deprecated metrics.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > В Пн, 17/06/2019 в 15:18 +0300, Alexey Goncharuk
> > > пишет:
> > > > > > > > > > > > > > > Igniters,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Even though we are still planning the Ignite 2.8
> > > > > > release, I
> > > > > > > > would
> > > > > > > > > > > >
> > > > > > > > > > > > like to
> > > > > > > > > > > > > > > kick-off a discussion related to Ignite 3.0,
> > > because
> > > > > the
> > > > > > > > efforts
> > > > > > > > > > >
> > > > > > > > > > > for
> > > > > > > > > > > > AI
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 3.0
> > > > > > > > > > > > > > > will be significantly larger than for AI 2.8,
> > > better
> > > > to
> > > > > > > start
> > > > > > > > > > >
> > > > > > > > > > > early.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > As a first step, I would like to discuss the list
> > > of
> > > > > > things
> > > > > > > > to be
> > > > > > > > > > > >
> > > > > > > > > > > > removed
> > > > > > > > > > > > > > > in Ignite 3.0 (partially this thread is inspired
> > by
> > > > > Denis
> > > > > > > > Magda's
> > > > > > > > > > > >
> > > > > > > > > > > > IGFS
> > > > > > > > > > > > > > > removal thread). I've separated all to-be-removed
> > > > > points
> > > > > > > from
> > > > > > > > > > > >
> > > > > > > > > > > > existing
> > > > > > > > > > > > > > > Ignite 3.0 wishlist [1] to a dedicated block and
> > > also
> > > > > > added
> > > > > > > > a few
> > > > > > > > > > > >
> > > > > > > > > > > > more
> > > > > > > > > > > > > > > things that look right to be dropped.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Please share your thoughts, probably, there are
> > > more
> > > > > > > outdated
> > > > > > > > > > >
> > > > > > > > > > > things
> > > > > > > > > > > > we
> > > > > > > > > > > > > > > need to add to the wishlist.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > As a side question: I think it makes sense to
> > > create
> > > > > > > tickets
> > > > > > > > for
> > > > > > > > > > >
> > > > > > > > > > > such
> > > > > > > > > > > > > > > improvements, how do we track them. Will the 3.0
> > > > > version
> > > > > > > > suffice
> > > > > > > > > >
> > > > > > > > > > or
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > we add a separate label?
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
> Best regards,
> Andrey V. Mashenkov

--
Best regards,
Ivan Pavlukhin

[Dmitry Pavlov]

Hi Ivan, thank you for this bit of information. We seem to be on the same
page about a removal, and it would not happen in 3.0. My concern related to
public API and users. If we internally redesign thick clients and remove
counter-intuitive use cases (e.g. caches on a client, excepting near
caches) it is perfectly fine, and I encourage everyone to propose solutions
in this issue.

Hi Andrey, please check your Apache ID while login to wiki. Since you are
comitter you should be able to edit (INFRA set up LDAP recently).

If it will not work, please share your wiki username, and I will add
permissions.

Sincerely
Dmitriy Pavlov

вт, 18 июн. 2019 г. в 12:32, Павлухин Иван <[hidden email]>:

> Nikolay, Dmitriy,
>
> Should we have a separate thread devoted to client nodes?
>
> Also, my cent here is from a Hazelcast history. Once they removed
> their thick client (called LiteMember), but after a while they brought
> it back. I think we need to learn this lesson in more details.
>
> вт, 18 июн. 2019 г. в 11:42, Andrey Mashenkov <[hidden email]
> >:
> >
> > Also,
> > * Get rid of old services.
> > * Make system cache non-persistent or even more - drop it. Discussion on
> > dev list [1].
> >
> > I have no permissions to edit wiki page and would glad if someone add all
> > thoughts from this thread.
> >
> > [1]
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-System-cache-persistence-td41158.html
> >
> > On Tue, Jun 18, 2019 at 10:33 AM Alexey Goncharuk <
> > [hidden email]> wrote:
> >
> > > Folks,
> > >
> > > May I ask you to add the mentioned points to the wishlist to keep them
> in
> > > one place for convenience?
> > >
> > > вт, 18 июн. 2019 г. в 00:19, Alex Plehanov <[hidden email]>:
> > >
> > > > Remove "force server mode" for client nodes (already was discussed
> on dev
> > > > list earlier [1]).
> > > >
> > > > [1] :
> > > >
> > > >
> > >
> http://apache-ignite-developers.2346864.n4.nabble.com/Deprecate-force-server-mode-for-clients-td33614.html
> > > >
> > > > пн, 17 июн. 2019 г. в 19:22, Pavel Tupitsyn <[hidden email]>:
> > > >
> > > > > Big changes for .NET:
> > > > > * Remove legacy Entity Framework integration
> > > > > * Remove legacy ASP.NET integration
> > > > > * Move from .NET Framework 4.0 (released in 2010) to .NET Standard
> 2.0
> > > > > (modern way to build libraries)
> > > > >
> > > > > Thanks,
> > > > > Pavel
> > > > >
> > > > > On Mon, Jun 17, 2019 at 7:14 PM Igor Sapego <[hidden email]>
> > > > wrote:
> > > > >
> > > > > > For the C++ I propose to drop support of VS 2010 and move to
> > > > > > at least 2012 (or, better yet 2013).
> > > > > >
> > > > > > Also, I'd drop x86 support for everything except for maybe ODBC.
> > > > > >
> > > > > > Best Regards,
> > > > > > Igor
> > > > > >
> > > > > > On Mon, Jun 17, 2019 at 7:12 PM Pavel Kovalenko <
> [hidden email]>
> > > > > > wrote:
> > > > > >
> > > > > > > I would like to add to the list following:
> > > > > > >
> > > > > > > 1. Remove ForceKeyRequests and related code. Since we have Late
> > > > > affinity
> > > > > > > assignment and primary node partitions are always up to date we
> > > don't
> > > > > > need
> > > > > > > to request actual data from backups.
> > > > > > > 2. Remove @CentralizedAffinityFunction and related code. I
> don't
> > > see
> > > > > any
> > > > > > > real usages of custom affinity functions that use this
> annotation.
> > > > > > > 3. Leave Exchanges Merge + Late Affinity assignment as the
> only PME
> > > > > > > protocol. Remove centralized affinity distribution in case of
> node
> > > > left
> > > > > > and
> > > > > > > no merge exchange legacy modes.
> > > > > > > 4. Remove CacheRebalanceMode.NONE and Rebalance Delay as it can
> > > break
> > > > > > data
> > > > > > > consistency in a cluster. Also, remove force rebalance mode as
> it
> > > can
> > > > > be
> > > > > > > used only if rebalance delay is set.
> > > > > > >
> > > > > > > пн, 17 июн. 2019 г. в 18:39, Dmitriy Pavlov <
> [hidden email]>:
> > > > > > >
> > > > > > > > Nikolay,
> > > > > > > >
> > > > > > > > we can (and probably should) discuss stop deploying
> > > caches/services
> > > > > to
> > > > > > > > client nodes.
> > > > > > > >
> > > > > > > > But I would not name it removal of client nodes at all. Any
> > > Apache
> > > > > > Ignite
> > > > > > > > guide I saw is starting from 2 steps: 1) start server node,
> 2)
> > > > start
> > > > > > > client
> > > > > > > > node.
> > > > > > > >
> > > > > > > > There are no reasons to write software if users are unaware
> of
> > > how
> > > > to
> > > > > > use
> > > > > > > > it. So I do not agree that supplementary materials are
> > > unimportant.
> > > > > > > >
> > > > > > > > Sincerely,
> > > > > > > > Dmitriy Pavlov
> > > > > > > >
> > > > > > > > пн, 17 июн. 2019 г. в 18:30, Nikolay Izhikov <
> > > [hidden email]
> > > > >:
> > > > > > > >
> > > > > > > > > Dmitriy,
> > > > > > > > >
> > > > > > > > > I think the whole concept of "client" nodes is broken.
> > > > > > > > > And that's why:
> > > > > > > > >
> > > > > > > > > Ignite Client node nothing to do with "client" :)
> > > > > > > > > We can deploy cache on it, we can execute compute tasks,
> > > services
> > > > > on
> > > > > > > it.
> > > > > > > > > "client node" is a node with special join process and some
> > > > > > > rebalance/PME
> > > > > > > > > hacks.
> > > > > > > > > And we put many(many!) efforts to support this concept and
> this
> > > > > > hacks.
> > > > > > > > >
> > > > > > > > > And I'm asking: What value client nodes bring to Ignite?
> > > > > > > > >
> > > > > > > > > I think, Alexey, already answered correctly:
> > > > > > > > >
> > > > > > > > > * Transactions support.
> > > > > > > > > * P2P deployment.
> > > > > > > > >
> > > > > > > > > I think we should, definitely, remove concept of "client
> nodes"
> > > > in
> > > > > > the
> > > > > > > > > future.
> > > > > > > > > It's about product design decision, in the first place, not
> > > about
> > > > > > > > > additional materials.
> > > > > > > > >
> > > > > > > > > The simpler core codebase we have, the more reliable
> product we
> > > > ca
> > > > > > > build
> > > > > > > > > with it.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > В Пн, 17/06/2019 в 18:19 +0300, Dmitriy Pavlov пишет:
> > > > > > > > > > Hi Nikolay,
> > > > > > > > > >
> > > > > > > > > > I think client nodes removal is not possible in the near
> > > future
> > > > > > > because
> > > > > > > > > of
> > > > > > > > > > tons of usages everywhere outside Ignite code (in
> products,
> > > > > guides,
> > > > > > > > > books,
> > > > > > > > > > training, etc.)
> > > > > > > > > >
> > > > > > > > > > If we have replacement we should encourage users to
> migrate,
> > > > but
> > > > > we
> > > > > > > > can't
> > > > > > > > > > remove such a core feature.
> > > > > > > > > >
> > > > > > > > > > Alexey, sure we can discuss removal of modules, why not?
> > > > > > > > > >
> > > > > > > > > > Sincerely,
> > > > > > > > > > Dmitriy Pavlov
> > > > > > > > > >
> > > > > > > > > > пн, 17 июн. 2019 г. в 18:02, Alexey Zinoviev <
> > > > > > [hidden email]
> > > > > > > >:
> > > > > > > > > >
> > > > > > > > > > > Could we suggest here remove whole modules?
> > > > > > > > > > >
> > > > > > > > > > > пн, 17 июн. 2019 г. в 16:28, Alexey Goncharuk <
> > > > > > > > > [hidden email]
> > > > > > > > > > > > :
> > > > > > > > > > > > Nikolay,
> > > > > > > > > > > >
> > > > > > > > > > > > I had this thought too, but I am not too eager to
> > > implement
> > > > > it
> > > > > > > yet.
> > > > > > > > > The
> > > > > > > > > > > > reason is transaction protocol complexity/performance
> > > > issues
> > > > > > with
> > > > > > > > > thin
> > > > > > > > > > > > clients.
> > > > > > > > > > > >
> > > > > > > > > > > > A thick client can communicate with each primary
> node and
> > > > > > > > coordinate
> > > > > > > > > > > > prepare/commit phases. Thin client can only
> communicate
> > > > with
> > > > > > one
> > > > > > > > > node, so
> > > > > > > > > > > > the change will mean an additional network hop. Of
> > > course,
> > > > we
> > > > > > can
> > > > > > > > > make
> > > > > > > > > > >
> > > > > > > > > > > thin
> > > > > > > > > > > > clients implement the same protocol, but it will
> > > > immediately
> > > > > > > > > increase the
> > > > > > > > > > > > protocol complexity for all platforms.
> > > > > > > > > > > >
> > > > > > > > > > > > Plus, we do not have near cache on thin clients, we
> do
> > > not
> > > > > > > support
> > > > > > > > > p2p
> > > > > > > > > > > > class deployment, etc. Since thin clients are
> positioned
> > > as
> > > > > > > > > > > > platform-agnostic, I do not think it makes sense to
> > > expose
> > > > > all
> > > > > > > > > feature
> > > > > > > > > > >
> > > > > > > > > > > set
> > > > > > > > > > > > of Igntie to thin clients.
> > > > > > > > > > > >
> > > > > > > > > > > > Instead, we can significantly simplify client node
> > > > > > configuration
> > > > > > > -
> > > > > > > > it
> > > > > > > > > > > > currently requires the same config as a regular
> Ignite
> > > > node,
> > > > > > > > > however, in
> > > > > > > > > > > > most cases, the configuration can be reduced almost
> to a
> > > > > > several
> > > > > > > > > > >
> > > > > > > > > > > host:port
> > > > > > > > > > > > pairs.
> > > > > > > > > > > >
> > > > > > > > > > > > пн, 17 июн. 2019 г. в 15:58, Nikolay Izhikov <
> > > > > > > [hidden email]
> > > > > > > > >:
> > > > > > > > > > > >
> > > > > > > > > > > > > Alexey.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I want to share a thought (just don't drop it out
> in
> > > one
> > > > > > moment
> > > > > > > > :)
> > > > > > > > > ).
> > > > > > > > > > > > >
> > > > > > > > > > > > > Do we really need "client nodes"?
> > > > > > > > > > > > >
> > > > > > > > > > > > > We have thin client protocol that is a very
> convenient
> > > > > point
> > > > > > to
> > > > > > > > > > >
> > > > > > > > > > > interact
> > > > > > > > > > > > > with Ignite.
> > > > > > > > > > > > > So, why, we need one more entity and work mode
> such as
> > > > > > "client
> > > > > > > > > node"?
> > > > > > > > > > > > >
> > > > > > > > > > > > > From my point of view, client nodes were required
> in
> > > the
> > > > > time
> > > > > > > > > without a
> > > > > > > > > > > > > thin client.
> > > > > > > > > > > > > Now, we have it.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Let's simplify Ignite codebase and drop client
> nodes!
> > > > > > > > > > > > >
> > > > > > > > > > > > > How does it sound?
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > В Пн, 17/06/2019 в 15:52 +0300, Alexey Goncharuk
> пишет:
> > > > > > > > > > > > > > Nikolay,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Local caches and scalar are already in the list
> :)
> > > > Added
> > > > > > the
> > > > > > > > > outdated
> > > > > > > > > > > > > > metrics point.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov <
> > > > > > > > > [hidden email]>:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > * Scalar.
> > > > > > > > > > > > > > > * LOCAL caches.
> > > > > > > > > > > > > > > * Deprecated metrics.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > В Пн, 17/06/2019 в 15:18 +0300, Alexey
> Goncharuk
> > > > пишет:
> > > > > > > > > > > > > > > > Igniters,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Even though we are still planning the Ignite
> 2.8
> > > > > > > release, I
> > > > > > > > > would
> > > > > > > > > > > > >
> > > > > > > > > > > > > like to
> > > > > > > > > > > > > > > > kick-off a discussion related to Ignite 3.0,
> > > > because
> > > > > > the
> > > > > > > > > efforts
> > > > > > > > > > > >
> > > > > > > > > > > > for
> > > > > > > > > > > > > AI
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 3.0
> > > > > > > > > > > > > > > > will be significantly larger than for AI 2.8,
> > > > better
> > > > > to
> > > > > > > > start
> > > > > > > > > > > >
> > > > > > > > > > > > early.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > As a first step, I would like to discuss the
> list
> > > > of
> > > > > > > things
> > > > > > > > > to be
> > > > > > > > > > > > >
> > > > > > > > > > > > > removed
> > > > > > > > > > > > > > > > in Ignite 3.0 (partially this thread is
> inspired
> > > by
> > > > > > Denis
> > > > > > > > > Magda's
> > > > > > > > > > > > >
> > > > > > > > > > > > > IGFS
> > > > > > > > > > > > > > > > removal thread). I've separated all
> to-be-removed
> > > > > > points
> > > > > > > > from
> > > > > > > > > > > > >
> > > > > > > > > > > > > existing
> > > > > > > > > > > > > > > > Ignite 3.0 wishlist [1] to a dedicated block
> and
> > > > also
> > > > > > > added
> > > > > > > > > a few
> > > > > > > > > > > > >
> > > > > > > > > > > > > more
> > > > > > > > > > > > > > > > things that look right to be dropped.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Please share your thoughts, probably, there
> are
> > > > more
> > > > > > > > outdated
> > > > > > > > > > > >
> > > > > > > > > > > > things
> > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > need to add to the wishlist.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > As a side question: I think it makes sense to
> > > > create
> > > > > > > > tickets
> > > > > > > > > for
> > > > > > > > > > > >
> > > > > > > > > > > > such
> > > > > > > > > > > > > > > > improvements, how do we track them. Will the
> 3.0
> > > > > > version
> > > > > > > > > suffice
> > > > > > > > > > >
> > > > > > > > > > > or
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > > we add a separate label?
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > Best regards,
> > Andrey V. Mashenkov
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>