ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Pavlov <dpav...@apache.org>
Subject Re: [DISCUSSION] Ignite 3.0 and to be removed list
Date Mon, 17 Jun 2019 15:38:56 GMT
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 <nizhikov@apache.org>:

> 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 <zaleslaw.sin@gmail.com>:
> >
> > > Could we suggest here remove whole modules?
> > >
> > > пн, 17 июн. 2019 г. в 16:28, Alexey Goncharuk <
> alexey.goncharuk@gmail.com
> > > > :
> > > > 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 <nizhikov@apache.org>:
> > > >
> > > > > 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 <
> nizhikov@apache.org>:
> > > > > >
> > > > > > > * 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?
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message