Igniters,
I'd like to start a discussion about API changes related to the data
colocation in Apache Ignite 3.0. [1]
The main purpose of the proposal is a definition of tables' colocation
from a user perspective including DDL syntax and changes related to
used terminology.
While proposed changes
l-archives.apache.org/mod_mbox/ignite-user/202101.mbox/%3CCABuYRcpgKQvTJDhSvqHOzKWJf5wN-mLKUHiNR5qyaNLvLsds8w%40mail.gmail.com%3E
> [3] Wiki Page
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0
> [4] Getting Started Guide:
> https://ignite.apache.org/docs/3.0.0-alpha/quick-
/ignite-user/202101.mbox/%3CCABuYRcpgKQvTJDhSvqHOzKWJf5wN-mLKUHiNR5qyaNLvLsds8w%40mail.gmail.com%3E
[3] Wiki Page
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0
[4] Getting Started Guide:
https://ignite.apache.org/docs/3.0.0-alpha/quick-start/getting-started-guide
[5] Apache Ignite
Alexey,
Thanks for details!
Common replication infra suggestion looks great!
Agree with your points regarding per-page replication, but still have a
feeling that this protocol can be made compact enough, e.g. by sending only
deltas. As far as entry processors we can decide on what to send - if
Hi!
Alexey,
> If we want to support etcd as a metastorage - let's do this as a concrete
configuration option, a
> first-class citizen of the system rather than an SPI implementation with
a rigid interface.
On one side this is quite reasonable. But on the other side, if someone
wants to adopt, for
Hello Ivan,
Thanks for the feedback, see my comments inline:
чт, 22 окт. 2020 г. в 17:59, Ivan Daschinsky :
> Hi!
> Alexey, your proposal looks great. Can I ask you some questions?
> 1. Is nodes, that take part of metastorage replication group (raft
> candidates and leader) are expected to also
Hello Yakov,
Glad to see you back!
Hi!
> I am back!
>
> Here are several ideas on top of my mind for Ignite 3.0
> 1. Client nodes should take the config from servers. Basically it should be
> enough to provide some cluster identifier or any known IP address to start
> a client.
>
This totally
Hey Valentin!
Any design docs/wiki for 1, 4 and 5 so far?
Yakov Zhdanov
Hi Yakov,
Great to have you here! :) Thanks for the inputs. My comments are below.
*Alexey*, could you please comment on the points 3 and 4?
-Val
On Sat, Oct 10, 2020 at 4:36 PM Yakov Zhdanov
wrote:
> Hi!
> I am back!
>
> Here are several ideas on top of my mind for Ignite 3.0
> 1. Client
Hi!
I am back!
Here are several ideas on top of my mind for Ignite 3.0
1. Client nodes should take the config from servers. Basically it should be
enough to provide some cluster identifier or any known IP address to start
a client.
2. Thread per partition. Again. I strongly recommend taking a
ith Compute as well.
Thanks,
Pavel
On Tue, Aug 18, 2020 at 3:16 AM Saikat Maitra <
saikat.mai...@gmail.com
wrote:
Hi Pavel,
Awesome, thank you.
Yes, I remember having .Net modernization as part of Apache
Ignite
3.0
roadmap.
Regards,
Saikat
On Sun, Aug 16, 2020 at 11:04 AM Pavel T
> version,
> > > > > > > and remove integrations with legacy technologies (old ASP.NET
> > and
> > > > EF).
> > > > > > >
> > > > > > > > As for the messaging, so far I haven't se
mes users attempt to use it for remote code
> > > > invocation,
> > > > > > but
> > > > > > > compute is usually a better option for this. Do you have any
> > > examples
> > > > > > where
> >
lly a better option for this. Do you have any
> > examples
> > > > > where
> > > > > > messaging is a better fit then compute?
> > > > >
> > > > > I guess you are right, Compute can replace Messaging in most
> > scenarios.
> > > > >
s a better fit then compute?
> > > >
> > > > I guess you are right, Compute can replace Messaging in most
> scenarios.
> > > >
> > > > Messaging can be more convenient, since it is pub-sub - subscriber
> > > controls
> > > > whether it r
- subscriber
> > controls
> > > whether it receives messages on the given topic. But this can be
> achieved
> > > with a little more work with Compute as well.
> > >
> > > Thanks,
> > > Pavel
> > >
> > >
> > >
> &g
pic. But this can be achieved
> with a little more work with Compute as well.
>
> Thanks,
> Pavel
>
>
>
> On Tue, Aug 18, 2020 at 3:16 AM Saikat Maitra
> wrote:
>
> > Hi Pavel,
> >
> > Awesome, thank you.
> >
> > Yes, I remember having .Net modernizati
chieved
with a little more work with Compute as well.
Thanks,
Pavel
On Tue, Aug 18, 2020 at 3:16 AM Saikat Maitra
wrote:
> Hi Pavel,
>
> Awesome, thank you.
>
> Yes, I remember having .Net modernization as part of Apache Ignite 3.0
> roadmap.
>
> Regards,
> Saikat
&g
Hi Pavel,
Awesome, thank you.
Yes, I remember having .Net modernization as part of Apache Ignite 3.0
roadmap.
Regards,
Saikat
On Sun, Aug 16, 2020 at 11:04 AM Pavel Tupitsyn
wrote:
> Saikat, yes, most definitely.
> This is mentioned in the wishlist under ".NET: Target .NET S
0:06 PM Saikat Maitra
> wrote:
>
> > Hi Val,
> >
> > Thank you for adding the Cleanup section and Removals list.
> >
> > Pavel, As part of Apache Ignite Roadmap we had mentioned we will add
> > modernization of .NET. Are we still targeting it in Apache Ignite 3.0
Hi Val,
Thank you for adding the Cleanup section and Removals list.
Pavel, As part of Apache Ignite Roadmap we had mentioned we will add
modernization of .NET. Are we still targeting it in Apache Ignite 3.0
release?
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap
> not have all libs locally from the start.
> >
> >
> > >
> > > -Val
> > >
> > > On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov > <mailto:mr.wei...@gmail.com>> wrote:
> >
we all want 3.0 to be a "cleanup" release, I've added a section that
>> lists potential API removals:
>>
>> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0#ApacheIgnite3.0-Removals
>>
>> Please take a look and let me know if there are any objec
gt; Folks,
>
> Since we all want 3.0 to be a "cleanup" release, I've added a section that
> lists potential API removals:
>
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0#ApacheIgnite3.0-Removals
>
> Please take a look and let me know if there are a
Folks,
Since we all want 3.0 to be a "cleanup" release, I've added a section that
lists potential API removals:
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0#ApacheIgnite3.0-Removals
Please take a look and let me know if there are any objections, or if there
i
> optional libs in run command while ignite.sh will download everything
> > missing from known storage.
> >
> > The whole idea is in storing everything remotely and download on
> demand,
> > not have all libs locally from the start.
> >
&g
gt;
> > -Val
> >
> > On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov <mailto:mr.wei...@gmail.com>> wrote:
> > Hi, Val!
> > Thanks for your efforts on this endeavour!
> >
> >
> > I would like to suggest de
idea is in storing everything remotely and download on demand,
> not have all libs locally from the start.
>
>
> >
> > -Val
> >
> > On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov <mailto:mr.wei...@gmail.com>> wrote:
> > Hi, Val!
> > Thanks for yo
sing from known
> storage.
>
> The whole idea is in storing everything remotely and download on demand, not
> have all libs locally from the start.
>
>
>>
>> -Val
>>
>> On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov > <mailto:mr.wei...@gmail.com>&g
known storage.
>
> The whole idea is in storing everything remotely and download on demand,
> not have all libs locally from the start.
>
>
>
> -Val
>
> On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov wrote:
>
>> Hi, Val!
>> Thanks for your efforts on this endea
n, Aug 9, 2020 at 11:25 PM Petr Ivanov <mailto:mr.wei...@gmail.com>> wrote:
> Hi, Val!
> Thanks for your efforts on this endeavour!
>
>
> I would like to suggest deliveries changes in Apache Ignite 3.0:
> — modularised binary delivery — single minimal binary for starti
Val,
> > >
> > > Thank you for sharing the page and your efforts in compiling the
> features
> > > list, I am thinking since it is a major version release then shall we
> > > include a section for deprecated features and add changes as mentioned
> in
> > > ou
and your efforts in compiling the features
> > list, I am thinking since it is a major version release then shall we
> > include a section for deprecated features and add changes as mentioned in
> > our Apache Ignite 3.0 Wishlist
> >
> >
> >
> https://c
Val,
>
> Thank you for sharing the page and your efforts in compiling the features
> list, I am thinking since it is a major version release then shall we
> include a section for deprecated features and add changes as mentioned in
> our Apache Ignite 3.0 Wishlist
>
>
> https://cwiki.ap
Hi, Val!
> Thanks for your efforts on this endeavour!
>
>
> I would like to suggest deliveries changes in Apache Ignite 3.0:
> — modularised binary delivery — single minimal binary for starting
> Ignite and all other modules and parts of the project (benchmarks,
> examples, e
Hi Val,
Thank you for sharing the page and your efforts in compiling the features
list, I am thinking since it is a major version release then shall we
include a section for deprecated features and add changes as mentioned in
our Apache Ignite 3.0 Wishlist
https://cwiki.apache.org/confluence
Hi, Val!
Thanks for your efforts on this endeavour!
I would like to suggest deliveries changes in Apache Ignite 3.0:
— modularised binary delivery — single minimal binary for starting Ignite and
all other modules and parts of the project (benchmarks, examples, etc.) packed
in their own
Igniters,
I've created the page:
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0
That's not everything I have in mind, but I believe there is already a lot
to talk about :)
Please take a look let me know if you have any concerns, objections, or
questions. Once we reach
1] of changes that we would like to have, but cannot
> implement
> > > > > without breaking compatibility.
> > > > >
> > > > > I think it's time to start planning for the next major release and
> > > > > discussing what should be included. I've already gathered some
> > > > information
> > > > > and feedback, and have some thoughts on how to approach this. In
> the
> > > next
> > > > > few days, I will put everything into a Wiki page and will share it
> > once
> > > > > this is done. Stay tuned!
> > > > >
> > > > > I'm willing to drive the 3.0 activities going forward as well.
> > > > >
> > > > > In the meantime, if there are any immediate thoughts or ideas,
> please
> > > > feel
> > > > > free to join the thread and share them.
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > > https://cwiki.apache.org/confluence/display/IGNITE/
> > > Apache+Ignite+3.0+Wishlist
> > > > >
> > > > > Regards,
> > > > > Val
> > > > >
> > > >
> > >
> >
> >
> > --
> > -
> > Denis
> >
>
t; > without breaking compatibility.
> > > >
> > > > I think it's time to start planning for the next major release and
> > > > discussing what should be included. I've already gathered some
> > > information
> > > > and feedback, and have som
t; > information
> > > and feedback, and have some thoughts on how to approach this. In the
> next
> > > few days, I will put everything into a Wiki page and will share it once
> > > this is done. Stay tuned!
> > >
> > > I'm willing to drive the 3.0 activities going forward as well.
> > >
> > > In the meantime, if there are any immediate thoughts or ideas, please
> > feel
> > > free to join the thread and share them.
> > >
> > > [1]
> > >
> > >
> > https://cwiki.apache.org/confluence/display/IGNITE/
> Apache+Ignite+3.0+Wishlist
> > >
> > > Regards,
> > > Val
> > >
> >
>
--
-
Denis
there are any immediate thoughts or ideas, please
> feel
> > free to join the thread and share them.
> >
> > [1]
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> >
> > Regards,
> > Val
> >
>
.
>
> [1]
>
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
>
> Regards,
> Val
>
the 3.0 activities going forward as well.
In the meantime, if there are any immediate thoughts or ideas, please feel
free to join the thread and share them.
[1]
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
Regards,
Val
; > > > >
> > > > > > > > Stan
> > > > > > > >
> > > > > > > > From: Sergey Antonov
> > > > > > > > Sent: 23 января 2019 г. 19:15
> > > > > > >
> in a minor release.
> > > > > > > Unfortunately, Ignite is far from that place for now. We don’t
> > have
> > > > any
> > > > > > > distinction between API and internal classes, don’t have
> > > > > > > p
don’t have
> > > > > > plugin-only APIs, etc. All classes are public, everything is
> > > accessible
> > > > > to
> > > > > > user code. We even refer to internal classes in public Javadoc
> > > > > > (e.g. I recall
d there).
> > > > > Considering this, moving CommandHandler from ignite-core to
> > > > > ignite-control-utility
> > > > > doesn't look that bad. It doesn’t differ to much from any other
> > change
> > > > > that
ing this, moving CommandHandler from ignite-core to
> > > > ignite-control-utility
> > > > doesn't look that bad. It doesn’t differ to much from any other
> change
> > > > that removes or renames a class.
> > > > There could be required changes with a
doesn’t differ to much from any other change
> > > that removes or renames a class.
> > > There could be required changes with a higher compatibility impact but
> I
> > > don’t see them after a superficial glance.
> > >
> > > Stan
> > >
> >
required changes with a higher compatibility impact but I
> > don’t see them after a superficial glance.
> >
> > Stan
> >
> > From: Sergey Antonov
> > Sent: 23 января 2019 г. 19:15
> > To: dev@ignite.apache.org
> > Subject: Re: [DISCUSSION] Control.sh glo
; From: Sergey Antonov
> Sent: 23 января 2019 г. 19:15
> To: dev@ignite.apache.org
> Subject: Re: [DISCUSSION] Control.sh global rework in apache ignite 3.0
>
> Stan, thank you for response!
>
> I my view we shouldn't make incompatible changes and switch extendable
> classes (i.e.
Subject: Re: [DISCUSSION] Control.sh global rework in apache ignite 3.0
Stan, thank you for response!
I my view we shouldn't make incompatible changes and switch extendable
classes (i.e. VisorDataTransferObject -> IgniteDataTransferObject) between
minor releases. Therefore we couldn't rework util
es are
> internal and unlikely to be used in the wild.
> On paper it’s an incompatible change, of course, but I think in this case
> it’s fine.
>
> My 2 cents,
> Stan
>
> From: Sergey Antonov
> Sent: 23 января 2019 г. 17:10
> To: dev@ignite.apache.org
> Subject: [DISC
in the wild.
On paper it’s an incompatible change, of course, but I think in this case it’s
fine.
My 2 cents,
Stan
From: Sergey Antonov
Sent: 23 января 2019 г. 17:10
To: dev@ignite.apache.org
Subject: [DISCUSSION] Control.sh global rework in apache ignite 3.0
Hello, Igniters!
I think, we should
Hello, Igniters!
I think, we should rework control.sh utility in Apache Ignite 3.0 release.
I made umbrella ticket [1] for it.
For a start we should move utitlity from ignite-core to separate module
[2]. It's enable using 3rd-party libraries, for example commons-cli [3].
Also we should add
56 matches
Mail list logo
