You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Valentin Kulichenko <va...@gmail.com> on 2020/08/06 00:53:48 UTC
Apache Ignite 3.0
Igniters,
I would like to kick off a discussion regarding Ignite 3.0. Ignite 2.0
exists for more than 3 years now and we've already collected a significant
list [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
Re: Apache Ignite 3.0
Posted by Nikolay Izhikov <ni...@apache.org>.
I propose to add removals of the legacy JMX bean and Java metrics
We should use new metrics framework and JMX exporter instead of it.
> 14 авг. 2020 г., в 10:40, Pavel Tupitsyn <pt...@apache.org> написал(а):
>
> Val,
>
> The list of removals looks good to me, except Messaging.
> I remember it had some implementation issues, but the API itself seems to
> be rather useful -
> what are we going to offer instead?
>
>
> On Fri, Aug 14, 2020 at 3:16 AM Valentin Kulichenko <
> valentin.kulichenko@gmail.com> wrote:
>
>> 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
>> is anything that should be added.
>>
>> -Val
>>
>> On Thu, Aug 13, 2020 at 4:55 PM Valentin Kulichenko <
>> valentin.kulichenko@gmail.com> wrote:
>>
>>> Hi Ilya,
>>>
>>> Can you please describe your vision of how it should work?
>>>
>>> Let's say, I want to set up a cluster of several standalone server nodes
>>> with a couple of optional modules enabled. What are my steps?
>>>
>>> -Val
>>>
>>> On Thu, Aug 13, 2020 at 6:03 AM Carbone, Adam <
>> Adam.Carbone@bottomline.com>
>>> wrote:
>>>
>>>> Good Morning from the EastCoast
>>>>
>>>> I have to agree that the larger industry is tending towards
>> immutability,
>>>> and that you build once and test, then you promote/migrate that
>> immutable
>>>> binary object, be is a library or a docker image etc... however there
>> are
>>>> still patterns that allow you to determine at install/or deployment
>> time (
>>>> helm as an example, you choose based on your values what the package
>>>> installs/provides ) It just isn't decided at runtime but install and
>> often
>>>> in a gitops type world that is determined by configuration as code. I
>> think
>>>> run time is difficult to manage especially in our increasingly
>>>> containerized world.
>>>>
>>>> Regards.
>>>>
>>>> Adam Carbone | Director of Innovation – Intelligent Platform Team |
>>>> Bottomline Technologies
>>>> Office: 603-501-6446 | Mobile: 603-570-8418
>>>> www.bottomline.com
>>>>
>>>>
>>>>
>>>> On 8/13/20, 8:01 AM, "Ilya Kasnacheev" <il...@gmail.com>
>>>> wrote:
>>>>
>>>> Hello!
>>>>
>>>> On the contrary, I would suggest that apache2 way was outdated even
>> at
>>>> times when apache was all rage.
>>>>
>>>> Now the nginx approach is prevalent: on devops phase, assemble a
>>>> custom
>>>> bundle with all plugins included, store it somewhere, and ship it to
>>>> production as a whole to remove any on-the-fly uncertainty from
>>>> production.
>>>>
>>>> This is what docker does, but also maven, which downloads
>> dependencies
>>>> during build. You do not need to download anything in runtime,
>> except
>>>> for
>>>> experimental deployments. You need to be all set before runtime
>>>> starts.
>>>>
>>>> Regards,
>>>> --
>>>> Ilya Kasnacheev
>>>>
>>>>
>>>> ср, 12 авг. 2020 г. в 09:48, Petr Ivanov <mr...@gmail.com>:
>>>>
>>>>> Hi, Val.
>>>>>
>>>>>> On 12 Aug 2020, at 01:31, Valentin Kulichenko <
>>>>> valentin.kulichenko@gmail.com> wrote:
>>>>>>
>>>>>> Hi Petr,
>>>>>>
>>>>>> I agree -- we should better modularize the platform. The current
>>>> way if
>>>>> very error-prone, especially during upgrades -- any changes made
>>>> within
>>>>> IGNITE_HOME (configs, scripts, modules, etc.) must be merged with
>> a
>>>> new
>>>>> version of the package. There is no standard way of doing this.
>>>>>>
>>>>>> However, I'm a bit concerned with your suggestion regarding
>> custom
>>>>> dependency management. Can you please elaborate on how you think
>> it
>>>> should
>>>>> work? Are there tools we can reuse for this purpose? I would try
>> to
>>>> avoid
>>>>> reinventing the wheel.
>>>>>
>>>>> I see it as a a2enmod | 2dismod analog of Apache2.
>>>>>
>>>>> We build and store Apache Ignite and its modules as separate
>>>> binaries
>>>>> (binary per module) then use custom script that will know where to
>>>> download
>>>>> necessary module. Or possibly use modified ignite.sh to specify
>>>> required
>>>>> 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.
>>>>>
>>>>>
>>>>>>
>>>>>> -Val
>>>>>>
>>>>>> On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov <
>> mr.weider@gmail.com
>>>>> <ma...@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
>>>> starting
>>>>> Ignite and all other modules and parts of the project (benchmarks,
>>>>> examples, etc.) packed in their own binary which can be added via
>>>> custom
>>>>> dependency management tool (i.e. modules.sh)
>>>>>> — same distribution for RPM and DEB packages but with modules
>>>> packed as
>>>>> separate ones (PHP for example)
>>>>>> — separate thin client release cycle with custom versioning
>>>>>> Possibly, we can we add additional section to the document you
>>>>> introduced for this part.
>>>>>>
>>>>>> Also, it seems that full JDK11 support (including building)
>> would
>>>> be a
>>>>> huge milestone and a sign of healthy modern project that tends to
>>>> be on the
>>>>> verge of mainstream technologies and not the stockpile of legacy
>>>> leftovers
>>>>> (fully support Iliya in removing all that was deprecated and/or
>>>> marked as
>>>>> unused anymore).
>>>>>>
>>>>>>
>>>>>>> On 8 Aug 2020, at 02:00, Valentin Kulichenko <
>>>>> valentin.kulichenko@gmail.com <mailto:
>> valentin.kulichenko@gmail.com
>>>>>>
>>>>> wrote:
>>>>>>>
>>>>>>> Igniters,
>>>>>>>
>>>>>>> I've created the page:
>>>>>>>
>>>>
>> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
>>>> <
>>>>>
>>>>
>> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
>>>>>
>>>>>>>
>>>>>>> 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 the consensus on the proposed
>> changes,
>>>> I will
>>>>>>> start creating tickets in Jira and a more detailed plan.
>>>>>>>
>>>>>>> -Val
>>>>>>>
>>>>>>> On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <
>>>> saikat.maitra@gmail.com
>>>>> <ma...@gmail.com>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Denis, Val
>>>>>>>>
>>>>>>>> Thank you for your reply and really appreciate it. It will be
>>>> very
>>>>> cool to
>>>>>>>> be able to connect and plan release together and learn more
>>>> about
>>>>> Ignite in
>>>>>>>> the process :)
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Saikat
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko <
>>>>>>>> valentin.kulichenko@gmail.com <mailto:
>>>> valentin.kulichenko@gmail.com>>
>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Saikat,
>>>>>>>>>
>>>>>>>>> That surely is a great idea. We will work together with
>> Denis
>>>> on
>>>>> setting
>>>>>>>>> this up in the nearest future.
>>>>>>>>>
>>>>>>>>> -Val
>>>>>>>>>
>>>>>>>>> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <
>>>> dmagda@apache.org
>>>>> <ma...@apache.org>> wrote:
>>>>>>>>>
>>>>>>>>>> Saikat,
>>>>>>>>>>
>>>>>>>>>> Fully support your idea on a virtual meetup! Once Val
>>>> collects and
>>>>>>>>> outlines
>>>>>>>>>> the main changes with directions on wiki, we’ll go ahead
>> and
>>>>> schedule
>>>>>>>> the
>>>>>>>>>> meetup to talk things out in a bit more detail. We’ll use
>>>> our new
>>>>>>>> Virtual
>>>>>>>>>> Ignite Meetup group for that inviting both Ignite
>>>> contributors and
>>>>>>>>>> application developers.
>>>>>>>>>>
>>>>>>>>>> Denis
>>>>>>>>>>
>>>>>>>>>> On Thursday, August 6, 2020, Saikat Maitra <
>>>> saikat.maitra@gmail.com
>>>>> <ma...@gmail.com>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Valentin
>>>>>>>>>>>
>>>>>>>>>>> Thank you for sharing and starting the thread. I am
>>>> thinking if it
>>>>>>>> will
>>>>>>>>>> be
>>>>>>>>>>> a good idea to have a virtual meet setup to discuss on the
>>>> release
>>>>>>>>>>> planning.
>>>>>>>>>>>
>>>>>>>>>>> It will help to learn more individual features to be added
>>>> and also
>>>>>>>> to
>>>>>>>>>>> understand about features that have been deprecated and
>>>> scheduled
>>>>> for
>>>>>>>>>>> removal in Ignite 3.0 release. Also it will help community
>>>> member
>>>>> to
>>>>>>>>>>> connect in real time and ask questions and share feedback.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Saikat
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <
>>>>>>>>>> ilya.kasnacheev@gmail.com <mailto:
>> ilya.kasnacheev@gmail.com
>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hello!
>>>>>>>>>>>>
>>>>>>>>>>>> I hope to see Apache Ignite release 3.0 as API trimming
>>>> release.
>>>>>>>> Let
>>>>>>>>> us
>>>>>>>>>>>> correct external and internal APIs for which we have
>>>> better ideas
>>>>>>>>> now,
>>>>>>>>>> as
>>>>>>>>>>>> well as remove old and deprecated code.
>>>>>>>>>>>>
>>>>>>>>>>>> We may also introduce new configuration mechanisms and
>>>> user-facing
>>>>>>>>> API
>>>>>>>>>>>> (such as cache-less native SQL queries), but this we
>> could
>>>>>>>> prototype
>>>>>>>>>>> before
>>>>>>>>>>>> starting the 3.0 task.
>>>>>>>>>>>>
>>>>>>>>>>>> I will advise against targeting large new features at
>> 3.0.
>>>> They
>>>>> can
>>>>>>>>> be
>>>>>>>>>>>> added in subsequent point releases, whereas we can't
>>>> really remove
>>>>>>>> or
>>>>>>>>>>>> remodel stuff in point releases.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> --
>>>>>>>>>>>> Ilya Kasnacheev
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
>>>>>>>>>>>> valentin.kulichenko@gmail.com <mailto:
>>>>> valentin.kulichenko@gmail.com>>:
>>>>>>>>>>>>
>>>>>>>>>>>>> Igniters,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I would like to kick off a discussion regarding Ignite
>>>> 3.0.
>>>>>>>> Ignite
>>>>>>>>>> 2.0
>>>>>>>>>>>>> exists for more than 3 years now and we've already
>>>> collected a
>>>>>>>>>>>> significant
>>>>>>>>>>>>> list [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://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
>>>> <
>>>>>
>>>>
>> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
>>>>>
>>>>>>>>>>> Apache+Ignite+3.0+Wishlist
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Val
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> -
>>>>>>>>>> Denis
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
Re: Apache Ignite 3.0
Posted by Pavel Tupitsyn <pt...@apache.org>.
Val,
The list of removals looks good to me, except Messaging.
I remember it had some implementation issues, but the API itself seems to
be rather useful -
what are we going to offer instead?
On Fri, Aug 14, 2020 at 3:16 AM Valentin Kulichenko <
valentin.kulichenko@gmail.com> wrote:
> 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
> is anything that should be added.
>
> -Val
>
> On Thu, Aug 13, 2020 at 4:55 PM Valentin Kulichenko <
> valentin.kulichenko@gmail.com> wrote:
>
> > Hi Ilya,
> >
> > Can you please describe your vision of how it should work?
> >
> > Let's say, I want to set up a cluster of several standalone server nodes
> > with a couple of optional modules enabled. What are my steps?
> >
> > -Val
> >
> > On Thu, Aug 13, 2020 at 6:03 AM Carbone, Adam <
> Adam.Carbone@bottomline.com>
> > wrote:
> >
> >> Good Morning from the EastCoast
> >>
> >> I have to agree that the larger industry is tending towards
> immutability,
> >> and that you build once and test, then you promote/migrate that
> immutable
> >> binary object, be is a library or a docker image etc... however there
> are
> >> still patterns that allow you to determine at install/or deployment
> time (
> >> helm as an example, you choose based on your values what the package
> >> installs/provides ) It just isn't decided at runtime but install and
> often
> >> in a gitops type world that is determined by configuration as code. I
> think
> >> run time is difficult to manage especially in our increasingly
> >> containerized world.
> >>
> >> Regards.
> >>
> >> Adam Carbone | Director of Innovation – Intelligent Platform Team |
> >> Bottomline Technologies
> >> Office: 603-501-6446 | Mobile: 603-570-8418
> >> www.bottomline.com
> >>
> >>
> >>
> >> On 8/13/20, 8:01 AM, "Ilya Kasnacheev" <il...@gmail.com>
> >> wrote:
> >>
> >> Hello!
> >>
> >> On the contrary, I would suggest that apache2 way was outdated even
> at
> >> times when apache was all rage.
> >>
> >> Now the nginx approach is prevalent: on devops phase, assemble a
> >> custom
> >> bundle with all plugins included, store it somewhere, and ship it to
> >> production as a whole to remove any on-the-fly uncertainty from
> >> production.
> >>
> >> This is what docker does, but also maven, which downloads
> dependencies
> >> during build. You do not need to download anything in runtime,
> except
> >> for
> >> experimental deployments. You need to be all set before runtime
> >> starts.
> >>
> >> Regards,
> >> --
> >> Ilya Kasnacheev
> >>
> >>
> >> ср, 12 авг. 2020 г. в 09:48, Petr Ivanov <mr...@gmail.com>:
> >>
> >> > Hi, Val.
> >> >
> >> > > On 12 Aug 2020, at 01:31, Valentin Kulichenko <
> >> > valentin.kulichenko@gmail.com> wrote:
> >> > >
> >> > > Hi Petr,
> >> > >
> >> > > I agree -- we should better modularize the platform. The current
> >> way if
> >> > very error-prone, especially during upgrades -- any changes made
> >> within
> >> > IGNITE_HOME (configs, scripts, modules, etc.) must be merged with
> a
> >> new
> >> > version of the package. There is no standard way of doing this.
> >> > >
> >> > > However, I'm a bit concerned with your suggestion regarding
> custom
> >> > dependency management. Can you please elaborate on how you think
> it
> >> should
> >> > work? Are there tools we can reuse for this purpose? I would try
> to
> >> avoid
> >> > reinventing the wheel.
> >> >
> >> > I see it as a a2enmod | 2dismod analog of Apache2.
> >> >
> >> > We build and store Apache Ignite and its modules as separate
> >> binaries
> >> > (binary per module) then use custom script that will know where to
> >> download
> >> > necessary module. Or possibly use modified ignite.sh to specify
> >> required
> >> > 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.
> >> >
> >> >
> >> > >
> >> > > -Val
> >> > >
> >> > > On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov <
> mr.weider@gmail.com
> >> > <ma...@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
> >> starting
> >> > Ignite and all other modules and parts of the project (benchmarks,
> >> > examples, etc.) packed in their own binary which can be added via
> >> custom
> >> > dependency management tool (i.e. modules.sh)
> >> > > — same distribution for RPM and DEB packages but with modules
> >> packed as
> >> > separate ones (PHP for example)
> >> > > — separate thin client release cycle with custom versioning
> >> > > Possibly, we can we add additional section to the document you
> >> > introduced for this part.
> >> > >
> >> > > Also, it seems that full JDK11 support (including building)
> would
> >> be a
> >> > huge milestone and a sign of healthy modern project that tends to
> >> be on the
> >> > verge of mainstream technologies and not the stockpile of legacy
> >> leftovers
> >> > (fully support Iliya in removing all that was deprecated and/or
> >> marked as
> >> > unused anymore).
> >> > >
> >> > >
> >> > > > On 8 Aug 2020, at 02:00, Valentin Kulichenko <
> >> > valentin.kulichenko@gmail.com <mailto:
> valentin.kulichenko@gmail.com
> >> >>
> >> > wrote:
> >> > > >
> >> > > > Igniters,
> >> > > >
> >> > > > I've created the page:
> >> > > >
> >>
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> >> <
> >> >
> >>
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> >> >
> >> > > >
> >> > > > 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 the consensus on the proposed
> changes,
> >> I will
> >> > > > start creating tickets in Jira and a more detailed plan.
> >> > > >
> >> > > > -Val
> >> > > >
> >> > > > On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <
> >> saikat.maitra@gmail.com
> >> > <ma...@gmail.com>>
> >> > > > wrote:
> >> > > >
> >> > > >> Hi Denis, Val
> >> > > >>
> >> > > >> Thank you for your reply and really appreciate it. It will be
> >> very
> >> > cool to
> >> > > >> be able to connect and plan release together and learn more
> >> about
> >> > Ignite in
> >> > > >> the process :)
> >> > > >>
> >> > > >> Regards
> >> > > >> Saikat
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >> On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko <
> >> > > >> valentin.kulichenko@gmail.com <mailto:
> >> valentin.kulichenko@gmail.com>>
> >> > wrote:
> >> > > >>
> >> > > >>> Hi Saikat,
> >> > > >>>
> >> > > >>> That surely is a great idea. We will work together with
> Denis
> >> on
> >> > setting
> >> > > >>> this up in the nearest future.
> >> > > >>>
> >> > > >>> -Val
> >> > > >>>
> >> > > >>> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <
> >> dmagda@apache.org
> >> > <ma...@apache.org>> wrote:
> >> > > >>>
> >> > > >>>> Saikat,
> >> > > >>>>
> >> > > >>>> Fully support your idea on a virtual meetup! Once Val
> >> collects and
> >> > > >>> outlines
> >> > > >>>> the main changes with directions on wiki, we’ll go ahead
> and
> >> > schedule
> >> > > >> the
> >> > > >>>> meetup to talk things out in a bit more detail. We’ll use
> >> our new
> >> > > >> Virtual
> >> > > >>>> Ignite Meetup group for that inviting both Ignite
> >> contributors and
> >> > > >>>> application developers.
> >> > > >>>>
> >> > > >>>> Denis
> >> > > >>>>
> >> > > >>>> On Thursday, August 6, 2020, Saikat Maitra <
> >> saikat.maitra@gmail.com
> >> > <ma...@gmail.com>>
> >> > > >>>> wrote:
> >> > > >>>>
> >> > > >>>>> Hi Valentin
> >> > > >>>>>
> >> > > >>>>> Thank you for sharing and starting the thread. I am
> >> thinking if it
> >> > > >> will
> >> > > >>>> be
> >> > > >>>>> a good idea to have a virtual meet setup to discuss on the
> >> release
> >> > > >>>>> planning.
> >> > > >>>>>
> >> > > >>>>> It will help to learn more individual features to be added
> >> and also
> >> > > >> to
> >> > > >>>>> understand about features that have been deprecated and
> >> scheduled
> >> > for
> >> > > >>>>> removal in Ignite 3.0 release. Also it will help community
> >> member
> >> > to
> >> > > >>>>> connect in real time and ask questions and share feedback.
> >> > > >>>>>
> >> > > >>>>> Regards,
> >> > > >>>>> Saikat
> >> > > >>>>>
> >> > > >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <
> >> > > >>>> ilya.kasnacheev@gmail.com <mailto:
> ilya.kasnacheev@gmail.com
> >> >>
> >> > > >>>>> wrote:
> >> > > >>>>>
> >> > > >>>>>> Hello!
> >> > > >>>>>>
> >> > > >>>>>> I hope to see Apache Ignite release 3.0 as API trimming
> >> release.
> >> > > >> Let
> >> > > >>> us
> >> > > >>>>>> correct external and internal APIs for which we have
> >> better ideas
> >> > > >>> now,
> >> > > >>>> as
> >> > > >>>>>> well as remove old and deprecated code.
> >> > > >>>>>>
> >> > > >>>>>> We may also introduce new configuration mechanisms and
> >> user-facing
> >> > > >>> API
> >> > > >>>>>> (such as cache-less native SQL queries), but this we
> could
> >> > > >> prototype
> >> > > >>>>> before
> >> > > >>>>>> starting the 3.0 task.
> >> > > >>>>>>
> >> > > >>>>>> I will advise against targeting large new features at
> 3.0.
> >> They
> >> > can
> >> > > >>> be
> >> > > >>>>>> added in subsequent point releases, whereas we can't
> >> really remove
> >> > > >> or
> >> > > >>>>>> remodel stuff in point releases.
> >> > > >>>>>>
> >> > > >>>>>> Regards,
> >> > > >>>>>> --
> >> > > >>>>>> Ilya Kasnacheev
> >> > > >>>>>>
> >> > > >>>>>>
> >> > > >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
> >> > > >>>>>> valentin.kulichenko@gmail.com <mailto:
> >> > valentin.kulichenko@gmail.com>>:
> >> > > >>>>>>
> >> > > >>>>>>> Igniters,
> >> > > >>>>>>>
> >> > > >>>>>>> I would like to kick off a discussion regarding Ignite
> >> 3.0.
> >> > > >> Ignite
> >> > > >>>> 2.0
> >> > > >>>>>>> exists for more than 3 years now and we've already
> >> collected a
> >> > > >>>>>> significant
> >> > > >>>>>>> list [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://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> >> <
> >> >
> >>
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> >> >
> >> > > >>>>> Apache+Ignite+3.0+Wishlist
> >> > > >>>>>>>
> >> > > >>>>>>> Regards,
> >> > > >>>>>>> Val
> >> > > >>>>>>>
> >> > > >>>>>>
> >> > > >>>>>
> >> > > >>>>
> >> > > >>>>
> >> > > >>>> --
> >> > > >>>> -
> >> > > >>>> Denis
> >> > > >>>>
> >> > > >>>
> >> > > >>
> >> > >
> >> >
> >> >
> >>
> >>
> >>
>
Re: Apache Ignite 3.0
Posted by Valentin Kulichenko <va...@gmail.com>.
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
is anything that should be added.
-Val
On Thu, Aug 13, 2020 at 4:55 PM Valentin Kulichenko <
valentin.kulichenko@gmail.com> wrote:
> Hi Ilya,
>
> Can you please describe your vision of how it should work?
>
> Let's say, I want to set up a cluster of several standalone server nodes
> with a couple of optional modules enabled. What are my steps?
>
> -Val
>
> On Thu, Aug 13, 2020 at 6:03 AM Carbone, Adam <Ad...@bottomline.com>
> wrote:
>
>> Good Morning from the EastCoast
>>
>> I have to agree that the larger industry is tending towards immutability,
>> and that you build once and test, then you promote/migrate that immutable
>> binary object, be is a library or a docker image etc... however there are
>> still patterns that allow you to determine at install/or deployment time (
>> helm as an example, you choose based on your values what the package
>> installs/provides ) It just isn't decided at runtime but install and often
>> in a gitops type world that is determined by configuration as code. I think
>> run time is difficult to manage especially in our increasingly
>> containerized world.
>>
>> Regards.
>>
>> Adam Carbone | Director of Innovation – Intelligent Platform Team |
>> Bottomline Technologies
>> Office: 603-501-6446 | Mobile: 603-570-8418
>> www.bottomline.com
>>
>>
>>
>> On 8/13/20, 8:01 AM, "Ilya Kasnacheev" <il...@gmail.com>
>> wrote:
>>
>> Hello!
>>
>> On the contrary, I would suggest that apache2 way was outdated even at
>> times when apache was all rage.
>>
>> Now the nginx approach is prevalent: on devops phase, assemble a
>> custom
>> bundle with all plugins included, store it somewhere, and ship it to
>> production as a whole to remove any on-the-fly uncertainty from
>> production.
>>
>> This is what docker does, but also maven, which downloads dependencies
>> during build. You do not need to download anything in runtime, except
>> for
>> experimental deployments. You need to be all set before runtime
>> starts.
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> ср, 12 авг. 2020 г. в 09:48, Petr Ivanov <mr...@gmail.com>:
>>
>> > Hi, Val.
>> >
>> > > On 12 Aug 2020, at 01:31, Valentin Kulichenko <
>> > valentin.kulichenko@gmail.com> wrote:
>> > >
>> > > Hi Petr,
>> > >
>> > > I agree -- we should better modularize the platform. The current
>> way if
>> > very error-prone, especially during upgrades -- any changes made
>> within
>> > IGNITE_HOME (configs, scripts, modules, etc.) must be merged with a
>> new
>> > version of the package. There is no standard way of doing this.
>> > >
>> > > However, I'm a bit concerned with your suggestion regarding custom
>> > dependency management. Can you please elaborate on how you think it
>> should
>> > work? Are there tools we can reuse for this purpose? I would try to
>> avoid
>> > reinventing the wheel.
>> >
>> > I see it as a a2enmod | 2dismod analog of Apache2.
>> >
>> > We build and store Apache Ignite and its modules as separate
>> binaries
>> > (binary per module) then use custom script that will know where to
>> download
>> > necessary module. Or possibly use modified ignite.sh to specify
>> required
>> > 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.
>> >
>> >
>> > >
>> > > -Val
>> > >
>> > > On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov <mr.weider@gmail.com
>> > <ma...@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
>> starting
>> > Ignite and all other modules and parts of the project (benchmarks,
>> > examples, etc.) packed in their own binary which can be added via
>> custom
>> > dependency management tool (i.e. modules.sh)
>> > > — same distribution for RPM and DEB packages but with modules
>> packed as
>> > separate ones (PHP for example)
>> > > — separate thin client release cycle with custom versioning
>> > > Possibly, we can we add additional section to the document you
>> > introduced for this part.
>> > >
>> > > Also, it seems that full JDK11 support (including building) would
>> be a
>> > huge milestone and a sign of healthy modern project that tends to
>> be on the
>> > verge of mainstream technologies and not the stockpile of legacy
>> leftovers
>> > (fully support Iliya in removing all that was deprecated and/or
>> marked as
>> > unused anymore).
>> > >
>> > >
>> > > > On 8 Aug 2020, at 02:00, Valentin Kulichenko <
>> > valentin.kulichenko@gmail.com <mailto:valentin.kulichenko@gmail.com
>> >>
>> > wrote:
>> > > >
>> > > > Igniters,
>> > > >
>> > > > I've created the page:
>> > > >
>> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
>> <
>> >
>> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
>> >
>> > > >
>> > > > 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 the consensus on the proposed changes,
>> I will
>> > > > start creating tickets in Jira and a more detailed plan.
>> > > >
>> > > > -Val
>> > > >
>> > > > On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <
>> saikat.maitra@gmail.com
>> > <ma...@gmail.com>>
>> > > > wrote:
>> > > >
>> > > >> Hi Denis, Val
>> > > >>
>> > > >> Thank you for your reply and really appreciate it. It will be
>> very
>> > cool to
>> > > >> be able to connect and plan release together and learn more
>> about
>> > Ignite in
>> > > >> the process :)
>> > > >>
>> > > >> Regards
>> > > >> Saikat
>> > > >>
>> > > >>
>> > > >>
>> > > >> On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko <
>> > > >> valentin.kulichenko@gmail.com <mailto:
>> valentin.kulichenko@gmail.com>>
>> > wrote:
>> > > >>
>> > > >>> Hi Saikat,
>> > > >>>
>> > > >>> That surely is a great idea. We will work together with Denis
>> on
>> > setting
>> > > >>> this up in the nearest future.
>> > > >>>
>> > > >>> -Val
>> > > >>>
>> > > >>> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <
>> dmagda@apache.org
>> > <ma...@apache.org>> wrote:
>> > > >>>
>> > > >>>> Saikat,
>> > > >>>>
>> > > >>>> Fully support your idea on a virtual meetup! Once Val
>> collects and
>> > > >>> outlines
>> > > >>>> the main changes with directions on wiki, we’ll go ahead and
>> > schedule
>> > > >> the
>> > > >>>> meetup to talk things out in a bit more detail. We’ll use
>> our new
>> > > >> Virtual
>> > > >>>> Ignite Meetup group for that inviting both Ignite
>> contributors and
>> > > >>>> application developers.
>> > > >>>>
>> > > >>>> Denis
>> > > >>>>
>> > > >>>> On Thursday, August 6, 2020, Saikat Maitra <
>> saikat.maitra@gmail.com
>> > <ma...@gmail.com>>
>> > > >>>> wrote:
>> > > >>>>
>> > > >>>>> Hi Valentin
>> > > >>>>>
>> > > >>>>> Thank you for sharing and starting the thread. I am
>> thinking if it
>> > > >> will
>> > > >>>> be
>> > > >>>>> a good idea to have a virtual meet setup to discuss on the
>> release
>> > > >>>>> planning.
>> > > >>>>>
>> > > >>>>> It will help to learn more individual features to be added
>> and also
>> > > >> to
>> > > >>>>> understand about features that have been deprecated and
>> scheduled
>> > for
>> > > >>>>> removal in Ignite 3.0 release. Also it will help community
>> member
>> > to
>> > > >>>>> connect in real time and ask questions and share feedback.
>> > > >>>>>
>> > > >>>>> Regards,
>> > > >>>>> Saikat
>> > > >>>>>
>> > > >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <
>> > > >>>> ilya.kasnacheev@gmail.com <mailto:ilya.kasnacheev@gmail.com
>> >>
>> > > >>>>> wrote:
>> > > >>>>>
>> > > >>>>>> Hello!
>> > > >>>>>>
>> > > >>>>>> I hope to see Apache Ignite release 3.0 as API trimming
>> release.
>> > > >> Let
>> > > >>> us
>> > > >>>>>> correct external and internal APIs for which we have
>> better ideas
>> > > >>> now,
>> > > >>>> as
>> > > >>>>>> well as remove old and deprecated code.
>> > > >>>>>>
>> > > >>>>>> We may also introduce new configuration mechanisms and
>> user-facing
>> > > >>> API
>> > > >>>>>> (such as cache-less native SQL queries), but this we could
>> > > >> prototype
>> > > >>>>> before
>> > > >>>>>> starting the 3.0 task.
>> > > >>>>>>
>> > > >>>>>> I will advise against targeting large new features at 3.0.
>> They
>> > can
>> > > >>> be
>> > > >>>>>> added in subsequent point releases, whereas we can't
>> really remove
>> > > >> or
>> > > >>>>>> remodel stuff in point releases.
>> > > >>>>>>
>> > > >>>>>> Regards,
>> > > >>>>>> --
>> > > >>>>>> Ilya Kasnacheev
>> > > >>>>>>
>> > > >>>>>>
>> > > >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
>> > > >>>>>> valentin.kulichenko@gmail.com <mailto:
>> > valentin.kulichenko@gmail.com>>:
>> > > >>>>>>
>> > > >>>>>>> Igniters,
>> > > >>>>>>>
>> > > >>>>>>> I would like to kick off a discussion regarding Ignite
>> 3.0.
>> > > >> Ignite
>> > > >>>> 2.0
>> > > >>>>>>> exists for more than 3 years now and we've already
>> collected a
>> > > >>>>>> significant
>> > > >>>>>>> list [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://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
>> <
>> >
>> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
>> >
>> > > >>>>> Apache+Ignite+3.0+Wishlist
>> > > >>>>>>>
>> > > >>>>>>> Regards,
>> > > >>>>>>> Val
>> > > >>>>>>>
>> > > >>>>>>
>> > > >>>>>
>> > > >>>>
>> > > >>>>
>> > > >>>> --
>> > > >>>> -
>> > > >>>> Denis
>> > > >>>>
>> > > >>>
>> > > >>
>> > >
>> >
>> >
>>
>>
>>
Re: Apache Ignite 3.0
Posted by Ivan Daschinsky <iv...@gmail.com>.
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 example Apache Zookeeper or
some other proprietary external lock service, we could provide basic
interfaces to do the job.
> Thus, by default, they will be mixed which will significantly simplify
cluster setup and usability.
According to raft specs, the leader processes all requests from clients.
Leader's response latency is a crucial thing for the whole cluster
stability.
Cluster setup simplicity is a subject of documentation, scripts and so on,
i.e. starting kafka is quite easy.
Also, if we use mixed approach, service discovery protocol should be
implemented.This is necessary, because we should discover nodes firstly in
order to choose finite subset for RAFT ensemble.
For example, Consul by HashiCorp uses gossip protocol to do the job. (Nodes
participating in RAFT are called servers, [1]
If we use separated approach, we could use service discovery pattern that
is common for zookeeper or etcd (data node create record with TTL and renew
it. (EPHEMERAL node approach for zk),
other data nodes watches for new records)
Some words about PacificA
Article [2] -- is just brief descriptions and ideas. Alexey, is there any
formal specification of this protocol? Preferrably in TLA+?
[1] -- https://www.consul.io/docs/architecture/gossip
[2] --
https://www.microsoft.com/en-us/research/wp-content/uploads/2008/02/tr-2008-25.pdf
пт, 23 окт. 2020 г. в 13:05, Alexey Goncharuk <al...@gmail.com>:
> Hello Ivan,
>
> Thanks for the feedback, see my comments inline:
>
> чт, 22 окт. 2020 г. в 17:59, Ivan Daschinsky <iv...@gmail.com>:
>
> > 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 bear cache data and
> participate
> > in cache transactions?
> > As for me, it seems quite dangerous to mix roles. For example, heavy
> > load from users can cause long GC pauses on leader of replication group
> and
> > therefore failure, new leader election, etc.
> >
> I think both ways should be possible. The set of nodes that hold
> metastorage should be defined declaratively in runtime, as well as the set
> of nodes holding table data. Thus, by default, they will be mixed which
> will significantly simplify cluster setup and usability, but when needed,
> this should be easily adjusted in runtime by the cluster administrator.
>
>
> > 2. If previous statement is true, other question arises. If one of
> > candidates or leader fails, how will a insufficient node will be chosen
> > from regular nodes to form full ensemble? Random one?
> >
> Similarly - by default, a 'best' node will be chosen from the available
> ones, but the administrator can override this.
>
>
> > 3. Do you think, that this metastorage implementation can be pluggable?
> it
> > can be implemented on top of etcd, for example.
>
> I think the metastorage abstraction must be clearly separated so it is
> possible to change the implementation. Moreover, I was thinking that we may
> use etcd to speed up the development of other system components while we
> are working on our own protocol implementation. However, I do not think we
> should expose it as a pluggable public API. 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.
>
> WDYT?
>
--
Sincerely yours, Ivan Daschinskiy
Re: Apache Ignite 3.0
Posted by Alexey Goncharuk <al...@gmail.com>.
Hello Ivan,
Thanks for the feedback, see my comments inline:
чт, 22 окт. 2020 г. в 17:59, Ivan Daschinsky <iv...@gmail.com>:
> 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 bear cache data and participate
> in cache transactions?
> As for me, it seems quite dangerous to mix roles. For example, heavy
> load from users can cause long GC pauses on leader of replication group and
> therefore failure, new leader election, etc.
>
I think both ways should be possible. The set of nodes that hold
metastorage should be defined declaratively in runtime, as well as the set
of nodes holding table data. Thus, by default, they will be mixed which
will significantly simplify cluster setup and usability, but when needed,
this should be easily adjusted in runtime by the cluster administrator.
> 2. If previous statement is true, other question arises. If one of
> candidates or leader fails, how will a insufficient node will be chosen
> from regular nodes to form full ensemble? Random one?
>
Similarly - by default, a 'best' node will be chosen from the available
ones, but the administrator can override this.
> 3. Do you think, that this metastorage implementation can be pluggable? it
> can be implemented on top of etcd, for example.
I think the metastorage abstraction must be clearly separated so it is
possible to change the implementation. Moreover, I was thinking that we may
use etcd to speed up the development of other system components while we
are working on our own protocol implementation. However, I do not think we
should expose it as a pluggable public API. 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.
WDYT?
Re: Apache Ignite 3.0
Posted by Ivan Daschinsky <iv...@gmail.com>.
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 bear cache data and participate
in cache transactions?
As for me, it seems quite dangerous to mix roles. For example, heavy
load from users can cause long GC pauses on leader of replication group and
therefore failure, new leader election, etc.
2. If previous statement is true, other question arises. If one of
candidates or leader fails, how will a insufficient node will be chosen
from regular nodes to form full ensemble? Random one?
3. Do you think, that this metastorage implementation can be pluggable? it
can be implemented on top of etcd, for example.
чт, 22 окт. 2020 г. в 13:04, Alexey Goncharuk <al...@gmail.com>:
> 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 makes sense and should be covered by the distributed
> metastorage approach described in [1]. A client can read and watch updates
> for the cluster configuration and run solely based on that config.
>
>
> > 2. Thread per partition. Again. I strongly recommend taking a look at how
> > Scylla DB operates. I think this is the best distributed database
> threading
> > model and can be a perfect fit for Ignite. Main idea is in "share
> nothing"
> > approach - they keep thread switches to the necessary minimum - messages
> > reading or updating data are processed within the thread that reads them
> > (of course, the sender should properly route the message, i.e. send it to
> > the correct socket). Blocking operations such as fsync happen outside of
> > worker (shard) threads.
> > This will require to split indexes per partition which should be quite ok
> > for most of the use cases in my view. Edge cases with high-selectivity
> > indexes selecting 1-2 rows for a value can be sped up with hash indexes
> or
> > even by secondary index backed by another cache.
> >
> Generally agree, and again this is what we will naturally have when we
> implement any log-based replication protocol [1]. However, I think it makes
> sense to separate the operation replication, which can be done in one
> thread, and actual command execution. The command execution can be done
> asynchronously thus reducing the latency of any operation to a single log
> append + fsync.
>
>
> > 3. Replicate physical updates instead of logical. This will simplify
> logic
> > running on backups to zero. Read a page sent by the primary node and
> apply
> > it locally. Most probably this change will require pure thread per
> > partition described above.
> >
> Not sure about this, I think this approach has the following disadvantages:
> * We will not be able to replicate a single page update as such an update
> usually leaves storage in a corrupted state. Therefore, we will still have
> to group pages into batches which must be applied atomically, thus
> complicating the protocol
> * Physical replication will result in significant network traffic
> amplification, especially for cases with large inline indexes. The same
> goes for EntryProcessors - we will have to replicate huge values while a
> small operation modifying a large object could have been replicated
> * Physical replication complicates a road for Ignite to support a rolling
> upgrade in the future. If we choose to change the local storage format, we
> will have to somehow convert a new binary format to the old at replication
> time when sending from new to old nodes, and additionally support forward
> conversion on new nodes if an old node is a replication group leader
> * Finally, this approach closes the road to having different storage
> formats on different nodes (for example, have one of the nodes in the
> replication group keep data in columnar format, as it is done in TiDB).
> This allows us to route analytical queries to separate dedicated nodes
> without affecting the performance properties of the whole replication
> group.
>
>
> > 4. Merge (all?) network components (communication, disco, REST, etc?) and
> > listen to one port.
> >
> Makes sense. There is no clear design for this though, we did not even
> discuss this in detail. I am not even sure we need separate discovery and
> communication services, as they are very dependent; on the other hand, a
> lot of discovery functions are moved to the distributed metastore.
>
>
>
> > 5. Revisit transaction concurrency and isolation settings. Currently some
> > of the combinations do not work as users may expect them to and some look
> > just weird.
> >
> Agree, looks like we can cut more than half of the transaction modes
> without sacrificing functionality at all. However, similarly to the single
> port point, we did not discuss how exactly the transactional protocol will
> look like yet, so this is an open question. Once I put my thoughts
> together, I will create an IEP for this (unless somebody does it earlier,
> of course).
>
> --AG
>
> [1]
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-61%3A+Common+Replication+Infrastructure
> <
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-61%3A+Common+Replication+Infrastructure
> >
>
--
Sincerely yours, Ivan Daschinskiy
Re: Apache Ignite 3.0
Posted by Yakov Zhdanov <ya...@gmail.com>.
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 the
serialized processor is of smaller size then we can send it instead of the
delta. This can sound like an overcomplication, but still good to measure.
Regards,
Yakov
Re: Apache Ignite 3.0
Posted by Alexey Goncharuk <al...@gmail.com>.
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 makes sense and should be covered by the distributed
metastorage approach described in [1]. A client can read and watch updates
for the cluster configuration and run solely based on that config.
> 2. Thread per partition. Again. I strongly recommend taking a look at how
> Scylla DB operates. I think this is the best distributed database threading
> model and can be a perfect fit for Ignite. Main idea is in "share nothing"
> approach - they keep thread switches to the necessary minimum - messages
> reading or updating data are processed within the thread that reads them
> (of course, the sender should properly route the message, i.e. send it to
> the correct socket). Blocking operations such as fsync happen outside of
> worker (shard) threads.
> This will require to split indexes per partition which should be quite ok
> for most of the use cases in my view. Edge cases with high-selectivity
> indexes selecting 1-2 rows for a value can be sped up with hash indexes or
> even by secondary index backed by another cache.
>
Generally agree, and again this is what we will naturally have when we
implement any log-based replication protocol [1]. However, I think it makes
sense to separate the operation replication, which can be done in one
thread, and actual command execution. The command execution can be done
asynchronously thus reducing the latency of any operation to a single log
append + fsync.
> 3. Replicate physical updates instead of logical. This will simplify logic
> running on backups to zero. Read a page sent by the primary node and apply
> it locally. Most probably this change will require pure thread per
> partition described above.
>
Not sure about this, I think this approach has the following disadvantages:
* We will not be able to replicate a single page update as such an update
usually leaves storage in a corrupted state. Therefore, we will still have
to group pages into batches which must be applied atomically, thus
complicating the protocol
* Physical replication will result in significant network traffic
amplification, especially for cases with large inline indexes. The same
goes for EntryProcessors - we will have to replicate huge values while a
small operation modifying a large object could have been replicated
* Physical replication complicates a road for Ignite to support a rolling
upgrade in the future. If we choose to change the local storage format, we
will have to somehow convert a new binary format to the old at replication
time when sending from new to old nodes, and additionally support forward
conversion on new nodes if an old node is a replication group leader
* Finally, this approach closes the road to having different storage
formats on different nodes (for example, have one of the nodes in the
replication group keep data in columnar format, as it is done in TiDB).
This allows us to route analytical queries to separate dedicated nodes
without affecting the performance properties of the whole replication group.
> 4. Merge (all?) network components (communication, disco, REST, etc?) and
> listen to one port.
>
Makes sense. There is no clear design for this though, we did not even
discuss this in detail. I am not even sure we need separate discovery and
communication services, as they are very dependent; on the other hand, a
lot of discovery functions are moved to the distributed metastore.
> 5. Revisit transaction concurrency and isolation settings. Currently some
> of the combinations do not work as users may expect them to and some look
> just weird.
>
Agree, looks like we can cut more than half of the transaction modes
without sacrificing functionality at all. However, similarly to the single
port point, we did not discuss how exactly the transactional protocol will
look like yet, so this is an open question. Once I put my thoughts
together, I will create an IEP for this (unless somebody does it earlier,
of course).
--AG
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-61%3A+Common+Replication+Infrastructure
<https://cwiki.apache.org/confluence/display/IGNITE/IEP-61%3A+Common+Replication+Infrastructure>
Re: Apache Ignite 3.0
Posted by Yakov Zhdanov <ya...@gmail.com>.
Hey Valentin!
Any design docs/wiki for 1, 4 and 5 so far?
Yakov Zhdanov
Re: Apache Ignite 3.0
Posted by Valentin Kulichenko <va...@gmail.com>.
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 <ya...@gmail.com>
wrote:
> 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.
>
[Val] We will have a meta-store that will store the cluster-wide
configuration (among other things). Whether it's a server or a client, any
new node will be able to fetch the required information from there. In
practice, it will work how you describe - just provide an IP address and
you are good to go.
>
> 2. Thread per partition. Again. I strongly recommend taking a look at how
> Scylla DB operates. I think this is the best distributed database threading
> model and can be a perfect fit for Ignite. Main idea is in "share nothing"
> approach - they keep thread switches to the necessary minimum - messages
> reading or updating data are processed within the thread that reads them
> (of course, the sender should properly route the message, i.e. send it to
> the correct socket). Blocking operations such as fsync happen outside of
> worker (shard) threads.
> This will require to split indexes per partition which should be quite ok
> for most of the use cases in my view. Edge cases with high-selectivity
> indexes selecting 1-2 rows for a value can be sped up with hash indexes or
> even by secondary index backed by another cache.
>
> 3. Replicate physical updates instead of logical. This will simplify logic
> running on backups to zero. Read a page sent by the primary node and apply
> it locally. Most probably this change will require pure thread per
> partition described above.
> 4. Merge (all?) network components (communication, disco, REST, etc?) and
> listen to one port.
>
[Val] This is in plans at least for the communication and disco. We'll see
how it goes for other components.
>
> 5. Revisit transaction concurrency and isolation settings. Currently some
> of the combinations do not work as users may expect them to and some look
> just weird.
>
[Val] Also planned.
>
> Ready to discuss the above and other points.
>
> Thanks!
> Yakov
>
Re: Apache Ignite 3.0
Posted by Yakov Zhdanov <ya...@gmail.com>.
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 look at how
Scylla DB operates. I think this is the best distributed database threading
model and can be a perfect fit for Ignite. Main idea is in "share nothing"
approach - they keep thread switches to the necessary minimum - messages
reading or updating data are processed within the thread that reads them
(of course, the sender should properly route the message, i.e. send it to
the correct socket). Blocking operations such as fsync happen outside of
worker (shard) threads.
This will require to split indexes per partition which should be quite ok
for most of the use cases in my view. Edge cases with high-selectivity
indexes selecting 1-2 rows for a value can be sped up with hash indexes or
even by secondary index backed by another cache.
3. Replicate physical updates instead of logical. This will simplify logic
running on backups to zero. Read a page sent by the primary node and apply
it locally. Most probably this change will require pure thread per
partition described above.
4. Merge (all?) network components (communication, disco, REST, etc?) and
listen to one port.
5. Revisit transaction concurrency and isolation settings. Currently some
of the combinations do not work as users may expect them to and some look
just weird.
Ready to discuss the above and other points.
Thanks!
Yakov
Re: Apache Ignite 3.0
Posted by 18624049226 <18...@163.com>.
Hi Val,
AFAIK, many developers use Ignite as a powerful development framework
for distributed applications.
The messaging function is easy to use. With it, many systems do not need
to introduce a special message system such as Kafka. Although this
function does not seem to coordinate with ignite's positioning, but it
does make the overall system architecture simple.
在 2020/9/17 下午1:21, Valentin Kulichenko 写道:
> Raymond,
>
> Can you please describe the way you use messaging in a little bit more
> detail? Is it for communication between server nodes or more of a
> client-server? what are the typical patterns?
>
> -Val
>
> On Wed, Sep 16, 2020 at 4:05 PM Raymond Wilson <ra...@trimble.com>
> wrote:
>
>> Hi Val,
>>
>> Possibly, but the core difficulty there is knowing when the fan-out to
>> listeners has been completed. Before you know it you have
>> re-implemented Kafka! :)
>>
>> I think we can leverage our use case knowledge to convert the messaging
>> style of notifications to a compute style broadcast against a compute
>> projection using an attribute based selection for nodes that want to be
>> listeners for the events. The messaging rate is relatively low (a few
>> messages a second) so this should be pretty workable.
>>
>> Raymond.
>>
>> On Thu, Sep 17, 2020 at 3:27 AM Valentin Kulichenko <
>> valentin.kulichenko@gmail.com> wrote:
>>
>>> Hi Raymond,
>>>
>>> Do you think you could use services for your use case?
>>> https://apacheignite.readme.io/docs/service-grid
>>>
>>> -Val
>>>
>>> On Tue, Sep 15, 2020 at 4:32 PM Raymond Wilson <
>> raymond_wilson@trimble.com
>>> wrote:
>>>
>>>> For what it is worth, we use messaging in Ignite to provide grid
>>>> notifications for various purposes. These might stimulate compute
>>>> operations in the message recipients, but they don't represent compute.
>>>>
>>>> If messaging is removed, how would Ignite provide the ability for a
>> node
>>> to
>>>> listen to events without the event sender being explicitly aware that
>> the
>>>> listener does, or should, exist, to produce a compute projection to
>> send
>>>> messages-as-compute-requests to?
>>>>
>>>> On Wed, Sep 16, 2020 at 9:28 AM Kseniya Romanova <
>>>> romanova.ks.spb@gmail.com>
>>>> wrote:
>>>>
>>>>> Just wanted to submit a link to the video about some offered changes.
>>>>> @valentin.kulichenko@gmail.com <va...@gmail.com>
>> please
>>>> add
>>>>> it to the wiki page. I created timestamps in the description, so one
>>> can
>>>>> browse the presentation fast or link the particular section:
>>>>> https://youtu.be/zPuLJgUfLaM
>>>>> Thanks a lot for the presentation!
>>>>>
>>>>> вт, 18 авг. 2020 г. в 14:13, Ilya Kasnacheev <
>>> ilya.kasnacheev@gmail.com
>>>>> :
>>>>>
>>>>>> Hello!
>>>>>>
>>>>>> Maybe we can implement messaging via compute? Share underlying code
>>> but
>>>>>> have a different API for convenience (maybe in extras).
>>>>>>
>>>>>> Regards,
>>>>>> --
>>>>>> Ilya Kasnacheev
>>>>>>
>>>>>>
>>>>>> вт, 18 авг. 2020 г. в 11:59, Pavel Tupitsyn <ptupitsyn@apache.org
>>> :
>>>>>>> Val,
>>>>>>>
>>>>>>>> Is see the ".NET Modernization for Ignite 3.0" item in the
>>> roadmap,
>>>>> but
>>>>>>> it
>>>>>>>> doesn't provide much detail. What are the actual changes in
>> .NET
>>>> that
>>>>>> you
>>>>>>>> propose for 3.0?
>>>>>>> I've updated the roadmap with a brief description.
>>>>>>> We want to move away from an old, long unsupported .NET version,
>>>>>>> and remove integrations with legacy technologies (old ASP.NET
>> and
>>>> EF).
>>>>>>>> As for the messaging, so far I haven't seen use cases that
>> would
>>>>>> require
>>>>>>>> this API. Sometimes users attempt to use it for remote code
>>>>> invocation,
>>>>>>> but
>>>>>>>> compute is usually 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.
>>>>>>> Messaging can be more convenient, since it is pub-sub -
>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Aug 18, 2020 at 3:16 AM Saikat Maitra <
>>>> saikat.maitra@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 Tupitsyn <
>>>>> ptupitsyn@apache.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Saikat, yes, most definitely.
>>>>>>>>> This is mentioned in the wishlist under ".NET: Target .NET
>>>> Standard
>>>>>>> 2.0,
>>>>>>>>> discontinue .NET 4.0 support".
>>>>>>>>> I'm already working towards this goal by making more code and
>>>> tests
>>>>>>> work
>>>>>>>>> properly under .NET Core,
>>>>>>>>> so when the time for breaking changes comes, it will be
>>> simpler.
>>>>>>>>> On Sat, Aug 15, 2020 at 10:06 PM Saikat Maitra <
>>>>>>> saikat.maitra@gmail.com>
>>>>>>>>> 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
>>>>>>>>>> release?
>>>>>>>>>>
>>>>>>>>>>
>> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap
>>>>>>>>>> Regards,
>>>>>>>>>> Saikat
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Aug 14, 2020 at 10:04 AM Carbone, Adam <
>>>>>>>>>> Adam.Carbone@bottomline.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> If you want to make is simpler to have the components
>> that
>>>> you
>>>>>>> want,
>>>>>>>>> but
>>>>>>>>>>> have that be immutable at install time you could take an
>>>>> approach
>>>>>>>>> similar
>>>>>>>>>>> to the way spring does it with their initializer (
>>>>>>>>>>> https://start.spring.io/ ) as an example... Basically
>> the
>>>>>> concept
>>>>>>>>> being
>>>>>>>>>>> something that produces a set of configurations that are
>>> used
>>>>> to
>>>>>>>> define
>>>>>>>>>>> what the environment looks like ( these could be k8s
>>> objects
>>>> )
>>>>>> they
>>>>>>>>> could
>>>>>>>>>>> be spring-configuration objects? They could be something
>>> that
>>>>> you
>>>>>>>>> develop
>>>>>>>>>>> all upon ignite ( probably wouldn’t recommend this
>>> approach )
>>>>>>> there
>>>>>>>>>> seems
>>>>>>>>>>> to be plenty of these types of things already
>>>>>>>>>>>
>>>>>>>>>>> Example
>>>>>>>>>>> * https://spring.io/guides/gs/centralized-configuration
>>>>>>>>>>> *
>>>>>>>>>>>
>> https://cocoon.apache.org/subprojects/configuration/spring-configurator/index.html
>>>>>>>>>>> And I'm by no means saying to use spring these are just
>>>>> examples
>>>>>>>> that I
>>>>>>>>>>> came across
>>>>>>>>>>>
>>>>>>>>>>> I'm thinking the outcome needs to be a platform config of
>>>>> source
>>>>>> (
>>>>>>>> that
>>>>>>>>>>> can be checked in for those doing gitops ) and maybe ends
>>> up
>>>>> as a
>>>>>>>>> config
>>>>>>>>>>> map for those doing k8s, and some other fashion for those
>>>> doing
>>>>>>>>> something
>>>>>>>>>>> else.
>>>>>>>>>>>
>>>>>>>>>>> Honestly I am not deep enough into the internals of
>> ignite
>>> to
>>>>>> know
>>>>>>>> how
>>>>>>>>>>> this might work for the platform, was more describing
>> what
>>>> I'm
>>>>>>> seeing
>>>>>>>>>> from
>>>>>>>>>>> a bigger picture trend
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>>
>>>>>>>>>>> Adam Carbone | Director of Innovation – Intelligent
>>> Platform
>>>>>> Team |
>>>>>>>>>>> Bottomline Technologies
>>>>>>>>>>> Office: 603-501-6446 | Mobile: 603-570-8418
>>>>>>>>>>> www.bottomline.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 8/13/20, 7:55 PM, "Valentin Kulichenko" <
>>>>>>>>>> valentin.kulichenko@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Ilya,
>>>>>>>>>>>
>>>>>>>>>>> Can you please describe your vision of how it should
>>>> work?
>>>>>>>>>>> Let's say, I want to set up a cluster of several
>>>> standalone
>>>>>>>> server
>>>>>>>>>>> nodes
>>>>>>>>>>> with a couple of optional modules enabled. What are
>> my
>>>>> steps?
>>>>>>>>>>> -Val
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Aug 13, 2020 at 6:03 AM Carbone, Adam <
>>>>>>>>>>> Adam.Carbone@bottomline.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> > Good Morning from the EastCoast
>>>>>>>>>>> >
>>>>>>>>>>> > I have to agree that the larger industry is tending
>>>>> towards
>>>>>>>>>>> immutability,
>>>>>>>>>>> > and that you build once and test, then you
>>>>> promote/migrate
>>>>>>> that
>>>>>>>>>>> immutable
>>>>>>>>>>> > binary object, be is a library or a docker image
>>> etc...
>>>>>>> however
>>>>>>>>>>> there are
>>>>>>>>>>> > still patterns that allow you to determine at
>>>> install/or
>>>>>>>>> deployment
>>>>>>>>>>> time (
>>>>>>>>>>> > helm as an example, you choose based on your values
>>>> what
>>>>>> the
>>>>>>>>>> package
>>>>>>>>>>> > installs/provides ) It just isn't decided at
>> runtime
>>>> but
>>>>>>>> install
>>>>>>>>>> and
>>>>>>>>>>> often
>>>>>>>>>>> > in a gitops type world that is determined by
>>>>> configuration
>>>>>> as
>>>>>>>>> code.
>>>>>>>>>>> I think
>>>>>>>>>>> > run time is difficult to manage especially in our
>>>>>>> increasingly
>>>>>>>>>>> > containerized world.
>>>>>>>>>>> >
>>>>>>>>>>> > Regards.
>>>>>>>>>>> >
>>>>>>>>>>> > Adam Carbone | Director of Innovation – Intelligent
>>>>>> Platform
>>>>>>>>> Team |
>>>>>>>>>>> > Bottomline Technologies
>>>>>>>>>>> > Office: 603-501-6446 | Mobile: 603-570-8418
>>>>>>>>>>> > www.bottomline.com
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> > On 8/13/20, 8:01 AM, "Ilya Kasnacheev" <
>>>>>>>>> ilya.kasnacheev@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>> >
>>>>>>>>>>> > Hello!
>>>>>>>>>>> >
>>>>>>>>>>> > On the contrary, I would suggest that apache2
>> way
>>>> was
>>>>>>>>> outdated
>>>>>>>>>>> even at
>>>>>>>>>>> > times when apache was all rage.
>>>>>>>>>>> >
>>>>>>>>>>> > Now the nginx approach is prevalent: on devops
>>>> phase,
>>>>>>>>> assemble
>>>>>>>>>> a
>>>>>>>>>>> custom
>>>>>>>>>>> > bundle with all plugins included, store it
>>>> somewhere,
>>>>>> and
>>>>>>>>> ship
>>>>>>>>>>> it to
>>>>>>>>>>> > production as a whole to remove any on-the-fly
>>>>>>> uncertainty
>>>>>>>>> from
>>>>>>>>>>> > production.
>>>>>>>>>>> >
>>>>>>>>>>> > This is what docker does, but also maven, which
>>>>>> downloads
>>>>>>>>>>> dependencies
>>>>>>>>>>> > during build. You do not need to download
>>> anything
>>>> in
>>>>>>>>> runtime,
>>>>>>>>>>> except
>>>>>>>>>>> > for
>>>>>>>>>>> > experimental deployments. You need to be all
>> set
>>>>> before
>>>>>>>>> runtime
>>>>>>>>>>> starts.
>>>>>>>>>>> >
>>>>>>>>>>> > Regards,
>>>>>>>>>>> > --
>>>>>>>>>>> > Ilya Kasnacheev
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> > ср, 12 авг. 2020 г. в 09:48, Petr Ivanov <
>>>>>>>>> mr.weider@gmail.com
>>>>>>>>>>> :
>>>>>>>>>>> >
>>>>>>>>>>> > > Hi, Val.
>>>>>>>>>>> > >
>>>>>>>>>>> > > > On 12 Aug 2020, at 01:31, Valentin
>>> Kulichenko <
>>>>>>>>>>> > > valentin.kulichenko@gmail.com> wrote:
>>>>>>>>>>> > > >
>>>>>>>>>>> > > > Hi Petr,
>>>>>>>>>>> > > >
>>>>>>>>>>> > > > I agree -- we should better modularize the
>>>>>> platform.
>>>>>>>> The
>>>>>>>>>>> current
>>>>>>>>>>> > way if
>>>>>>>>>>> > > very error-prone, especially during upgrades
>> --
>>>> any
>>>>>>>> changes
>>>>>>>>>>> made
>>>>>>>>>>> > within
>>>>>>>>>>> > > IGNITE_HOME (configs, scripts, modules, etc.)
>>>> must
>>>>> be
>>>>>>>>> merged
>>>>>>>>>>> with a
>>>>>>>>>>> > new
>>>>>>>>>>> > > version of the package. There is no standard
>>> way
>>>> of
>>>>>>> doing
>>>>>>>>>> this.
>>>>>>>>>>> > > >
>>>>>>>>>>> > > > However, I'm a bit concerned with your
>>>> suggestion
>>>>>>>>> regarding
>>>>>>>>>>> custom
>>>>>>>>>>> > > dependency management. Can you please
>> elaborate
>>>> on
>>>>>> how
>>>>>>>> you
>>>>>>>>>>> think it
>>>>>>>>>>> > should
>>>>>>>>>>> > > work? Are there tools we can reuse for this
>>>>> purpose?
>>>>>> I
>>>>>>>>> would
>>>>>>>>>>> try to
>>>>>>>>>>> > avoid
>>>>>>>>>>> > > reinventing the wheel.
>>>>>>>>>>> > >
>>>>>>>>>>> > > I see it as a a2enmod | 2dismod analog of
>>>> Apache2.
>>>>>>>>>>> > >
>>>>>>>>>>> > > We build and store Apache Ignite and its
>>> modules
>>>> as
>>>>>>>>> separate
>>>>>>>>>>> binaries
>>>>>>>>>>> > > (binary per module) then use custom script
>> that
>>>>> will
>>>>>>> know
>>>>>>>>>>> where to
>>>>>>>>>>> > download
>>>>>>>>>>> > > necessary module. Or possibly use modified
>>>>> ignite.sh
>>>>>> to
>>>>>>>>>> specify
>>>>>>>>>>> > required
>>>>>>>>>>> > > 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.
>>>>>>>>>>> > >
>>>>>>>>>>> > >
>>>>>>>>>>> > > >
>>>>>>>>>>> > > > -Val
>>>>>>>>>>> > > >
>>>>>>>>>>> > > > On Sun, Aug 9, 2020 at 11:25 PM Petr
>> Ivanov <
>>>>>>>>>>> mr.weider@gmail.com
>>>>>>>>>>> > > <ma...@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
>>>>>>>>>>> > starting
>>>>>>>>>>> > > Ignite and all other modules and parts of the
>>>>> project
>>>>>>>>>>> (benchmarks,
>>>>>>>>>>> > > examples, etc.) packed in their own binary
>>> which
>>>>> can
>>>>>> be
>>>>>>>>> added
>>>>>>>>>>> via
>>>>>>>>>>> > custom
>>>>>>>>>>> > > dependency management tool (i.e. modules.sh)
>>>>>>>>>>> > > > — same distribution for RPM and DEB
>> packages
>>>> but
>>>>>>> with
>>>>>>>>>>> modules
>>>>>>>>>>> > packed as
>>>>>>>>>>> > > separate ones (PHP for example)
>>>>>>>>>>> > > > — separate thin client release cycle with
>>>> custom
>>>>>>>>>> versioning
>>>>>>>>>>> > > > Possibly, we can we add additional section
>> to
>>>> the
>>>>>>>>> document
>>>>>>>>>>> you
>>>>>>>>>>> > > introduced for this part.
>>>>>>>>>>> > > >
>>>>>>>>>>> > > > Also, it seems that full JDK11 support
>>>> (including
>>>>>>>>> building)
>>>>>>>>>>> would
>>>>>>>>>>> > be a
>>>>>>>>>>> > > huge milestone and a sign of healthy modern
>>>> project
>>>>>>> that
>>>>>>>>>> tends
>>>>>>>>>>> to be
>>>>>>>>>>> > on the
>>>>>>>>>>> > > verge of mainstream technologies and not the
>>>>>> stockpile
>>>>>>> of
>>>>>>>>>>> legacy
>>>>>>>>>>> > leftovers
>>>>>>>>>>> > > (fully support Iliya in removing all that was
>>>>>>> deprecated
>>>>>>>>>> and/or
>>>>>>>>>>> > marked as
>>>>>>>>>>> > > unused anymore).
>>>>>>>>>>> > > >
>>>>>>>>>>> > > >
>>>>>>>>>>> > > > > On 8 Aug 2020, at 02:00, Valentin
>>> Kulichenko
>>>> <
>>>>>>>>>>> > > valentin.kulichenko@gmail.com <mailto:
>>>>>>>>>>> valentin.kulichenko@gmail.com
>>>>>>>>>>> > >>
>>>>>>>>>>> > > wrote:
>>>>>>>>>>> > > > >
>>>>>>>>>>> > > > > Igniters,
>>>>>>>>>>> > > > >
>>>>>>>>>>> > > > > I've created the page:
>>>>>>>>>>> > > > >
>>>>>>>>>>> >
>>>>>>>>>>>
>> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
>>>>>>>>>>> > <
>>>>>>>>>>> > >
>>>>>>>>>>> >
>>>>>>>>>>>
>> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
>>>>>>>>>>> > >
>>>>>>>>>>> > > > >
>>>>>>>>>>> > > > > 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 the consensus on
>>> the
>>>>>>>> proposed
>>>>>>>>>>> changes,
>>>>>>>>>>> > I will
>>>>>>>>>>> > > > > start creating tickets in Jira and a more
>>>>>> detailed
>>>>>>>>> plan.
>>>>>>>>>>> > > > >
>>>>>>>>>>> > > > > -Val
>>>>>>>>>>> > > > >
>>>>>>>>>>> > > > > On Thu, Aug 6, 2020 at 6:28 PM Saikat
>>> Maitra
>>>> <
>>>>>>>>>>> > saikat.maitra@gmail.com
>>>>>>>>>>> > > <ma...@gmail.com>>
>>>>>>>>>>> > > > > wrote:
>>>>>>>>>>> > > > >
>>>>>>>>>>> > > > >> Hi Denis, Val
>>>>>>>>>>> > > > >>
>>>>>>>>>>> > > > >> Thank you for your reply and really
>>>> appreciate
>>>>>> it.
>>>>>>>> It
>>>>>>>>>>> will be
>>>>>>>>>>> > very
>>>>>>>>>>> > > cool to
>>>>>>>>>>> > > > >> be able to connect and plan release
>>> together
>>>>> and
>>>>>>>> learn
>>>>>>>>>>> more
>>>>>>>>>>> > about
>>>>>>>>>>> > > Ignite in
>>>>>>>>>>> > > > >> the process :)
>>>>>>>>>>> > > > >>
>>>>>>>>>>> > > > >> Regards
>>>>>>>>>>> > > > >> Saikat
>>>>>>>>>>> > > > >>
>>>>>>>>>>> > > > >>
>>>>>>>>>>> > > > >>
>>>>>>>>>>> > > > >> On Thu, Aug 6, 2020 at 7:12 PM Valentin
>>>>>>> Kulichenko <
>>>>>>>>>>> > > > >> valentin.kulichenko@gmail.com <mailto:
>>>>>>>>>>> > valentin.kulichenko@gmail.com>>
>>>>>>>>>>> > > wrote:
>>>>>>>>>>> > > > >>
>>>>>>>>>>> > > > >>> Hi Saikat,
>>>>>>>>>>> > > > >>>
>>>>>>>>>>> > > > >>> That surely is a great idea. We will
>> work
>>>>>>> together
>>>>>>>>> with
>>>>>>>>>>> Denis
>>>>>>>>>>> > on
>>>>>>>>>>> > > setting
>>>>>>>>>>> > > > >>> this up in the nearest future.
>>>>>>>>>>> > > > >>>
>>>>>>>>>>> > > > >>> -Val
>>>>>>>>>>> > > > >>>
>>>>>>>>>>> > > > >>> On Thu, Aug 6, 2020 at 10:21 AM Denis
>>>> Magda <
>>>>>>>>>>> dmagda@apache.org
>>>>>>>>>>> > > <ma...@apache.org>> wrote:
>>>>>>>>>>> > > > >>>
>>>>>>>>>>> > > > >>>> Saikat,
>>>>>>>>>>> > > > >>>>
>>>>>>>>>>> > > > >>>> Fully support your idea on a virtual
>>>> meetup!
>>>>>>> Once
>>>>>>>>> Val
>>>>>>>>>>> > collects and
>>>>>>>>>>> > > > >>> outlines
>>>>>>>>>>> > > > >>>> the main changes with directions on
>>> wiki,
>>>>>> we’ll
>>>>>>> go
>>>>>>>>>>> ahead and
>>>>>>>>>>> > > schedule
>>>>>>>>>>> > > > >> the
>>>>>>>>>>> > > > >>>> meetup to talk things out in a bit
>> more
>>>>>> detail.
>>>>>>>>> We’ll
>>>>>>>>>>> use our
>>>>>>>>>>> > new
>>>>>>>>>>> > > > >> Virtual
>>>>>>>>>>> > > > >>>> Ignite Meetup group for that inviting
>>> both
>>>>>>> Ignite
>>>>>>>>>>> > contributors and
>>>>>>>>>>> > > > >>>> application developers.
>>>>>>>>>>> > > > >>>>
>>>>>>>>>>> > > > >>>> Denis
>>>>>>>>>>> > > > >>>>
>>>>>>>>>>> > > > >>>> On Thursday, August 6, 2020, Saikat
>>>> Maitra <
>>>>>>>>>>> > saikat.maitra@gmail.com
>>>>>>>>>>> > > <ma...@gmail.com>>
>>>>>>>>>>> > > > >>>> wrote:
>>>>>>>>>>> > > > >>>>
>>>>>>>>>>> > > > >>>>> Hi Valentin
>>>>>>>>>>> > > > >>>>>
>>>>>>>>>>> > > > >>>>> Thank you for sharing and starting
>> the
>>>>>> thread.
>>>>>>> I
>>>>>>>> am
>>>>>>>>>>> thinking
>>>>>>>>>>> > if it
>>>>>>>>>>> > > > >> will
>>>>>>>>>>> > > > >>>> be
>>>>>>>>>>> > > > >>>>> a good idea to have a virtual meet
>>> setup
>>>> to
>>>>>>>> discuss
>>>>>>>>>> on
>>>>>>>>>>> the
>>>>>>>>>>> > release
>>>>>>>>>>> > > > >>>>> planning.
>>>>>>>>>>> > > > >>>>>
>>>>>>>>>>> > > > >>>>> It will help to learn more individual
>>>>>> features
>>>>>>> to
>>>>>>>>> be
>>>>>>>>>>> added
>>>>>>>>>>> > and also
>>>>>>>>>>> > > > >> to
>>>>>>>>>>> > > > >>>>> understand about features that have
>>> been
>>>>>>>> deprecated
>>>>>>>>>> and
>>>>>>>>>>> > scheduled
>>>>>>>>>>> > > for
>>>>>>>>>>> > > > >>>>> removal in Ignite 3.0 release. Also
>> it
>>>> will
>>>>>>> help
>>>>>>>>>>> community
>>>>>>>>>>> > member
>>>>>>>>>>> > > to
>>>>>>>>>>> > > > >>>>> connect in real time and ask
>> questions
>>>> and
>>>>>>> share
>>>>>>>>>>> feedback.
>>>>>>>>>>> > > > >>>>>
>>>>>>>>>>> > > > >>>>> Regards,
>>>>>>>>>>> > > > >>>>> Saikat
>>>>>>>>>>> > > > >>>>>
>>>>>>>>>>> > > > >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya
>>>>>> Kasnacheev
>>>>>>> <
>>>>>>>>>>> > > > >>>> ilya.kasnacheev@gmail.com <mailto:
>>>>>>>>>>> ilya.kasnacheev@gmail.com>>
>>>>>>>>>>> > > > >>>>> wrote:
>>>>>>>>>>> > > > >>>>>
>>>>>>>>>>> > > > >>>>>> Hello!
>>>>>>>>>>> > > > >>>>>>
>>>>>>>>>>> > > > >>>>>> I hope to see Apache Ignite release
>>> 3.0
>>>> as
>>>>>> API
>>>>>>>>>>> trimming
>>>>>>>>>>> > release.
>>>>>>>>>>> > > > >> Let
>>>>>>>>>>> > > > >>> us
>>>>>>>>>>> > > > >>>>>> correct external and internal APIs
>> for
>>>>> which
>>>>>>> we
>>>>>>>>> have
>>>>>>>>>>> better
>>>>>>>>>>> > ideas
>>>>>>>>>>> > > > >>> now,
>>>>>>>>>>> > > > >>>> as
>>>>>>>>>>> > > > >>>>>> well as remove old and deprecated
>>> code.
>>>>>>>>>>> > > > >>>>>>
>>>>>>>>>>> > > > >>>>>> We may also introduce new
>>> configuration
>>>>>>>> mechanisms
>>>>>>>>>> and
>>>>>>>>>>> > user-facing
>>>>>>>>>>> > > > >>> API
>>>>>>>>>>> > > > >>>>>> (such as cache-less native SQL
>>> queries),
>>>>> but
>>>>>>>> this
>>>>>>>>> we
>>>>>>>>>>> could
>>>>>>>>>>> > > > >> prototype
>>>>>>>>>>> > > > >>>>> before
>>>>>>>>>>> > > > >>>>>> starting the 3.0 task.
>>>>>>>>>>> > > > >>>>>>
>>>>>>>>>>> > > > >>>>>> I will advise against targeting
>> large
>>>> new
>>>>>>>> features
>>>>>>>>>> at
>>>>>>>>>>> 3.0.
>>>>>>>>>>> > They
>>>>>>>>>>> > > can
>>>>>>>>>>> > > > >>> be
>>>>>>>>>>> > > > >>>>>> added in subsequent point releases,
>>>>> whereas
>>>>>> we
>>>>>>>>> can't
>>>>>>>>>>> really
>>>>>>>>>>> > remove
>>>>>>>>>>> > > > >> or
>>>>>>>>>>> > > > >>>>>> remodel stuff in point releases.
>>>>>>>>>>> > > > >>>>>>
>>>>>>>>>>> > > > >>>>>> Regards,
>>>>>>>>>>> > > > >>>>>> --
>>>>>>>>>>> > > > >>>>>> Ilya Kasnacheev
>>>>>>>>>>> > > > >>>>>>
>>>>>>>>>>> > > > >>>>>>
>>>>>>>>>>> > > > >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin
>>>>>>> Kulichenko
>>>>>>>> <
>>>>>>>>>>> > > > >>>>>> valentin.kulichenko@gmail.com
>>> <mailto:
>>>>>>>>>>> > > valentin.kulichenko@gmail.com>>:
>>>>>>>>>>> > > > >>>>>>
>>>>>>>>>>> > > > >>>>>>> Igniters,
>>>>>>>>>>> > > > >>>>>>>
>>>>>>>>>>> > > > >>>>>>> I would like to kick off a
>> discussion
>>>>>>> regarding
>>>>>>>>>>> Ignite 3.0.
>>>>>>>>>>> > > > >> Ignite
>>>>>>>>>>> > > > >>>> 2.0
>>>>>>>>>>> > > > >>>>>>> exists for more than 3 years now
>> and
>>>>> we've
>>>>>>>>> already
>>>>>>>>>>> > collected a
>>>>>>>>>>> > > > >>>>>> significant
>>>>>>>>>>> > > > >>>>>>> list [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://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
>>>>>>>>>>> > <
>>>>>>>>>>> > >
>>>>>>>>>>> >
>>>>>>>>>>>
>> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
>>>>>>>>>>> > >
>>>>>>>>>>> > > > >>>>> Apache+Ignite+3.0+Wishlist
>>>>>>>>>>> > > > >>>>>>>
>>>>>>>>>>> > > > >>>>>>> Regards,
>>>>>>>>>>> > > > >>>>>>> Val
>>>>>>>>>>> > > > >>>>>>>
>>>>>>>>>>> > > > >>>>>>
>>>>>>>>>>> > > > >>>>>
>>>>>>>>>>> > > > >>>>
>>>>>>>>>>> > > > >>>>
>>>>>>>>>>> > > > >>>> --
>>>>>>>>>>> > > > >>>> -
>>>>>>>>>>> > > > >>>> Denis
>>>>>>>>>>> > > > >>>>
>>>>>>>>>>> > > > >>>
>>>>>>>>>>> > > > >>
>>>>>>>>>>> > > >
>>>>>>>>>>> > >
>>>>>>>>>>> > >
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>
>>>> --
>>>> <http://www.trimble.com/>
>>>> Raymond Wilson
>>>> Solution Architect, Civil Construction Software Systems (CCSS)
>>>> 11 Birmingham Drive | Christchurch, New Zealand
>>>> +64-21-2013317 Mobile
>>>> raymond_wilson@trimble.com
>>>>
>>>> <
>>>>
>> https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch
>>
>> --
>> <http://www.trimble.com/>
>> Raymond Wilson
>> Solution Architect, Civil Construction Software Systems (CCSS)
>> 11 Birmingham Drive | Christchurch, New Zealand
>> +64-21-2013317 Mobile
>> raymond_wilson@trimble.com
>>
>> <
>> https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch
Re: Apache Ignite 3.0
Posted by Valentin Kulichenko <va...@gmail.com>.
Hi Pavel,
Is see the ".NET Modernization for Ignite 3.0" item in the roadmap, but it
doesn't provide much detail. What are the actual changes in .NET that you
propose for 3.0?
As for the messaging, so far I haven't seen use cases that would require
this API. Sometimes users attempt to use it for remote code invocation, but
compute is usually a better option for this. Do you have any examples where
messaging is a better fit then compute?
-Val
On Sun, Aug 16, 2020 at 9:04 AM Pavel Tupitsyn <pt...@apache.org> wrote:
> Saikat, yes, most definitely.
> This is mentioned in the wishlist under ".NET: Target .NET Standard 2.0,
> discontinue .NET 4.0 support".
> I'm already working towards this goal by making more code and tests work
> properly under .NET Core,
> so when the time for breaking changes comes, it will be simpler.
>
> On Sat, Aug 15, 2020 at 10:06 PM Saikat Maitra <sa...@gmail.com>
> 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
> > release?
> >
> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap
> >
> > Regards,
> > Saikat
> >
> >
> >
> > On Fri, Aug 14, 2020 at 10:04 AM Carbone, Adam <
> > Adam.Carbone@bottomline.com>
> > wrote:
> >
> > > If you want to make is simpler to have the components that you want,
> but
> > > have that be immutable at install time you could take an approach
> similar
> > > to the way spring does it with their initializer (
> > > https://start.spring.io/ ) as an example... Basically the concept
> being
> > > something that produces a set of configurations that are used to define
> > > what the environment looks like ( these could be k8s objects ) they
> could
> > > be spring-configuration objects? They could be something that you
> develop
> > > all upon ignite ( probably wouldn’t recommend this approach ) there
> > seems
> > > to be plenty of these types of things already
> > >
> > > Example
> > > * https://spring.io/guides/gs/centralized-configuration
> > > *
> > >
> >
> https://cocoon.apache.org/subprojects/configuration/spring-configurator/index.html
> > >
> > > And I'm by no means saying to use spring these are just examples that I
> > > came across
> > >
> > > I'm thinking the outcome needs to be a platform config of source ( that
> > > can be checked in for those doing gitops ) and maybe ends up as a
> config
> > > map for those doing k8s, and some other fashion for those doing
> something
> > > else.
> > >
> > > Honestly I am not deep enough into the internals of ignite to know how
> > > this might work for the platform, was more describing what I'm seeing
> > from
> > > a bigger picture trend
> > >
> > > Regards
> > >
> > > Adam Carbone | Director of Innovation – Intelligent Platform Team |
> > > Bottomline Technologies
> > > Office: 603-501-6446 | Mobile: 603-570-8418
> > > www.bottomline.com
> > >
> > >
> > >
> > > On 8/13/20, 7:55 PM, "Valentin Kulichenko" <
> > valentin.kulichenko@gmail.com>
> > > wrote:
> > >
> > > Hi Ilya,
> > >
> > > Can you please describe your vision of how it should work?
> > >
> > > Let's say, I want to set up a cluster of several standalone server
> > > nodes
> > > with a couple of optional modules enabled. What are my steps?
> > >
> > > -Val
> > >
> > > On Thu, Aug 13, 2020 at 6:03 AM Carbone, Adam <
> > > Adam.Carbone@bottomline.com>
> > > wrote:
> > >
> > > > Good Morning from the EastCoast
> > > >
> > > > I have to agree that the larger industry is tending towards
> > > immutability,
> > > > and that you build once and test, then you promote/migrate that
> > > immutable
> > > > binary object, be is a library or a docker image etc... however
> > > there are
> > > > still patterns that allow you to determine at install/or
> deployment
> > > time (
> > > > helm as an example, you choose based on your values what the
> > package
> > > > installs/provides ) It just isn't decided at runtime but install
> > and
> > > often
> > > > in a gitops type world that is determined by configuration as
> code.
> > > I think
> > > > run time is difficult to manage especially in our increasingly
> > > > containerized world.
> > > >
> > > > Regards.
> > > >
> > > > Adam Carbone | Director of Innovation – Intelligent Platform
> Team |
> > > > Bottomline Technologies
> > > > Office: 603-501-6446 | Mobile: 603-570-8418
> > > > www.bottomline.com
> > > >
> > > >
> > > >
> > > > On 8/13/20, 8:01 AM, "Ilya Kasnacheev" <
> ilya.kasnacheev@gmail.com>
> > > wrote:
> > > >
> > > > Hello!
> > > >
> > > > On the contrary, I would suggest that apache2 way was
> outdated
> > > even at
> > > > times when apache was all rage.
> > > >
> > > > Now the nginx approach is prevalent: on devops phase,
> assemble
> > a
> > > custom
> > > > bundle with all plugins included, store it somewhere, and
> ship
> > > it to
> > > > production as a whole to remove any on-the-fly uncertainty
> from
> > > > production.
> > > >
> > > > This is what docker does, but also maven, which downloads
> > > dependencies
> > > > during build. You do not need to download anything in
> runtime,
> > > except
> > > > for
> > > > experimental deployments. You need to be all set before
> runtime
> > > starts.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > ср, 12 авг. 2020 г. в 09:48, Petr Ivanov <
> mr.weider@gmail.com
> > >:
> > > >
> > > > > Hi, Val.
> > > > >
> > > > > > On 12 Aug 2020, at 01:31, Valentin Kulichenko <
> > > > > valentin.kulichenko@gmail.com> wrote:
> > > > > >
> > > > > > Hi Petr,
> > > > > >
> > > > > > I agree -- we should better modularize the platform. The
> > > current
> > > > way if
> > > > > very error-prone, especially during upgrades -- any changes
> > > made
> > > > within
> > > > > IGNITE_HOME (configs, scripts, modules, etc.) must be
> merged
> > > with a
> > > > new
> > > > > version of the package. There is no standard way of doing
> > this.
> > > > > >
> > > > > > However, I'm a bit concerned with your suggestion
> regarding
> > > custom
> > > > > dependency management. Can you please elaborate on how you
> > > think it
> > > > should
> > > > > work? Are there tools we can reuse for this purpose? I
> would
> > > try to
> > > > avoid
> > > > > reinventing the wheel.
> > > > >
> > > > > I see it as a a2enmod | 2dismod analog of Apache2.
> > > > >
> > > > > We build and store Apache Ignite and its modules as
> separate
> > > binaries
> > > > > (binary per module) then use custom script that will know
> > > where to
> > > > download
> > > > > necessary module. Or possibly use modified ignite.sh to
> > specify
> > > > required
> > > > > 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.
> > > > >
> > > > >
> > > > > >
> > > > > > -Val
> > > > > >
> > > > > > On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov <
> > > mr.weider@gmail.com
> > > > > <ma...@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
> > > > starting
> > > > > Ignite and all other modules and parts of the project
> > > (benchmarks,
> > > > > examples, etc.) packed in their own binary which can be
> added
> > > via
> > > > custom
> > > > > dependency management tool (i.e. modules.sh)
> > > > > > — same distribution for RPM and DEB packages but with
> > > modules
> > > > packed as
> > > > > separate ones (PHP for example)
> > > > > > — separate thin client release cycle with custom
> > versioning
> > > > > > Possibly, we can we add additional section to the
> document
> > > you
> > > > > introduced for this part.
> > > > > >
> > > > > > Also, it seems that full JDK11 support (including
> building)
> > > would
> > > > be a
> > > > > huge milestone and a sign of healthy modern project that
> > tends
> > > to be
> > > > on the
> > > > > verge of mainstream technologies and not the stockpile of
> > > legacy
> > > > leftovers
> > > > > (fully support Iliya in removing all that was deprecated
> > and/or
> > > > marked as
> > > > > unused anymore).
> > > > > >
> > > > > >
> > > > > > > On 8 Aug 2020, at 02:00, Valentin Kulichenko <
> > > > > valentin.kulichenko@gmail.com <mailto:
> > > valentin.kulichenko@gmail.com
> > > > >>
> > > > > wrote:
> > > > > > >
> > > > > > > Igniters,
> > > > > > >
> > > > > > > I've created the page:
> > > > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> > > > <
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> > > > >
> > > > > > >
> > > > > > > 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 the consensus on the proposed
> > > changes,
> > > > I will
> > > > > > > start creating tickets in Jira and a more detailed
> plan.
> > > > > > >
> > > > > > > -Val
> > > > > > >
> > > > > > > On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <
> > > > saikat.maitra@gmail.com
> > > > > <ma...@gmail.com>>
> > > > > > > wrote:
> > > > > > >
> > > > > > >> Hi Denis, Val
> > > > > > >>
> > > > > > >> Thank you for your reply and really appreciate it. It
> > > will be
> > > > very
> > > > > cool to
> > > > > > >> be able to connect and plan release together and learn
> > > more
> > > > about
> > > > > Ignite in
> > > > > > >> the process :)
> > > > > > >>
> > > > > > >> Regards
> > > > > > >> Saikat
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko <
> > > > > > >> valentin.kulichenko@gmail.com <mailto:
> > > > valentin.kulichenko@gmail.com>>
> > > > > wrote:
> > > > > > >>
> > > > > > >>> Hi Saikat,
> > > > > > >>>
> > > > > > >>> That surely is a great idea. We will work together
> with
> > > Denis
> > > > on
> > > > > setting
> > > > > > >>> this up in the nearest future.
> > > > > > >>>
> > > > > > >>> -Val
> > > > > > >>>
> > > > > > >>> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <
> > > dmagda@apache.org
> > > > > <ma...@apache.org>> wrote:
> > > > > > >>>
> > > > > > >>>> Saikat,
> > > > > > >>>>
> > > > > > >>>> Fully support your idea on a virtual meetup! Once
> Val
> > > > collects and
> > > > > > >>> outlines
> > > > > > >>>> the main changes with directions on wiki, we’ll go
> > > ahead and
> > > > > schedule
> > > > > > >> the
> > > > > > >>>> meetup to talk things out in a bit more detail.
> We’ll
> > > use our
> > > > new
> > > > > > >> Virtual
> > > > > > >>>> Ignite Meetup group for that inviting both Ignite
> > > > contributors and
> > > > > > >>>> application developers.
> > > > > > >>>>
> > > > > > >>>> Denis
> > > > > > >>>>
> > > > > > >>>> On Thursday, August 6, 2020, Saikat Maitra <
> > > > saikat.maitra@gmail.com
> > > > > <ma...@gmail.com>>
> > > > > > >>>> wrote:
> > > > > > >>>>
> > > > > > >>>>> Hi Valentin
> > > > > > >>>>>
> > > > > > >>>>> Thank you for sharing and starting the thread. I am
> > > thinking
> > > > if it
> > > > > > >> will
> > > > > > >>>> be
> > > > > > >>>>> a good idea to have a virtual meet setup to discuss
> > on
> > > the
> > > > release
> > > > > > >>>>> planning.
> > > > > > >>>>>
> > > > > > >>>>> It will help to learn more individual features to
> be
> > > added
> > > > and also
> > > > > > >> to
> > > > > > >>>>> understand about features that have been deprecated
> > and
> > > > scheduled
> > > > > for
> > > > > > >>>>> removal in Ignite 3.0 release. Also it will help
> > > community
> > > > member
> > > > > to
> > > > > > >>>>> connect in real time and ask questions and share
> > > feedback.
> > > > > > >>>>>
> > > > > > >>>>> Regards,
> > > > > > >>>>> Saikat
> > > > > > >>>>>
> > > > > > >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <
> > > > > > >>>> ilya.kasnacheev@gmail.com <mailto:
> > > ilya.kasnacheev@gmail.com>>
> > > > > > >>>>> wrote:
> > > > > > >>>>>
> > > > > > >>>>>> Hello!
> > > > > > >>>>>>
> > > > > > >>>>>> I hope to see Apache Ignite release 3.0 as API
> > > trimming
> > > > release.
> > > > > > >> Let
> > > > > > >>> us
> > > > > > >>>>>> correct external and internal APIs for which we
> have
> > > better
> > > > ideas
> > > > > > >>> now,
> > > > > > >>>> as
> > > > > > >>>>>> well as remove old and deprecated code.
> > > > > > >>>>>>
> > > > > > >>>>>> We may also introduce new configuration mechanisms
> > and
> > > > user-facing
> > > > > > >>> API
> > > > > > >>>>>> (such as cache-less native SQL queries), but this
> we
> > > could
> > > > > > >> prototype
> > > > > > >>>>> before
> > > > > > >>>>>> starting the 3.0 task.
> > > > > > >>>>>>
> > > > > > >>>>>> I will advise against targeting large new features
> > at
> > > 3.0.
> > > > They
> > > > > can
> > > > > > >>> be
> > > > > > >>>>>> added in subsequent point releases, whereas we
> can't
> > > really
> > > > remove
> > > > > > >> or
> > > > > > >>>>>> remodel stuff in point releases.
> > > > > > >>>>>>
> > > > > > >>>>>> Regards,
> > > > > > >>>>>> --
> > > > > > >>>>>> Ilya Kasnacheev
> > > > > > >>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
> > > > > > >>>>>> valentin.kulichenko@gmail.com <mailto:
> > > > > valentin.kulichenko@gmail.com>>:
> > > > > > >>>>>>
> > > > > > >>>>>>> Igniters,
> > > > > > >>>>>>>
> > > > > > >>>>>>> I would like to kick off a discussion regarding
> > > Ignite 3.0.
> > > > > > >> Ignite
> > > > > > >>>> 2.0
> > > > > > >>>>>>> exists for more than 3 years now and we've
> already
> > > > collected a
> > > > > > >>>>>> significant
> > > > > > >>>>>>> list [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://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> > > > <
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> > > > >
> > > > > > >>>>> Apache+Ignite+3.0+Wishlist
> > > > > > >>>>>>>
> > > > > > >>>>>>> Regards,
> > > > > > >>>>>>> Val
> > > > > > >>>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>> --
> > > > > > >>>> -
> > > > > > >>>> Denis
> > > > > > >>>>
> > > > > > >>>
> > > > > > >>
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
>
Re: Apache Ignite 3.0
Posted by Raymond Wilson <ra...@trimble.com>.
Val,
We use it in a mixture of server-server and server-client use cases.
The common use case is variations of cache invalidation, particularly with
respect to cached derivatives computed from information contained in the
Ignite persistent store. I am aware of the Ignite cache events to detect
changes to elements, but we decided against this as some (single) cache
invalidation contexts are only triggered after potentially thousands of
elements in persistent caches have been modified, so this cuts down high
frequency event chatter across the grid. It's also nice to separate the
Ignite persistent store domain from the business logic domain.
We did have a use case where messaging was used to shuttle partial results
between nodes in an a, synchronous pattern however this caused deadlocking
issues due to thread pool exhaustion so this has been switched to a compute
Invoke pattern.
Raymond.
On Thu, Sep 17, 2020 at 5:21 PM Valentin Kulichenko <
valentin.kulichenko@gmail.com> wrote:
> Raymond,
>
> Can you please describe the way you use messaging in a little bit more
> detail? Is it for communication between server nodes or more of a
> client-server? what are the typical patterns?
>
> -Val
>
> On Wed, Sep 16, 2020 at 4:05 PM Raymond Wilson <raymond_wilson@trimble.com
> >
> wrote:
>
> > Hi Val,
> >
> > Possibly, but the core difficulty there is knowing when the fan-out to
> > listeners has been completed. Before you know it you have
> > re-implemented Kafka! :)
> >
> > I think we can leverage our use case knowledge to convert the messaging
> > style of notifications to a compute style broadcast against a compute
> > projection using an attribute based selection for nodes that want to be
> > listeners for the events. The messaging rate is relatively low (a few
> > messages a second) so this should be pretty workable.
> >
> > Raymond.
> >
> > On Thu, Sep 17, 2020 at 3:27 AM Valentin Kulichenko <
> > valentin.kulichenko@gmail.com> wrote:
> >
> > > Hi Raymond,
> > >
> > > Do you think you could use services for your use case?
> > > https://apacheignite.readme.io/docs/service-grid
> > >
> > > -Val
> > >
> > > On Tue, Sep 15, 2020 at 4:32 PM Raymond Wilson <
> > raymond_wilson@trimble.com
> > > >
> > > wrote:
> > >
> > > > For what it is worth, we use messaging in Ignite to provide grid
> > > > notifications for various purposes. These might stimulate compute
> > > > operations in the message recipients, but they don't represent
> compute.
> > > >
> > > > If messaging is removed, how would Ignite provide the ability for a
> > node
> > > to
> > > > listen to events without the event sender being explicitly aware that
> > the
> > > > listener does, or should, exist, to produce a compute projection to
> > send
> > > > messages-as-compute-requests to?
> > > >
> > > > On Wed, Sep 16, 2020 at 9:28 AM Kseniya Romanova <
> > > > romanova.ks.spb@gmail.com>
> > > > wrote:
> > > >
> > > > > Just wanted to submit a link to the video about some offered
> changes.
> > > > > @valentin.kulichenko@gmail.com <va...@gmail.com>
> > please
> > > > add
> > > > > it to the wiki page. I created timestamps in the description, so
> one
> > > can
> > > > > browse the presentation fast or link the particular section:
> > > > > https://youtu.be/zPuLJgUfLaM
> > > > > Thanks a lot for the presentation!
> > > > >
> > > > > вт, 18 авг. 2020 г. в 14:13, Ilya Kasnacheev <
> > > ilya.kasnacheev@gmail.com
> > > > >:
> > > > >
> > > > > > Hello!
> > > > > >
> > > > > > Maybe we can implement messaging via compute? Share underlying
> code
> > > but
> > > > > > have a different API for convenience (maybe in extras).
> > > > > >
> > > > > > Regards,
> > > > > > --
> > > > > > Ilya Kasnacheev
> > > > > >
> > > > > >
> > > > > > вт, 18 авг. 2020 г. в 11:59, Pavel Tupitsyn <
> ptupitsyn@apache.org
> > >:
> > > > > >
> > > > > > > Val,
> > > > > > >
> > > > > > > > Is see the ".NET Modernization for Ignite 3.0" item in the
> > > roadmap,
> > > > > but
> > > > > > > it
> > > > > > > > doesn't provide much detail. What are the actual changes in
> > .NET
> > > > that
> > > > > > you
> > > > > > > > propose for 3.0?
> > > > > > >
> > > > > > > I've updated the roadmap with a brief description.
> > > > > > > We want to move away from an old, long unsupported .NET
> version,
> > > > > > > and remove integrations with legacy technologies (old ASP.NET
> > and
> > > > EF).
> > > > > > >
> > > > > > > > As for the messaging, so far I haven't seen use cases that
> > would
> > > > > > require
> > > > > > > > this API. Sometimes users attempt to use it for remote code
> > > > > invocation,
> > > > > > > but
> > > > > > > > compute is usually 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.
> > > > > > >
> > > > > > > Messaging can be more convenient, since it is pub-sub -
> > 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Aug 18, 2020 at 3:16 AM Saikat Maitra <
> > > > saikat.maitra@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 Tupitsyn <
> > > > > ptupitsyn@apache.org>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Saikat, yes, most definitely.
> > > > > > > > > This is mentioned in the wishlist under ".NET: Target .NET
> > > > Standard
> > > > > > > 2.0,
> > > > > > > > > discontinue .NET 4.0 support".
> > > > > > > > > I'm already working towards this goal by making more code
> and
> > > > tests
> > > > > > > work
> > > > > > > > > properly under .NET Core,
> > > > > > > > > so when the time for breaking changes comes, it will be
> > > simpler.
> > > > > > > > >
> > > > > > > > > On Sat, Aug 15, 2020 at 10:06 PM Saikat Maitra <
> > > > > > > saikat.maitra@gmail.com>
> > > > > > > > > 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
> > > > > > > > > > release?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > > Saikat
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Fri, Aug 14, 2020 at 10:04 AM Carbone, Adam <
> > > > > > > > > > Adam.Carbone@bottomline.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > If you want to make is simpler to have the components
> > that
> > > > you
> > > > > > > want,
> > > > > > > > > but
> > > > > > > > > > > have that be immutable at install time you could take
> an
> > > > > approach
> > > > > > > > > similar
> > > > > > > > > > > to the way spring does it with their initializer (
> > > > > > > > > > > https://start.spring.io/ ) as an example... Basically
> > the
> > > > > > concept
> > > > > > > > > being
> > > > > > > > > > > something that produces a set of configurations that
> are
> > > used
> > > > > to
> > > > > > > > define
> > > > > > > > > > > what the environment looks like ( these could be k8s
> > > objects
> > > > )
> > > > > > they
> > > > > > > > > could
> > > > > > > > > > > be spring-configuration objects? They could be
> something
> > > that
> > > > > you
> > > > > > > > > develop
> > > > > > > > > > > all upon ignite ( probably wouldn’t recommend this
> > > approach )
> > > > > > > there
> > > > > > > > > > seems
> > > > > > > > > > > to be plenty of these types of things already
> > > > > > > > > > >
> > > > > > > > > > > Example
> > > > > > > > > > > *
> https://spring.io/guides/gs/centralized-configuration
> > > > > > > > > > > *
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cocoon.apache.org/subprojects/configuration/spring-configurator/index.html
> > > > > > > > > > >
> > > > > > > > > > > And I'm by no means saying to use spring these are just
> > > > > examples
> > > > > > > > that I
> > > > > > > > > > > came across
> > > > > > > > > > >
> > > > > > > > > > > I'm thinking the outcome needs to be a platform config
> of
> > > > > source
> > > > > > (
> > > > > > > > that
> > > > > > > > > > > can be checked in for those doing gitops ) and maybe
> ends
> > > up
> > > > > as a
> > > > > > > > > config
> > > > > > > > > > > map for those doing k8s, and some other fashion for
> those
> > > > doing
> > > > > > > > > something
> > > > > > > > > > > else.
> > > > > > > > > > >
> > > > > > > > > > > Honestly I am not deep enough into the internals of
> > ignite
> > > to
> > > > > > know
> > > > > > > > how
> > > > > > > > > > > this might work for the platform, was more describing
> > what
> > > > I'm
> > > > > > > seeing
> > > > > > > > > > from
> > > > > > > > > > > a bigger picture trend
> > > > > > > > > > >
> > > > > > > > > > > Regards
> > > > > > > > > > >
> > > > > > > > > > > Adam Carbone | Director of Innovation – Intelligent
> > > Platform
> > > > > > Team |
> > > > > > > > > > > Bottomline Technologies
> > > > > > > > > > > Office: 603-501-6446 | Mobile: 603-570-8418
> > > > > > > > > > > www.bottomline.com
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On 8/13/20, 7:55 PM, "Valentin Kulichenko" <
> > > > > > > > > > valentin.kulichenko@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Ilya,
> > > > > > > > > > >
> > > > > > > > > > > Can you please describe your vision of how it
> should
> > > > work?
> > > > > > > > > > >
> > > > > > > > > > > Let's say, I want to set up a cluster of several
> > > > standalone
> > > > > > > > server
> > > > > > > > > > > nodes
> > > > > > > > > > > with a couple of optional modules enabled. What are
> > my
> > > > > steps?
> > > > > > > > > > >
> > > > > > > > > > > -Val
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Aug 13, 2020 at 6:03 AM Carbone, Adam <
> > > > > > > > > > > Adam.Carbone@bottomline.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Good Morning from the EastCoast
> > > > > > > > > > > >
> > > > > > > > > > > > I have to agree that the larger industry is
> tending
> > > > > towards
> > > > > > > > > > > immutability,
> > > > > > > > > > > > and that you build once and test, then you
> > > > > promote/migrate
> > > > > > > that
> > > > > > > > > > > immutable
> > > > > > > > > > > > binary object, be is a library or a docker image
> > > etc...
> > > > > > > however
> > > > > > > > > > > there are
> > > > > > > > > > > > still patterns that allow you to determine at
> > > > install/or
> > > > > > > > > deployment
> > > > > > > > > > > time (
> > > > > > > > > > > > helm as an example, you choose based on your
> values
> > > > what
> > > > > > the
> > > > > > > > > > package
> > > > > > > > > > > > installs/provides ) It just isn't decided at
> > runtime
> > > > but
> > > > > > > > install
> > > > > > > > > > and
> > > > > > > > > > > often
> > > > > > > > > > > > in a gitops type world that is determined by
> > > > > configuration
> > > > > > as
> > > > > > > > > code.
> > > > > > > > > > > I think
> > > > > > > > > > > > run time is difficult to manage especially in our
> > > > > > > increasingly
> > > > > > > > > > > > containerized world.
> > > > > > > > > > > >
> > > > > > > > > > > > Regards.
> > > > > > > > > > > >
> > > > > > > > > > > > Adam Carbone | Director of Innovation –
> Intelligent
> > > > > > Platform
> > > > > > > > > Team |
> > > > > > > > > > > > Bottomline Technologies
> > > > > > > > > > > > Office: 603-501-6446 | Mobile: 603-570-8418
> > > > > > > > > > > > www.bottomline.com
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On 8/13/20, 8:01 AM, "Ilya Kasnacheev" <
> > > > > > > > > ilya.kasnacheev@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hello!
> > > > > > > > > > > >
> > > > > > > > > > > > On the contrary, I would suggest that apache2
> > way
> > > > was
> > > > > > > > > outdated
> > > > > > > > > > > even at
> > > > > > > > > > > > times when apache was all rage.
> > > > > > > > > > > >
> > > > > > > > > > > > Now the nginx approach is prevalent: on
> devops
> > > > phase,
> > > > > > > > > assemble
> > > > > > > > > > a
> > > > > > > > > > > custom
> > > > > > > > > > > > bundle with all plugins included, store it
> > > > somewhere,
> > > > > > and
> > > > > > > > > ship
> > > > > > > > > > > it to
> > > > > > > > > > > > production as a whole to remove any
> on-the-fly
> > > > > > > uncertainty
> > > > > > > > > from
> > > > > > > > > > > > production.
> > > > > > > > > > > >
> > > > > > > > > > > > This is what docker does, but also maven,
> which
> > > > > > downloads
> > > > > > > > > > > dependencies
> > > > > > > > > > > > during build. You do not need to download
> > > anything
> > > > in
> > > > > > > > > runtime,
> > > > > > > > > > > except
> > > > > > > > > > > > for
> > > > > > > > > > > > experimental deployments. You need to be all
> > set
> > > > > before
> > > > > > > > > runtime
> > > > > > > > > > > starts.
> > > > > > > > > > > >
> > > > > > > > > > > > Regards,
> > > > > > > > > > > > --
> > > > > > > > > > > > Ilya Kasnacheev
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > ср, 12 авг. 2020 г. в 09:48, Petr Ivanov <
> > > > > > > > > mr.weider@gmail.com
> > > > > > > > > > >:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hi, Val.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > On 12 Aug 2020, at 01:31, Valentin
> > > Kulichenko <
> > > > > > > > > > > > > valentin.kulichenko@gmail.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Petr,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I agree -- we should better modularize
> the
> > > > > > platform.
> > > > > > > > The
> > > > > > > > > > > current
> > > > > > > > > > > > way if
> > > > > > > > > > > > > very error-prone, especially during
> upgrades
> > --
> > > > any
> > > > > > > > changes
> > > > > > > > > > > made
> > > > > > > > > > > > within
> > > > > > > > > > > > > IGNITE_HOME (configs, scripts, modules,
> etc.)
> > > > must
> > > > > be
> > > > > > > > > merged
> > > > > > > > > > > with a
> > > > > > > > > > > > new
> > > > > > > > > > > > > version of the package. There is no
> standard
> > > way
> > > > of
> > > > > > > doing
> > > > > > > > > > this.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > However, I'm a bit concerned with your
> > > > suggestion
> > > > > > > > > regarding
> > > > > > > > > > > custom
> > > > > > > > > > > > > dependency management. Can you please
> > elaborate
> > > > on
> > > > > > how
> > > > > > > > you
> > > > > > > > > > > think it
> > > > > > > > > > > > should
> > > > > > > > > > > > > work? Are there tools we can reuse for this
> > > > > purpose?
> > > > > > I
> > > > > > > > > would
> > > > > > > > > > > try to
> > > > > > > > > > > > avoid
> > > > > > > > > > > > > reinventing the wheel.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I see it as a a2enmod | 2dismod analog of
> > > > Apache2.
> > > > > > > > > > > > >
> > > > > > > > > > > > > We build and store Apache Ignite and its
> > > modules
> > > > as
> > > > > > > > > separate
> > > > > > > > > > > binaries
> > > > > > > > > > > > > (binary per module) then use custom script
> > that
> > > > > will
> > > > > > > know
> > > > > > > > > > > where to
> > > > > > > > > > > > download
> > > > > > > > > > > > > necessary module. Or possibly use modified
> > > > > ignite.sh
> > > > > > to
> > > > > > > > > > specify
> > > > > > > > > > > > required
> > > > > > > > > > > > > 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.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -Val
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Sun, Aug 9, 2020 at 11:25 PM Petr
> > Ivanov <
> > > > > > > > > > > mr.weider@gmail.com
> > > > > > > > > > > > > <ma...@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
> > > > > > > > > > > > starting
> > > > > > > > > > > > > Ignite and all other modules and parts of
> the
> > > > > project
> > > > > > > > > > > (benchmarks,
> > > > > > > > > > > > > examples, etc.) packed in their own binary
> > > which
> > > > > can
> > > > > > be
> > > > > > > > > added
> > > > > > > > > > > via
> > > > > > > > > > > > custom
> > > > > > > > > > > > > dependency management tool (i.e.
> modules.sh)
> > > > > > > > > > > > > > — same distribution for RPM and DEB
> > packages
> > > > but
> > > > > > > with
> > > > > > > > > > > modules
> > > > > > > > > > > > packed as
> > > > > > > > > > > > > separate ones (PHP for example)
> > > > > > > > > > > > > > — separate thin client release cycle
> with
> > > > custom
> > > > > > > > > > versioning
> > > > > > > > > > > > > > Possibly, we can we add additional
> section
> > to
> > > > the
> > > > > > > > > document
> > > > > > > > > > > you
> > > > > > > > > > > > > introduced for this part.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Also, it seems that full JDK11 support
> > > > (including
> > > > > > > > > building)
> > > > > > > > > > > would
> > > > > > > > > > > > be a
> > > > > > > > > > > > > huge milestone and a sign of healthy modern
> > > > project
> > > > > > > that
> > > > > > > > > > tends
> > > > > > > > > > > to be
> > > > > > > > > > > > on the
> > > > > > > > > > > > > verge of mainstream technologies and not
> the
> > > > > > stockpile
> > > > > > > of
> > > > > > > > > > > legacy
> > > > > > > > > > > > leftovers
> > > > > > > > > > > > > (fully support Iliya in removing all that
> was
> > > > > > > deprecated
> > > > > > > > > > and/or
> > > > > > > > > > > > marked as
> > > > > > > > > > > > > unused anymore).
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On 8 Aug 2020, at 02:00, Valentin
> > > Kulichenko
> > > > <
> > > > > > > > > > > > > valentin.kulichenko@gmail.com <mailto:
> > > > > > > > > > > valentin.kulichenko@gmail.com
> > > > > > > > > > > > >>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Igniters,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I've created the page:
> > > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> > > > > > > > > > > > <
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 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 the consensus
> on
> > > the
> > > > > > > > proposed
> > > > > > > > > > > changes,
> > > > > > > > > > > > I will
> > > > > > > > > > > > > > > start creating tickets in Jira and a
> more
> > > > > > detailed
> > > > > > > > > plan.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -Val
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Thu, Aug 6, 2020 at 6:28 PM Saikat
> > > Maitra
> > > > <
> > > > > > > > > > > > saikat.maitra@gmail.com
> > > > > > > > > > > > > <ma...@gmail.com>>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >> Hi Denis, Val
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> Thank you for your reply and really
> > > > appreciate
> > > > > > it.
> > > > > > > > It
> > > > > > > > > > > will be
> > > > > > > > > > > > very
> > > > > > > > > > > > > cool to
> > > > > > > > > > > > > > >> be able to connect and plan release
> > > together
> > > > > and
> > > > > > > > learn
> > > > > > > > > > > more
> > > > > > > > > > > > about
> > > > > > > > > > > > > Ignite in
> > > > > > > > > > > > > > >> the process :)
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> Regards
> > > > > > > > > > > > > > >> Saikat
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> On Thu, Aug 6, 2020 at 7:12 PM
> Valentin
> > > > > > > Kulichenko <
> > > > > > > > > > > > > > >> valentin.kulichenko@gmail.com
> <mailto:
> > > > > > > > > > > > valentin.kulichenko@gmail.com>>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >>> Hi Saikat,
> > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > >>> That surely is a great idea. We will
> > work
> > > > > > > together
> > > > > > > > > with
> > > > > > > > > > > Denis
> > > > > > > > > > > > on
> > > > > > > > > > > > > setting
> > > > > > > > > > > > > > >>> this up in the nearest future.
> > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > >>> -Val
> > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > >>> On Thu, Aug 6, 2020 at 10:21 AM Denis
> > > > Magda <
> > > > > > > > > > > dmagda@apache.org
> > > > > > > > > > > > > <ma...@apache.org>> wrote:
> > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > >>>> Saikat,
> > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > >>>> Fully support your idea on a virtual
> > > > meetup!
> > > > > > > Once
> > > > > > > > > Val
> > > > > > > > > > > > collects and
> > > > > > > > > > > > > > >>> outlines
> > > > > > > > > > > > > > >>>> the main changes with directions on
> > > wiki,
> > > > > > we’ll
> > > > > > > go
> > > > > > > > > > > ahead and
> > > > > > > > > > > > > schedule
> > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > >>>> meetup to talk things out in a bit
> > more
> > > > > > detail.
> > > > > > > > > We’ll
> > > > > > > > > > > use our
> > > > > > > > > > > > new
> > > > > > > > > > > > > > >> Virtual
> > > > > > > > > > > > > > >>>> Ignite Meetup group for that
> inviting
> > > both
> > > > > > > Ignite
> > > > > > > > > > > > contributors and
> > > > > > > > > > > > > > >>>> application developers.
> > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > >>>> Denis
> > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > >>>> On Thursday, August 6, 2020, Saikat
> > > > Maitra <
> > > > > > > > > > > > saikat.maitra@gmail.com
> > > > > > > > > > > > > <ma...@gmail.com>>
> > > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > >>>>> Hi Valentin
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>> Thank you for sharing and starting
> > the
> > > > > > thread.
> > > > > > > I
> > > > > > > > am
> > > > > > > > > > > thinking
> > > > > > > > > > > > if it
> > > > > > > > > > > > > > >> will
> > > > > > > > > > > > > > >>>> be
> > > > > > > > > > > > > > >>>>> a good idea to have a virtual meet
> > > setup
> > > > to
> > > > > > > > discuss
> > > > > > > > > > on
> > > > > > > > > > > the
> > > > > > > > > > > > release
> > > > > > > > > > > > > > >>>>> planning.
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>> It will help to learn more
> individual
> > > > > > features
> > > > > > > to
> > > > > > > > > be
> > > > > > > > > > > added
> > > > > > > > > > > > and also
> > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > >>>>> understand about features that have
> > > been
> > > > > > > > deprecated
> > > > > > > > > > and
> > > > > > > > > > > > scheduled
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > >>>>> removal in Ignite 3.0 release. Also
> > it
> > > > will
> > > > > > > help
> > > > > > > > > > > community
> > > > > > > > > > > > member
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > >>>>> connect in real time and ask
> > questions
> > > > and
> > > > > > > share
> > > > > > > > > > > feedback.
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>> Regards,
> > > > > > > > > > > > > > >>>>> Saikat
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya
> > > > > > Kasnacheev
> > > > > > > <
> > > > > > > > > > > > > > >>>> ilya.kasnacheev@gmail.com <mailto:
> > > > > > > > > > > ilya.kasnacheev@gmail.com>>
> > > > > > > > > > > > > > >>>>> wrote:
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>>> Hello!
> > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > >>>>>> I hope to see Apache Ignite
> release
> > > 3.0
> > > > as
> > > > > > API
> > > > > > > > > > > trimming
> > > > > > > > > > > > release.
> > > > > > > > > > > > > > >> Let
> > > > > > > > > > > > > > >>> us
> > > > > > > > > > > > > > >>>>>> correct external and internal APIs
> > for
> > > > > which
> > > > > > > we
> > > > > > > > > have
> > > > > > > > > > > better
> > > > > > > > > > > > ideas
> > > > > > > > > > > > > > >>> now,
> > > > > > > > > > > > > > >>>> as
> > > > > > > > > > > > > > >>>>>> well as remove old and deprecated
> > > code.
> > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > >>>>>> We may also introduce new
> > > configuration
> > > > > > > > mechanisms
> > > > > > > > > > and
> > > > > > > > > > > > user-facing
> > > > > > > > > > > > > > >>> API
> > > > > > > > > > > > > > >>>>>> (such as cache-less native SQL
> > > queries),
> > > > > but
> > > > > > > > this
> > > > > > > > > we
> > > > > > > > > > > could
> > > > > > > > > > > > > > >> prototype
> > > > > > > > > > > > > > >>>>> before
> > > > > > > > > > > > > > >>>>>> starting the 3.0 task.
> > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > >>>>>> I will advise against targeting
> > large
> > > > new
> > > > > > > > features
> > > > > > > > > > at
> > > > > > > > > > > 3.0.
> > > > > > > > > > > > They
> > > > > > > > > > > > > can
> > > > > > > > > > > > > > >>> be
> > > > > > > > > > > > > > >>>>>> added in subsequent point
> releases,
> > > > > whereas
> > > > > > we
> > > > > > > > > can't
> > > > > > > > > > > really
> > > > > > > > > > > > remove
> > > > > > > > > > > > > > >> or
> > > > > > > > > > > > > > >>>>>> remodel stuff in point releases.
> > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > >>>>>> Regards,
> > > > > > > > > > > > > > >>>>>> --
> > > > > > > > > > > > > > >>>>>> Ilya Kasnacheev
> > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > >>>>>> чт, 6 авг. 2020 г. в 03:54,
> Valentin
> > > > > > > Kulichenko
> > > > > > > > <
> > > > > > > > > > > > > > >>>>>> valentin.kulichenko@gmail.com
> > > <mailto:
> > > > > > > > > > > > > valentin.kulichenko@gmail.com>>:
> > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > >>>>>>> Igniters,
> > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > >>>>>>> I would like to kick off a
> > discussion
> > > > > > > regarding
> > > > > > > > > > > Ignite 3.0.
> > > > > > > > > > > > > > >> Ignite
> > > > > > > > > > > > > > >>>> 2.0
> > > > > > > > > > > > > > >>>>>>> exists for more than 3 years now
> > and
> > > > > we've
> > > > > > > > > already
> > > > > > > > > > > > collected a
> > > > > > > > > > > > > > >>>>>> significant
> > > > > > > > > > > > > > >>>>>>> list [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://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> > > > > > > > > > > > <
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> > > > > > > > > > > > >
> > > > > > > > > > > > > > >>>>> Apache+Ignite+3.0+Wishlist
> > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > >>>>>>> Regards,
> > > > > > > > > > > > > > >>>>>>> Val
> > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > >>>> --
> > > > > > > > > > > > > > >>>> -
> > > > > > > > > > > > > > >>>> Denis
> > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > <http://www.trimble.com/>
> > > > Raymond Wilson
> > > > Solution Architect, Civil Construction Software Systems (CCSS)
> > > > 11 Birmingham Drive | Christchurch, New Zealand
> > > > +64-21-2013317 Mobile
> > > > raymond_wilson@trimble.com
> > > >
> > > > <
> > > >
> > >
> >
> https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch
> > > > >
> > > >
> > >
> >
> >
> > --
> > <http://www.trimble.com/>
> > Raymond Wilson
> > Solution Architect, Civil Construction Software Systems (CCSS)
> > 11 Birmingham Drive | Christchurch, New Zealand
> > +64-21-2013317 Mobile
> > raymond_wilson@trimble.com
> >
> > <
> >
> https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch
> > >
> >
>
--
<http://www.trimble.com/>
Raymond Wilson
Solution Architect, Civil Construction Software Systems (CCSS)
11 Birmingham Drive | Christchurch, New Zealand
+64-21-2013317 Mobile
raymond_wilson@trimble.com
<https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch>
Re: Apache Ignite 3.0
Posted by Valentin Kulichenko <va...@gmail.com>.
Raymond,
Can you please describe the way you use messaging in a little bit more
detail? Is it for communication between server nodes or more of a
client-server? what are the typical patterns?
-Val
On Wed, Sep 16, 2020 at 4:05 PM Raymond Wilson <ra...@trimble.com>
wrote:
> Hi Val,
>
> Possibly, but the core difficulty there is knowing when the fan-out to
> listeners has been completed. Before you know it you have
> re-implemented Kafka! :)
>
> I think we can leverage our use case knowledge to convert the messaging
> style of notifications to a compute style broadcast against a compute
> projection using an attribute based selection for nodes that want to be
> listeners for the events. The messaging rate is relatively low (a few
> messages a second) so this should be pretty workable.
>
> Raymond.
>
> On Thu, Sep 17, 2020 at 3:27 AM Valentin Kulichenko <
> valentin.kulichenko@gmail.com> wrote:
>
> > Hi Raymond,
> >
> > Do you think you could use services for your use case?
> > https://apacheignite.readme.io/docs/service-grid
> >
> > -Val
> >
> > On Tue, Sep 15, 2020 at 4:32 PM Raymond Wilson <
> raymond_wilson@trimble.com
> > >
> > wrote:
> >
> > > For what it is worth, we use messaging in Ignite to provide grid
> > > notifications for various purposes. These might stimulate compute
> > > operations in the message recipients, but they don't represent compute.
> > >
> > > If messaging is removed, how would Ignite provide the ability for a
> node
> > to
> > > listen to events without the event sender being explicitly aware that
> the
> > > listener does, or should, exist, to produce a compute projection to
> send
> > > messages-as-compute-requests to?
> > >
> > > On Wed, Sep 16, 2020 at 9:28 AM Kseniya Romanova <
> > > romanova.ks.spb@gmail.com>
> > > wrote:
> > >
> > > > Just wanted to submit a link to the video about some offered changes.
> > > > @valentin.kulichenko@gmail.com <va...@gmail.com>
> please
> > > add
> > > > it to the wiki page. I created timestamps in the description, so one
> > can
> > > > browse the presentation fast or link the particular section:
> > > > https://youtu.be/zPuLJgUfLaM
> > > > Thanks a lot for the presentation!
> > > >
> > > > вт, 18 авг. 2020 г. в 14:13, Ilya Kasnacheev <
> > ilya.kasnacheev@gmail.com
> > > >:
> > > >
> > > > > Hello!
> > > > >
> > > > > Maybe we can implement messaging via compute? Share underlying code
> > but
> > > > > have a different API for convenience (maybe in extras).
> > > > >
> > > > > Regards,
> > > > > --
> > > > > Ilya Kasnacheev
> > > > >
> > > > >
> > > > > вт, 18 авг. 2020 г. в 11:59, Pavel Tupitsyn <ptupitsyn@apache.org
> >:
> > > > >
> > > > > > Val,
> > > > > >
> > > > > > > Is see the ".NET Modernization for Ignite 3.0" item in the
> > roadmap,
> > > > but
> > > > > > it
> > > > > > > doesn't provide much detail. What are the actual changes in
> .NET
> > > that
> > > > > you
> > > > > > > propose for 3.0?
> > > > > >
> > > > > > I've updated the roadmap with a brief description.
> > > > > > We want to move away from an old, long unsupported .NET version,
> > > > > > and remove integrations with legacy technologies (old ASP.NET
> and
> > > EF).
> > > > > >
> > > > > > > As for the messaging, so far I haven't seen use cases that
> would
> > > > > require
> > > > > > > this API. Sometimes users attempt to use it for remote code
> > > > invocation,
> > > > > > but
> > > > > > > compute is usually 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.
> > > > > >
> > > > > > Messaging can be more convenient, since it is pub-sub -
> 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
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Aug 18, 2020 at 3:16 AM Saikat Maitra <
> > > saikat.maitra@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 Tupitsyn <
> > > > ptupitsyn@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Saikat, yes, most definitely.
> > > > > > > > This is mentioned in the wishlist under ".NET: Target .NET
> > > Standard
> > > > > > 2.0,
> > > > > > > > discontinue .NET 4.0 support".
> > > > > > > > I'm already working towards this goal by making more code and
> > > tests
> > > > > > work
> > > > > > > > properly under .NET Core,
> > > > > > > > so when the time for breaking changes comes, it will be
> > simpler.
> > > > > > > >
> > > > > > > > On Sat, Aug 15, 2020 at 10:06 PM Saikat Maitra <
> > > > > > saikat.maitra@gmail.com>
> > > > > > > > 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
> > > > > > > > > release?
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Saikat
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Fri, Aug 14, 2020 at 10:04 AM Carbone, Adam <
> > > > > > > > > Adam.Carbone@bottomline.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > If you want to make is simpler to have the components
> that
> > > you
> > > > > > want,
> > > > > > > > but
> > > > > > > > > > have that be immutable at install time you could take an
> > > > approach
> > > > > > > > similar
> > > > > > > > > > to the way spring does it with their initializer (
> > > > > > > > > > https://start.spring.io/ ) as an example... Basically
> the
> > > > > concept
> > > > > > > > being
> > > > > > > > > > something that produces a set of configurations that are
> > used
> > > > to
> > > > > > > define
> > > > > > > > > > what the environment looks like ( these could be k8s
> > objects
> > > )
> > > > > they
> > > > > > > > could
> > > > > > > > > > be spring-configuration objects? They could be something
> > that
> > > > you
> > > > > > > > develop
> > > > > > > > > > all upon ignite ( probably wouldn’t recommend this
> > approach )
> > > > > > there
> > > > > > > > > seems
> > > > > > > > > > to be plenty of these types of things already
> > > > > > > > > >
> > > > > > > > > > Example
> > > > > > > > > > * https://spring.io/guides/gs/centralized-configuration
> > > > > > > > > > *
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cocoon.apache.org/subprojects/configuration/spring-configurator/index.html
> > > > > > > > > >
> > > > > > > > > > And I'm by no means saying to use spring these are just
> > > > examples
> > > > > > > that I
> > > > > > > > > > came across
> > > > > > > > > >
> > > > > > > > > > I'm thinking the outcome needs to be a platform config of
> > > > source
> > > > > (
> > > > > > > that
> > > > > > > > > > can be checked in for those doing gitops ) and maybe ends
> > up
> > > > as a
> > > > > > > > config
> > > > > > > > > > map for those doing k8s, and some other fashion for those
> > > doing
> > > > > > > > something
> > > > > > > > > > else.
> > > > > > > > > >
> > > > > > > > > > Honestly I am not deep enough into the internals of
> ignite
> > to
> > > > > know
> > > > > > > how
> > > > > > > > > > this might work for the platform, was more describing
> what
> > > I'm
> > > > > > seeing
> > > > > > > > > from
> > > > > > > > > > a bigger picture trend
> > > > > > > > > >
> > > > > > > > > > Regards
> > > > > > > > > >
> > > > > > > > > > Adam Carbone | Director of Innovation – Intelligent
> > Platform
> > > > > Team |
> > > > > > > > > > Bottomline Technologies
> > > > > > > > > > Office: 603-501-6446 | Mobile: 603-570-8418
> > > > > > > > > > www.bottomline.com
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On 8/13/20, 7:55 PM, "Valentin Kulichenko" <
> > > > > > > > > valentin.kulichenko@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Ilya,
> > > > > > > > > >
> > > > > > > > > > Can you please describe your vision of how it should
> > > work?
> > > > > > > > > >
> > > > > > > > > > Let's say, I want to set up a cluster of several
> > > standalone
> > > > > > > server
> > > > > > > > > > nodes
> > > > > > > > > > with a couple of optional modules enabled. What are
> my
> > > > steps?
> > > > > > > > > >
> > > > > > > > > > -Val
> > > > > > > > > >
> > > > > > > > > > On Thu, Aug 13, 2020 at 6:03 AM Carbone, Adam <
> > > > > > > > > > Adam.Carbone@bottomline.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Good Morning from the EastCoast
> > > > > > > > > > >
> > > > > > > > > > > I have to agree that the larger industry is tending
> > > > towards
> > > > > > > > > > immutability,
> > > > > > > > > > > and that you build once and test, then you
> > > > promote/migrate
> > > > > > that
> > > > > > > > > > immutable
> > > > > > > > > > > binary object, be is a library or a docker image
> > etc...
> > > > > > however
> > > > > > > > > > there are
> > > > > > > > > > > still patterns that allow you to determine at
> > > install/or
> > > > > > > > deployment
> > > > > > > > > > time (
> > > > > > > > > > > helm as an example, you choose based on your values
> > > what
> > > > > the
> > > > > > > > > package
> > > > > > > > > > > installs/provides ) It just isn't decided at
> runtime
> > > but
> > > > > > > install
> > > > > > > > > and
> > > > > > > > > > often
> > > > > > > > > > > in a gitops type world that is determined by
> > > > configuration
> > > > > as
> > > > > > > > code.
> > > > > > > > > > I think
> > > > > > > > > > > run time is difficult to manage especially in our
> > > > > > increasingly
> > > > > > > > > > > containerized world.
> > > > > > > > > > >
> > > > > > > > > > > Regards.
> > > > > > > > > > >
> > > > > > > > > > > Adam Carbone | Director of Innovation – Intelligent
> > > > > Platform
> > > > > > > > Team |
> > > > > > > > > > > Bottomline Technologies
> > > > > > > > > > > Office: 603-501-6446 | Mobile: 603-570-8418
> > > > > > > > > > > www.bottomline.com
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On 8/13/20, 8:01 AM, "Ilya Kasnacheev" <
> > > > > > > > ilya.kasnacheev@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hello!
> > > > > > > > > > >
> > > > > > > > > > > On the contrary, I would suggest that apache2
> way
> > > was
> > > > > > > > outdated
> > > > > > > > > > even at
> > > > > > > > > > > times when apache was all rage.
> > > > > > > > > > >
> > > > > > > > > > > Now the nginx approach is prevalent: on devops
> > > phase,
> > > > > > > > assemble
> > > > > > > > > a
> > > > > > > > > > custom
> > > > > > > > > > > bundle with all plugins included, store it
> > > somewhere,
> > > > > and
> > > > > > > > ship
> > > > > > > > > > it to
> > > > > > > > > > > production as a whole to remove any on-the-fly
> > > > > > uncertainty
> > > > > > > > from
> > > > > > > > > > > production.
> > > > > > > > > > >
> > > > > > > > > > > This is what docker does, but also maven, which
> > > > > downloads
> > > > > > > > > > dependencies
> > > > > > > > > > > during build. You do not need to download
> > anything
> > > in
> > > > > > > > runtime,
> > > > > > > > > > except
> > > > > > > > > > > for
> > > > > > > > > > > experimental deployments. You need to be all
> set
> > > > before
> > > > > > > > runtime
> > > > > > > > > > starts.
> > > > > > > > > > >
> > > > > > > > > > > Regards,
> > > > > > > > > > > --
> > > > > > > > > > > Ilya Kasnacheev
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > ср, 12 авг. 2020 г. в 09:48, Petr Ivanov <
> > > > > > > > mr.weider@gmail.com
> > > > > > > > > >:
> > > > > > > > > > >
> > > > > > > > > > > > Hi, Val.
> > > > > > > > > > > >
> > > > > > > > > > > > > On 12 Aug 2020, at 01:31, Valentin
> > Kulichenko <
> > > > > > > > > > > > valentin.kulichenko@gmail.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi Petr,
> > > > > > > > > > > > >
> > > > > > > > > > > > > I agree -- we should better modularize the
> > > > > platform.
> > > > > > > The
> > > > > > > > > > current
> > > > > > > > > > > way if
> > > > > > > > > > > > very error-prone, especially during upgrades
> --
> > > any
> > > > > > > changes
> > > > > > > > > > made
> > > > > > > > > > > within
> > > > > > > > > > > > IGNITE_HOME (configs, scripts, modules, etc.)
> > > must
> > > > be
> > > > > > > > merged
> > > > > > > > > > with a
> > > > > > > > > > > new
> > > > > > > > > > > > version of the package. There is no standard
> > way
> > > of
> > > > > > doing
> > > > > > > > > this.
> > > > > > > > > > > > >
> > > > > > > > > > > > > However, I'm a bit concerned with your
> > > suggestion
> > > > > > > > regarding
> > > > > > > > > > custom
> > > > > > > > > > > > dependency management. Can you please
> elaborate
> > > on
> > > > > how
> > > > > > > you
> > > > > > > > > > think it
> > > > > > > > > > > should
> > > > > > > > > > > > work? Are there tools we can reuse for this
> > > > purpose?
> > > > > I
> > > > > > > > would
> > > > > > > > > > try to
> > > > > > > > > > > avoid
> > > > > > > > > > > > reinventing the wheel.
> > > > > > > > > > > >
> > > > > > > > > > > > I see it as a a2enmod | 2dismod analog of
> > > Apache2.
> > > > > > > > > > > >
> > > > > > > > > > > > We build and store Apache Ignite and its
> > modules
> > > as
> > > > > > > > separate
> > > > > > > > > > binaries
> > > > > > > > > > > > (binary per module) then use custom script
> that
> > > > will
> > > > > > know
> > > > > > > > > > where to
> > > > > > > > > > > download
> > > > > > > > > > > > necessary module. Or possibly use modified
> > > > ignite.sh
> > > > > to
> > > > > > > > > specify
> > > > > > > > > > > required
> > > > > > > > > > > > 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.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > -Val
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Sun, Aug 9, 2020 at 11:25 PM Petr
> Ivanov <
> > > > > > > > > > mr.weider@gmail.com
> > > > > > > > > > > > <ma...@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
> > > > > > > > > > > starting
> > > > > > > > > > > > Ignite and all other modules and parts of the
> > > > project
> > > > > > > > > > (benchmarks,
> > > > > > > > > > > > examples, etc.) packed in their own binary
> > which
> > > > can
> > > > > be
> > > > > > > > added
> > > > > > > > > > via
> > > > > > > > > > > custom
> > > > > > > > > > > > dependency management tool (i.e. modules.sh)
> > > > > > > > > > > > > — same distribution for RPM and DEB
> packages
> > > but
> > > > > > with
> > > > > > > > > > modules
> > > > > > > > > > > packed as
> > > > > > > > > > > > separate ones (PHP for example)
> > > > > > > > > > > > > — separate thin client release cycle with
> > > custom
> > > > > > > > > versioning
> > > > > > > > > > > > > Possibly, we can we add additional section
> to
> > > the
> > > > > > > > document
> > > > > > > > > > you
> > > > > > > > > > > > introduced for this part.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Also, it seems that full JDK11 support
> > > (including
> > > > > > > > building)
> > > > > > > > > > would
> > > > > > > > > > > be a
> > > > > > > > > > > > huge milestone and a sign of healthy modern
> > > project
> > > > > > that
> > > > > > > > > tends
> > > > > > > > > > to be
> > > > > > > > > > > on the
> > > > > > > > > > > > verge of mainstream technologies and not the
> > > > > stockpile
> > > > > > of
> > > > > > > > > > legacy
> > > > > > > > > > > leftovers
> > > > > > > > > > > > (fully support Iliya in removing all that was
> > > > > > deprecated
> > > > > > > > > and/or
> > > > > > > > > > > marked as
> > > > > > > > > > > > unused anymore).
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > On 8 Aug 2020, at 02:00, Valentin
> > Kulichenko
> > > <
> > > > > > > > > > > > valentin.kulichenko@gmail.com <mailto:
> > > > > > > > > > valentin.kulichenko@gmail.com
> > > > > > > > > > > >>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Igniters,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I've created the page:
> > > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> > > > > > > > > > > <
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 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 the consensus on
> > the
> > > > > > > proposed
> > > > > > > > > > changes,
> > > > > > > > > > > I will
> > > > > > > > > > > > > > start creating tickets in Jira and a more
> > > > > detailed
> > > > > > > > plan.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -Val
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Thu, Aug 6, 2020 at 6:28 PM Saikat
> > Maitra
> > > <
> > > > > > > > > > > saikat.maitra@gmail.com
> > > > > > > > > > > > <ma...@gmail.com>>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >> Hi Denis, Val
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> Thank you for your reply and really
> > > appreciate
> > > > > it.
> > > > > > > It
> > > > > > > > > > will be
> > > > > > > > > > > very
> > > > > > > > > > > > cool to
> > > > > > > > > > > > > >> be able to connect and plan release
> > together
> > > > and
> > > > > > > learn
> > > > > > > > > > more
> > > > > > > > > > > about
> > > > > > > > > > > > Ignite in
> > > > > > > > > > > > > >> the process :)
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> Regards
> > > > > > > > > > > > > >> Saikat
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> On Thu, Aug 6, 2020 at 7:12 PM Valentin
> > > > > > Kulichenko <
> > > > > > > > > > > > > >> valentin.kulichenko@gmail.com <mailto:
> > > > > > > > > > > valentin.kulichenko@gmail.com>>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >>> Hi Saikat,
> > > > > > > > > > > > > >>>
> > > > > > > > > > > > > >>> That surely is a great idea. We will
> work
> > > > > > together
> > > > > > > > with
> > > > > > > > > > Denis
> > > > > > > > > > > on
> > > > > > > > > > > > setting
> > > > > > > > > > > > > >>> this up in the nearest future.
> > > > > > > > > > > > > >>>
> > > > > > > > > > > > > >>> -Val
> > > > > > > > > > > > > >>>
> > > > > > > > > > > > > >>> On Thu, Aug 6, 2020 at 10:21 AM Denis
> > > Magda <
> > > > > > > > > > dmagda@apache.org
> > > > > > > > > > > > <ma...@apache.org>> wrote:
> > > > > > > > > > > > > >>>
> > > > > > > > > > > > > >>>> Saikat,
> > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > >>>> Fully support your idea on a virtual
> > > meetup!
> > > > > > Once
> > > > > > > > Val
> > > > > > > > > > > collects and
> > > > > > > > > > > > > >>> outlines
> > > > > > > > > > > > > >>>> the main changes with directions on
> > wiki,
> > > > > we’ll
> > > > > > go
> > > > > > > > > > ahead and
> > > > > > > > > > > > schedule
> > > > > > > > > > > > > >> the
> > > > > > > > > > > > > >>>> meetup to talk things out in a bit
> more
> > > > > detail.
> > > > > > > > We’ll
> > > > > > > > > > use our
> > > > > > > > > > > new
> > > > > > > > > > > > > >> Virtual
> > > > > > > > > > > > > >>>> Ignite Meetup group for that inviting
> > both
> > > > > > Ignite
> > > > > > > > > > > contributors and
> > > > > > > > > > > > > >>>> application developers.
> > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > >>>> Denis
> > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > >>>> On Thursday, August 6, 2020, Saikat
> > > Maitra <
> > > > > > > > > > > saikat.maitra@gmail.com
> > > > > > > > > > > > <ma...@gmail.com>>
> > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > >>>>> Hi Valentin
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>> Thank you for sharing and starting
> the
> > > > > thread.
> > > > > > I
> > > > > > > am
> > > > > > > > > > thinking
> > > > > > > > > > > if it
> > > > > > > > > > > > > >> will
> > > > > > > > > > > > > >>>> be
> > > > > > > > > > > > > >>>>> a good idea to have a virtual meet
> > setup
> > > to
> > > > > > > discuss
> > > > > > > > > on
> > > > > > > > > > the
> > > > > > > > > > > release
> > > > > > > > > > > > > >>>>> planning.
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>> It will help to learn more individual
> > > > > features
> > > > > > to
> > > > > > > > be
> > > > > > > > > > added
> > > > > > > > > > > and also
> > > > > > > > > > > > > >> to
> > > > > > > > > > > > > >>>>> understand about features that have
> > been
> > > > > > > deprecated
> > > > > > > > > and
> > > > > > > > > > > scheduled
> > > > > > > > > > > > for
> > > > > > > > > > > > > >>>>> removal in Ignite 3.0 release. Also
> it
> > > will
> > > > > > help
> > > > > > > > > > community
> > > > > > > > > > > member
> > > > > > > > > > > > to
> > > > > > > > > > > > > >>>>> connect in real time and ask
> questions
> > > and
> > > > > > share
> > > > > > > > > > feedback.
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>> Regards,
> > > > > > > > > > > > > >>>>> Saikat
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya
> > > > > Kasnacheev
> > > > > > <
> > > > > > > > > > > > > >>>> ilya.kasnacheev@gmail.com <mailto:
> > > > > > > > > > ilya.kasnacheev@gmail.com>>
> > > > > > > > > > > > > >>>>> wrote:
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>>> Hello!
> > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > >>>>>> I hope to see Apache Ignite release
> > 3.0
> > > as
> > > > > API
> > > > > > > > > > trimming
> > > > > > > > > > > release.
> > > > > > > > > > > > > >> Let
> > > > > > > > > > > > > >>> us
> > > > > > > > > > > > > >>>>>> correct external and internal APIs
> for
> > > > which
> > > > > > we
> > > > > > > > have
> > > > > > > > > > better
> > > > > > > > > > > ideas
> > > > > > > > > > > > > >>> now,
> > > > > > > > > > > > > >>>> as
> > > > > > > > > > > > > >>>>>> well as remove old and deprecated
> > code.
> > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > >>>>>> We may also introduce new
> > configuration
> > > > > > > mechanisms
> > > > > > > > > and
> > > > > > > > > > > user-facing
> > > > > > > > > > > > > >>> API
> > > > > > > > > > > > > >>>>>> (such as cache-less native SQL
> > queries),
> > > > but
> > > > > > > this
> > > > > > > > we
> > > > > > > > > > could
> > > > > > > > > > > > > >> prototype
> > > > > > > > > > > > > >>>>> before
> > > > > > > > > > > > > >>>>>> starting the 3.0 task.
> > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > >>>>>> I will advise against targeting
> large
> > > new
> > > > > > > features
> > > > > > > > > at
> > > > > > > > > > 3.0.
> > > > > > > > > > > They
> > > > > > > > > > > > can
> > > > > > > > > > > > > >>> be
> > > > > > > > > > > > > >>>>>> added in subsequent point releases,
> > > > whereas
> > > > > we
> > > > > > > > can't
> > > > > > > > > > really
> > > > > > > > > > > remove
> > > > > > > > > > > > > >> or
> > > > > > > > > > > > > >>>>>> remodel stuff in point releases.
> > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > >>>>>> Regards,
> > > > > > > > > > > > > >>>>>> --
> > > > > > > > > > > > > >>>>>> Ilya Kasnacheev
> > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin
> > > > > > Kulichenko
> > > > > > > <
> > > > > > > > > > > > > >>>>>> valentin.kulichenko@gmail.com
> > <mailto:
> > > > > > > > > > > > valentin.kulichenko@gmail.com>>:
> > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > >>>>>>> Igniters,
> > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > >>>>>>> I would like to kick off a
> discussion
> > > > > > regarding
> > > > > > > > > > Ignite 3.0.
> > > > > > > > > > > > > >> Ignite
> > > > > > > > > > > > > >>>> 2.0
> > > > > > > > > > > > > >>>>>>> exists for more than 3 years now
> and
> > > > we've
> > > > > > > > already
> > > > > > > > > > > collected a
> > > > > > > > > > > > > >>>>>> significant
> > > > > > > > > > > > > >>>>>>> list [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://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> > > > > > > > > > > <
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> > > > > > > > > > > >
> > > > > > > > > > > > > >>>>> Apache+Ignite+3.0+Wishlist
> > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > >>>>>>> Regards,
> > > > > > > > > > > > > >>>>>>> Val
> > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > >>>> --
> > > > > > > > > > > > > >>>> -
> > > > > > > > > > > > > >>>> Denis
> > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > >>>
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > <http://www.trimble.com/>
> > > Raymond Wilson
> > > Solution Architect, Civil Construction Software Systems (CCSS)
> > > 11 Birmingham Drive | Christchurch, New Zealand
> > > +64-21-2013317 Mobile
> > > raymond_wilson@trimble.com
> > >
> > > <
> > >
> >
> https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch
> > > >
> > >
> >
>
>
> --
> <http://www.trimble.com/>
> Raymond Wilson
> Solution Architect, Civil Construction Software Systems (CCSS)
> 11 Birmingham Drive | Christchurch, New Zealand
> +64-21-2013317 Mobile
> raymond_wilson@trimble.com
>
> <
> https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch
> >
>
Re: Apache Ignite 3.0
Posted by Raymond Wilson <ra...@trimble.com>.
Hi Val,
Possibly, but the core difficulty there is knowing when the fan-out to
listeners has been completed. Before you know it you have
re-implemented Kafka! :)
I think we can leverage our use case knowledge to convert the messaging
style of notifications to a compute style broadcast against a compute
projection using an attribute based selection for nodes that want to be
listeners for the events. The messaging rate is relatively low (a few
messages a second) so this should be pretty workable.
Raymond.
On Thu, Sep 17, 2020 at 3:27 AM Valentin Kulichenko <
valentin.kulichenko@gmail.com> wrote:
> Hi Raymond,
>
> Do you think you could use services for your use case?
> https://apacheignite.readme.io/docs/service-grid
>
> -Val
>
> On Tue, Sep 15, 2020 at 4:32 PM Raymond Wilson <raymond_wilson@trimble.com
> >
> wrote:
>
> > For what it is worth, we use messaging in Ignite to provide grid
> > notifications for various purposes. These might stimulate compute
> > operations in the message recipients, but they don't represent compute.
> >
> > If messaging is removed, how would Ignite provide the ability for a node
> to
> > listen to events without the event sender being explicitly aware that the
> > listener does, or should, exist, to produce a compute projection to send
> > messages-as-compute-requests to?
> >
> > On Wed, Sep 16, 2020 at 9:28 AM Kseniya Romanova <
> > romanova.ks.spb@gmail.com>
> > wrote:
> >
> > > Just wanted to submit a link to the video about some offered changes.
> > > @valentin.kulichenko@gmail.com <va...@gmail.com> please
> > add
> > > it to the wiki page. I created timestamps in the description, so one
> can
> > > browse the presentation fast or link the particular section:
> > > https://youtu.be/zPuLJgUfLaM
> > > Thanks a lot for the presentation!
> > >
> > > вт, 18 авг. 2020 г. в 14:13, Ilya Kasnacheev <
> ilya.kasnacheev@gmail.com
> > >:
> > >
> > > > Hello!
> > > >
> > > > Maybe we can implement messaging via compute? Share underlying code
> but
> > > > have a different API for convenience (maybe in extras).
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > вт, 18 авг. 2020 г. в 11:59, Pavel Tupitsyn <pt...@apache.org>:
> > > >
> > > > > Val,
> > > > >
> > > > > > Is see the ".NET Modernization for Ignite 3.0" item in the
> roadmap,
> > > but
> > > > > it
> > > > > > doesn't provide much detail. What are the actual changes in .NET
> > that
> > > > you
> > > > > > propose for 3.0?
> > > > >
> > > > > I've updated the roadmap with a brief description.
> > > > > We want to move away from an old, long unsupported .NET version,
> > > > > and remove integrations with legacy technologies (old ASP.NET and
> > EF).
> > > > >
> > > > > > As for the messaging, so far I haven't seen use cases that would
> > > > require
> > > > > > this API. Sometimes users attempt to use it for remote code
> > > invocation,
> > > > > but
> > > > > > compute is usually 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.
> > > > >
> > > > > Messaging can be more convenient, since it is pub-sub - 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
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Aug 18, 2020 at 3:16 AM Saikat Maitra <
> > saikat.maitra@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 Tupitsyn <
> > > ptupitsyn@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > Saikat, yes, most definitely.
> > > > > > > This is mentioned in the wishlist under ".NET: Target .NET
> > Standard
> > > > > 2.0,
> > > > > > > discontinue .NET 4.0 support".
> > > > > > > I'm already working towards this goal by making more code and
> > tests
> > > > > work
> > > > > > > properly under .NET Core,
> > > > > > > so when the time for breaking changes comes, it will be
> simpler.
> > > > > > >
> > > > > > > On Sat, Aug 15, 2020 at 10:06 PM Saikat Maitra <
> > > > > saikat.maitra@gmail.com>
> > > > > > > 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
> > > > > > > > release?
> > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Saikat
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Aug 14, 2020 at 10:04 AM Carbone, Adam <
> > > > > > > > Adam.Carbone@bottomline.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > If you want to make is simpler to have the components that
> > you
> > > > > want,
> > > > > > > but
> > > > > > > > > have that be immutable at install time you could take an
> > > approach
> > > > > > > similar
> > > > > > > > > to the way spring does it with their initializer (
> > > > > > > > > https://start.spring.io/ ) as an example... Basically the
> > > > concept
> > > > > > > being
> > > > > > > > > something that produces a set of configurations that are
> used
> > > to
> > > > > > define
> > > > > > > > > what the environment looks like ( these could be k8s
> objects
> > )
> > > > they
> > > > > > > could
> > > > > > > > > be spring-configuration objects? They could be something
> that
> > > you
> > > > > > > develop
> > > > > > > > > all upon ignite ( probably wouldn’t recommend this
> approach )
> > > > > there
> > > > > > > > seems
> > > > > > > > > to be plenty of these types of things already
> > > > > > > > >
> > > > > > > > > Example
> > > > > > > > > * https://spring.io/guides/gs/centralized-configuration
> > > > > > > > > *
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cocoon.apache.org/subprojects/configuration/spring-configurator/index.html
> > > > > > > > >
> > > > > > > > > And I'm by no means saying to use spring these are just
> > > examples
> > > > > > that I
> > > > > > > > > came across
> > > > > > > > >
> > > > > > > > > I'm thinking the outcome needs to be a platform config of
> > > source
> > > > (
> > > > > > that
> > > > > > > > > can be checked in for those doing gitops ) and maybe ends
> up
> > > as a
> > > > > > > config
> > > > > > > > > map for those doing k8s, and some other fashion for those
> > doing
> > > > > > > something
> > > > > > > > > else.
> > > > > > > > >
> > > > > > > > > Honestly I am not deep enough into the internals of ignite
> to
> > > > know
> > > > > > how
> > > > > > > > > this might work for the platform, was more describing what
> > I'm
> > > > > seeing
> > > > > > > > from
> > > > > > > > > a bigger picture trend
> > > > > > > > >
> > > > > > > > > Regards
> > > > > > > > >
> > > > > > > > > Adam Carbone | Director of Innovation – Intelligent
> Platform
> > > > Team |
> > > > > > > > > Bottomline Technologies
> > > > > > > > > Office: 603-501-6446 | Mobile: 603-570-8418
> > > > > > > > > www.bottomline.com
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 8/13/20, 7:55 PM, "Valentin Kulichenko" <
> > > > > > > > valentin.kulichenko@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi Ilya,
> > > > > > > > >
> > > > > > > > > Can you please describe your vision of how it should
> > work?
> > > > > > > > >
> > > > > > > > > Let's say, I want to set up a cluster of several
> > standalone
> > > > > > server
> > > > > > > > > nodes
> > > > > > > > > with a couple of optional modules enabled. What are my
> > > steps?
> > > > > > > > >
> > > > > > > > > -Val
> > > > > > > > >
> > > > > > > > > On Thu, Aug 13, 2020 at 6:03 AM Carbone, Adam <
> > > > > > > > > Adam.Carbone@bottomline.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Good Morning from the EastCoast
> > > > > > > > > >
> > > > > > > > > > I have to agree that the larger industry is tending
> > > towards
> > > > > > > > > immutability,
> > > > > > > > > > and that you build once and test, then you
> > > promote/migrate
> > > > > that
> > > > > > > > > immutable
> > > > > > > > > > binary object, be is a library or a docker image
> etc...
> > > > > however
> > > > > > > > > there are
> > > > > > > > > > still patterns that allow you to determine at
> > install/or
> > > > > > > deployment
> > > > > > > > > time (
> > > > > > > > > > helm as an example, you choose based on your values
> > what
> > > > the
> > > > > > > > package
> > > > > > > > > > installs/provides ) It just isn't decided at runtime
> > but
> > > > > > install
> > > > > > > > and
> > > > > > > > > often
> > > > > > > > > > in a gitops type world that is determined by
> > > configuration
> > > > as
> > > > > > > code.
> > > > > > > > > I think
> > > > > > > > > > run time is difficult to manage especially in our
> > > > > increasingly
> > > > > > > > > > containerized world.
> > > > > > > > > >
> > > > > > > > > > Regards.
> > > > > > > > > >
> > > > > > > > > > Adam Carbone | Director of Innovation – Intelligent
> > > > Platform
> > > > > > > Team |
> > > > > > > > > > Bottomline Technologies
> > > > > > > > > > Office: 603-501-6446 | Mobile: 603-570-8418
> > > > > > > > > > www.bottomline.com
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On 8/13/20, 8:01 AM, "Ilya Kasnacheev" <
> > > > > > > ilya.kasnacheev@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hello!
> > > > > > > > > >
> > > > > > > > > > On the contrary, I would suggest that apache2 way
> > was
> > > > > > > outdated
> > > > > > > > > even at
> > > > > > > > > > times when apache was all rage.
> > > > > > > > > >
> > > > > > > > > > Now the nginx approach is prevalent: on devops
> > phase,
> > > > > > > assemble
> > > > > > > > a
> > > > > > > > > custom
> > > > > > > > > > bundle with all plugins included, store it
> > somewhere,
> > > > and
> > > > > > > ship
> > > > > > > > > it to
> > > > > > > > > > production as a whole to remove any on-the-fly
> > > > > uncertainty
> > > > > > > from
> > > > > > > > > > production.
> > > > > > > > > >
> > > > > > > > > > This is what docker does, but also maven, which
> > > > downloads
> > > > > > > > > dependencies
> > > > > > > > > > during build. You do not need to download
> anything
> > in
> > > > > > > runtime,
> > > > > > > > > except
> > > > > > > > > > for
> > > > > > > > > > experimental deployments. You need to be all set
> > > before
> > > > > > > runtime
> > > > > > > > > starts.
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > > --
> > > > > > > > > > Ilya Kasnacheev
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > ср, 12 авг. 2020 г. в 09:48, Petr Ivanov <
> > > > > > > mr.weider@gmail.com
> > > > > > > > >:
> > > > > > > > > >
> > > > > > > > > > > Hi, Val.
> > > > > > > > > > >
> > > > > > > > > > > > On 12 Aug 2020, at 01:31, Valentin
> Kulichenko <
> > > > > > > > > > > valentin.kulichenko@gmail.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Petr,
> > > > > > > > > > > >
> > > > > > > > > > > > I agree -- we should better modularize the
> > > > platform.
> > > > > > The
> > > > > > > > > current
> > > > > > > > > > way if
> > > > > > > > > > > very error-prone, especially during upgrades --
> > any
> > > > > > changes
> > > > > > > > > made
> > > > > > > > > > within
> > > > > > > > > > > IGNITE_HOME (configs, scripts, modules, etc.)
> > must
> > > be
> > > > > > > merged
> > > > > > > > > with a
> > > > > > > > > > new
> > > > > > > > > > > version of the package. There is no standard
> way
> > of
> > > > > doing
> > > > > > > > this.
> > > > > > > > > > > >
> > > > > > > > > > > > However, I'm a bit concerned with your
> > suggestion
> > > > > > > regarding
> > > > > > > > > custom
> > > > > > > > > > > dependency management. Can you please elaborate
> > on
> > > > how
> > > > > > you
> > > > > > > > > think it
> > > > > > > > > > should
> > > > > > > > > > > work? Are there tools we can reuse for this
> > > purpose?
> > > > I
> > > > > > > would
> > > > > > > > > try to
> > > > > > > > > > avoid
> > > > > > > > > > > reinventing the wheel.
> > > > > > > > > > >
> > > > > > > > > > > I see it as a a2enmod | 2dismod analog of
> > Apache2.
> > > > > > > > > > >
> > > > > > > > > > > We build and store Apache Ignite and its
> modules
> > as
> > > > > > > separate
> > > > > > > > > binaries
> > > > > > > > > > > (binary per module) then use custom script that
> > > will
> > > > > know
> > > > > > > > > where to
> > > > > > > > > > download
> > > > > > > > > > > necessary module. Or possibly use modified
> > > ignite.sh
> > > > to
> > > > > > > > specify
> > > > > > > > > > required
> > > > > > > > > > > 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.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > -Val
> > > > > > > > > > > >
> > > > > > > > > > > > On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov <
> > > > > > > > > mr.weider@gmail.com
> > > > > > > > > > > <ma...@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
> > > > > > > > > > starting
> > > > > > > > > > > Ignite and all other modules and parts of the
> > > project
> > > > > > > > > (benchmarks,
> > > > > > > > > > > examples, etc.) packed in their own binary
> which
> > > can
> > > > be
> > > > > > > added
> > > > > > > > > via
> > > > > > > > > > custom
> > > > > > > > > > > dependency management tool (i.e. modules.sh)
> > > > > > > > > > > > — same distribution for RPM and DEB packages
> > but
> > > > > with
> > > > > > > > > modules
> > > > > > > > > > packed as
> > > > > > > > > > > separate ones (PHP for example)
> > > > > > > > > > > > — separate thin client release cycle with
> > custom
> > > > > > > > versioning
> > > > > > > > > > > > Possibly, we can we add additional section to
> > the
> > > > > > > document
> > > > > > > > > you
> > > > > > > > > > > introduced for this part.
> > > > > > > > > > > >
> > > > > > > > > > > > Also, it seems that full JDK11 support
> > (including
> > > > > > > building)
> > > > > > > > > would
> > > > > > > > > > be a
> > > > > > > > > > > huge milestone and a sign of healthy modern
> > project
> > > > > that
> > > > > > > > tends
> > > > > > > > > to be
> > > > > > > > > > on the
> > > > > > > > > > > verge of mainstream technologies and not the
> > > > stockpile
> > > > > of
> > > > > > > > > legacy
> > > > > > > > > > leftovers
> > > > > > > > > > > (fully support Iliya in removing all that was
> > > > > deprecated
> > > > > > > > and/or
> > > > > > > > > > marked as
> > > > > > > > > > > unused anymore).
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > On 8 Aug 2020, at 02:00, Valentin
> Kulichenko
> > <
> > > > > > > > > > > valentin.kulichenko@gmail.com <mailto:
> > > > > > > > > valentin.kulichenko@gmail.com
> > > > > > > > > > >>
> > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Igniters,
> > > > > > > > > > > > >
> > > > > > > > > > > > > I've created the page:
> > > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> > > > > > > > > > <
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 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 the consensus on
> the
> > > > > > proposed
> > > > > > > > > changes,
> > > > > > > > > > I will
> > > > > > > > > > > > > start creating tickets in Jira and a more
> > > > detailed
> > > > > > > plan.
> > > > > > > > > > > > >
> > > > > > > > > > > > > -Val
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, Aug 6, 2020 at 6:28 PM Saikat
> Maitra
> > <
> > > > > > > > > > saikat.maitra@gmail.com
> > > > > > > > > > > <ma...@gmail.com>>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > >> Hi Denis, Val
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Thank you for your reply and really
> > appreciate
> > > > it.
> > > > > > It
> > > > > > > > > will be
> > > > > > > > > > very
> > > > > > > > > > > cool to
> > > > > > > > > > > > >> be able to connect and plan release
> together
> > > and
> > > > > > learn
> > > > > > > > > more
> > > > > > > > > > about
> > > > > > > > > > > Ignite in
> > > > > > > > > > > > >> the process :)
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Regards
> > > > > > > > > > > > >> Saikat
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> On Thu, Aug 6, 2020 at 7:12 PM Valentin
> > > > > Kulichenko <
> > > > > > > > > > > > >> valentin.kulichenko@gmail.com <mailto:
> > > > > > > > > > valentin.kulichenko@gmail.com>>
> > > > > > > > > > > wrote:
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>> Hi Saikat,
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> That surely is a great idea. We will work
> > > > > together
> > > > > > > with
> > > > > > > > > Denis
> > > > > > > > > > on
> > > > > > > > > > > setting
> > > > > > > > > > > > >>> this up in the nearest future.
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> -Val
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> On Thu, Aug 6, 2020 at 10:21 AM Denis
> > Magda <
> > > > > > > > > dmagda@apache.org
> > > > > > > > > > > <ma...@apache.org>> wrote:
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>>> Saikat,
> > > > > > > > > > > > >>>>
> > > > > > > > > > > > >>>> Fully support your idea on a virtual
> > meetup!
> > > > > Once
> > > > > > > Val
> > > > > > > > > > collects and
> > > > > > > > > > > > >>> outlines
> > > > > > > > > > > > >>>> the main changes with directions on
> wiki,
> > > > we’ll
> > > > > go
> > > > > > > > > ahead and
> > > > > > > > > > > schedule
> > > > > > > > > > > > >> the
> > > > > > > > > > > > >>>> meetup to talk things out in a bit more
> > > > detail.
> > > > > > > We’ll
> > > > > > > > > use our
> > > > > > > > > > new
> > > > > > > > > > > > >> Virtual
> > > > > > > > > > > > >>>> Ignite Meetup group for that inviting
> both
> > > > > Ignite
> > > > > > > > > > contributors and
> > > > > > > > > > > > >>>> application developers.
> > > > > > > > > > > > >>>>
> > > > > > > > > > > > >>>> Denis
> > > > > > > > > > > > >>>>
> > > > > > > > > > > > >>>> On Thursday, August 6, 2020, Saikat
> > Maitra <
> > > > > > > > > > saikat.maitra@gmail.com
> > > > > > > > > > > <ma...@gmail.com>>
> > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > >>>>
> > > > > > > > > > > > >>>>> Hi Valentin
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>> Thank you for sharing and starting the
> > > > thread.
> > > > > I
> > > > > > am
> > > > > > > > > thinking
> > > > > > > > > > if it
> > > > > > > > > > > > >> will
> > > > > > > > > > > > >>>> be
> > > > > > > > > > > > >>>>> a good idea to have a virtual meet
> setup
> > to
> > > > > > discuss
> > > > > > > > on
> > > > > > > > > the
> > > > > > > > > > release
> > > > > > > > > > > > >>>>> planning.
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>> It will help to learn more individual
> > > > features
> > > > > to
> > > > > > > be
> > > > > > > > > added
> > > > > > > > > > and also
> > > > > > > > > > > > >> to
> > > > > > > > > > > > >>>>> understand about features that have
> been
> > > > > > deprecated
> > > > > > > > and
> > > > > > > > > > scheduled
> > > > > > > > > > > for
> > > > > > > > > > > > >>>>> removal in Ignite 3.0 release. Also it
> > will
> > > > > help
> > > > > > > > > community
> > > > > > > > > > member
> > > > > > > > > > > to
> > > > > > > > > > > > >>>>> connect in real time and ask questions
> > and
> > > > > share
> > > > > > > > > feedback.
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>> Regards,
> > > > > > > > > > > > >>>>> Saikat
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya
> > > > Kasnacheev
> > > > > <
> > > > > > > > > > > > >>>> ilya.kasnacheev@gmail.com <mailto:
> > > > > > > > > ilya.kasnacheev@gmail.com>>
> > > > > > > > > > > > >>>>> wrote:
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>>> Hello!
> > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > >>>>>> I hope to see Apache Ignite release
> 3.0
> > as
> > > > API
> > > > > > > > > trimming
> > > > > > > > > > release.
> > > > > > > > > > > > >> Let
> > > > > > > > > > > > >>> us
> > > > > > > > > > > > >>>>>> correct external and internal APIs for
> > > which
> > > > > we
> > > > > > > have
> > > > > > > > > better
> > > > > > > > > > ideas
> > > > > > > > > > > > >>> now,
> > > > > > > > > > > > >>>> as
> > > > > > > > > > > > >>>>>> well as remove old and deprecated
> code.
> > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > >>>>>> We may also introduce new
> configuration
> > > > > > mechanisms
> > > > > > > > and
> > > > > > > > > > user-facing
> > > > > > > > > > > > >>> API
> > > > > > > > > > > > >>>>>> (such as cache-less native SQL
> queries),
> > > but
> > > > > > this
> > > > > > > we
> > > > > > > > > could
> > > > > > > > > > > > >> prototype
> > > > > > > > > > > > >>>>> before
> > > > > > > > > > > > >>>>>> starting the 3.0 task.
> > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > >>>>>> I will advise against targeting large
> > new
> > > > > > features
> > > > > > > > at
> > > > > > > > > 3.0.
> > > > > > > > > > They
> > > > > > > > > > > can
> > > > > > > > > > > > >>> be
> > > > > > > > > > > > >>>>>> added in subsequent point releases,
> > > whereas
> > > > we
> > > > > > > can't
> > > > > > > > > really
> > > > > > > > > > remove
> > > > > > > > > > > > >> or
> > > > > > > > > > > > >>>>>> remodel stuff in point releases.
> > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > >>>>>> Regards,
> > > > > > > > > > > > >>>>>> --
> > > > > > > > > > > > >>>>>> Ilya Kasnacheev
> > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin
> > > > > Kulichenko
> > > > > > <
> > > > > > > > > > > > >>>>>> valentin.kulichenko@gmail.com
> <mailto:
> > > > > > > > > > > valentin.kulichenko@gmail.com>>:
> > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > >>>>>>> Igniters,
> > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > >>>>>>> I would like to kick off a discussion
> > > > > regarding
> > > > > > > > > Ignite 3.0.
> > > > > > > > > > > > >> Ignite
> > > > > > > > > > > > >>>> 2.0
> > > > > > > > > > > > >>>>>>> exists for more than 3 years now and
> > > we've
> > > > > > > already
> > > > > > > > > > collected a
> > > > > > > > > > > > >>>>>> significant
> > > > > > > > > > > > >>>>>>> list [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://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> > > > > > > > > > <
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> > > > > > > > > > >
> > > > > > > > > > > > >>>>> Apache+Ignite+3.0+Wishlist
> > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > >>>>>>> Regards,
> > > > > > > > > > > > >>>>>>> Val
> > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>
> > > > > > > > > > > > >>>>
> > > > > > > > > > > > >>>> --
> > > > > > > > > > > > >>>> -
> > > > > > > > > > > > >>>> Denis
> > > > > > > > > > > > >>>>
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > <http://www.trimble.com/>
> > Raymond Wilson
> > Solution Architect, Civil Construction Software Systems (CCSS)
> > 11 Birmingham Drive | Christchurch, New Zealand
> > +64-21-2013317 Mobile
> > raymond_wilson@trimble.com
> >
> > <
> >
> https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch
> > >
> >
>
--
<http://www.trimble.com/>
Raymond Wilson
Solution Architect, Civil Construction Software Systems (CCSS)
11 Birmingham Drive | Christchurch, New Zealand
+64-21-2013317 Mobile
raymond_wilson@trimble.com
<https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch>
Re: Apache Ignite 3.0
Posted by Valentin Kulichenko <va...@gmail.com>.
Hi Raymond,
Do you think you could use services for your use case?
https://apacheignite.readme.io/docs/service-grid
-Val
On Tue, Sep 15, 2020 at 4:32 PM Raymond Wilson <ra...@trimble.com>
wrote:
> For what it is worth, we use messaging in Ignite to provide grid
> notifications for various purposes. These might stimulate compute
> operations in the message recipients, but they don't represent compute.
>
> If messaging is removed, how would Ignite provide the ability for a node to
> listen to events without the event sender being explicitly aware that the
> listener does, or should, exist, to produce a compute projection to send
> messages-as-compute-requests to?
>
> On Wed, Sep 16, 2020 at 9:28 AM Kseniya Romanova <
> romanova.ks.spb@gmail.com>
> wrote:
>
> > Just wanted to submit a link to the video about some offered changes.
> > @valentin.kulichenko@gmail.com <va...@gmail.com> please
> add
> > it to the wiki page. I created timestamps in the description, so one can
> > browse the presentation fast or link the particular section:
> > https://youtu.be/zPuLJgUfLaM
> > Thanks a lot for the presentation!
> >
> > вт, 18 авг. 2020 г. в 14:13, Ilya Kasnacheev <ilya.kasnacheev@gmail.com
> >:
> >
> > > Hello!
> > >
> > > Maybe we can implement messaging via compute? Share underlying code but
> > > have a different API for convenience (maybe in extras).
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > вт, 18 авг. 2020 г. в 11:59, Pavel Tupitsyn <pt...@apache.org>:
> > >
> > > > Val,
> > > >
> > > > > Is see the ".NET Modernization for Ignite 3.0" item in the roadmap,
> > but
> > > > it
> > > > > doesn't provide much detail. What are the actual changes in .NET
> that
> > > you
> > > > > propose for 3.0?
> > > >
> > > > I've updated the roadmap with a brief description.
> > > > We want to move away from an old, long unsupported .NET version,
> > > > and remove integrations with legacy technologies (old ASP.NET and
> EF).
> > > >
> > > > > As for the messaging, so far I haven't seen use cases that would
> > > require
> > > > > this API. Sometimes users attempt to use it for remote code
> > invocation,
> > > > but
> > > > > compute is usually 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.
> > > >
> > > > Messaging can be more convenient, since it is pub-sub - 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
> > > >
> > > >
> > > >
> > > > On Tue, Aug 18, 2020 at 3:16 AM Saikat Maitra <
> saikat.maitra@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 Tupitsyn <
> > ptupitsyn@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Saikat, yes, most definitely.
> > > > > > This is mentioned in the wishlist under ".NET: Target .NET
> Standard
> > > > 2.0,
> > > > > > discontinue .NET 4.0 support".
> > > > > > I'm already working towards this goal by making more code and
> tests
> > > > work
> > > > > > properly under .NET Core,
> > > > > > so when the time for breaking changes comes, it will be simpler.
> > > > > >
> > > > > > On Sat, Aug 15, 2020 at 10:06 PM Saikat Maitra <
> > > > saikat.maitra@gmail.com>
> > > > > > 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
> > > > > > > release?
> > > > > > >
> > > > > > >
> > > > >
> > >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap
> > > > > > >
> > > > > > > Regards,
> > > > > > > Saikat
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Aug 14, 2020 at 10:04 AM Carbone, Adam <
> > > > > > > Adam.Carbone@bottomline.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > If you want to make is simpler to have the components that
> you
> > > > want,
> > > > > > but
> > > > > > > > have that be immutable at install time you could take an
> > approach
> > > > > > similar
> > > > > > > > to the way spring does it with their initializer (
> > > > > > > > https://start.spring.io/ ) as an example... Basically the
> > > concept
> > > > > > being
> > > > > > > > something that produces a set of configurations that are used
> > to
> > > > > define
> > > > > > > > what the environment looks like ( these could be k8s objects
> )
> > > they
> > > > > > could
> > > > > > > > be spring-configuration objects? They could be something that
> > you
> > > > > > develop
> > > > > > > > all upon ignite ( probably wouldn’t recommend this approach )
> > > > there
> > > > > > > seems
> > > > > > > > to be plenty of these types of things already
> > > > > > > >
> > > > > > > > Example
> > > > > > > > * https://spring.io/guides/gs/centralized-configuration
> > > > > > > > *
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cocoon.apache.org/subprojects/configuration/spring-configurator/index.html
> > > > > > > >
> > > > > > > > And I'm by no means saying to use spring these are just
> > examples
> > > > > that I
> > > > > > > > came across
> > > > > > > >
> > > > > > > > I'm thinking the outcome needs to be a platform config of
> > source
> > > (
> > > > > that
> > > > > > > > can be checked in for those doing gitops ) and maybe ends up
> > as a
> > > > > > config
> > > > > > > > map for those doing k8s, and some other fashion for those
> doing
> > > > > > something
> > > > > > > > else.
> > > > > > > >
> > > > > > > > Honestly I am not deep enough into the internals of ignite to
> > > know
> > > > > how
> > > > > > > > this might work for the platform, was more describing what
> I'm
> > > > seeing
> > > > > > > from
> > > > > > > > a bigger picture trend
> > > > > > > >
> > > > > > > > Regards
> > > > > > > >
> > > > > > > > Adam Carbone | Director of Innovation – Intelligent Platform
> > > Team |
> > > > > > > > Bottomline Technologies
> > > > > > > > Office: 603-501-6446 | Mobile: 603-570-8418
> > > > > > > > www.bottomline.com
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 8/13/20, 7:55 PM, "Valentin Kulichenko" <
> > > > > > > valentin.kulichenko@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Ilya,
> > > > > > > >
> > > > > > > > Can you please describe your vision of how it should
> work?
> > > > > > > >
> > > > > > > > Let's say, I want to set up a cluster of several
> standalone
> > > > > server
> > > > > > > > nodes
> > > > > > > > with a couple of optional modules enabled. What are my
> > steps?
> > > > > > > >
> > > > > > > > -Val
> > > > > > > >
> > > > > > > > On Thu, Aug 13, 2020 at 6:03 AM Carbone, Adam <
> > > > > > > > Adam.Carbone@bottomline.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Good Morning from the EastCoast
> > > > > > > > >
> > > > > > > > > I have to agree that the larger industry is tending
> > towards
> > > > > > > > immutability,
> > > > > > > > > and that you build once and test, then you
> > promote/migrate
> > > > that
> > > > > > > > immutable
> > > > > > > > > binary object, be is a library or a docker image etc...
> > > > however
> > > > > > > > there are
> > > > > > > > > still patterns that allow you to determine at
> install/or
> > > > > > deployment
> > > > > > > > time (
> > > > > > > > > helm as an example, you choose based on your values
> what
> > > the
> > > > > > > package
> > > > > > > > > installs/provides ) It just isn't decided at runtime
> but
> > > > > install
> > > > > > > and
> > > > > > > > often
> > > > > > > > > in a gitops type world that is determined by
> > configuration
> > > as
> > > > > > code.
> > > > > > > > I think
> > > > > > > > > run time is difficult to manage especially in our
> > > > increasingly
> > > > > > > > > containerized world.
> > > > > > > > >
> > > > > > > > > Regards.
> > > > > > > > >
> > > > > > > > > Adam Carbone | Director of Innovation – Intelligent
> > > Platform
> > > > > > Team |
> > > > > > > > > Bottomline Technologies
> > > > > > > > > Office: 603-501-6446 | Mobile: 603-570-8418
> > > > > > > > > www.bottomline.com
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 8/13/20, 8:01 AM, "Ilya Kasnacheev" <
> > > > > > ilya.kasnacheev@gmail.com>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hello!
> > > > > > > > >
> > > > > > > > > On the contrary, I would suggest that apache2 way
> was
> > > > > > outdated
> > > > > > > > even at
> > > > > > > > > times when apache was all rage.
> > > > > > > > >
> > > > > > > > > Now the nginx approach is prevalent: on devops
> phase,
> > > > > > assemble
> > > > > > > a
> > > > > > > > custom
> > > > > > > > > bundle with all plugins included, store it
> somewhere,
> > > and
> > > > > > ship
> > > > > > > > it to
> > > > > > > > > production as a whole to remove any on-the-fly
> > > > uncertainty
> > > > > > from
> > > > > > > > > production.
> > > > > > > > >
> > > > > > > > > This is what docker does, but also maven, which
> > > downloads
> > > > > > > > dependencies
> > > > > > > > > during build. You do not need to download anything
> in
> > > > > > runtime,
> > > > > > > > except
> > > > > > > > > for
> > > > > > > > > experimental deployments. You need to be all set
> > before
> > > > > > runtime
> > > > > > > > starts.
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > --
> > > > > > > > > Ilya Kasnacheev
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > ср, 12 авг. 2020 г. в 09:48, Petr Ivanov <
> > > > > > mr.weider@gmail.com
> > > > > > > >:
> > > > > > > > >
> > > > > > > > > > Hi, Val.
> > > > > > > > > >
> > > > > > > > > > > On 12 Aug 2020, at 01:31, Valentin Kulichenko <
> > > > > > > > > > valentin.kulichenko@gmail.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Petr,
> > > > > > > > > > >
> > > > > > > > > > > I agree -- we should better modularize the
> > > platform.
> > > > > The
> > > > > > > > current
> > > > > > > > > way if
> > > > > > > > > > very error-prone, especially during upgrades --
> any
> > > > > changes
> > > > > > > > made
> > > > > > > > > within
> > > > > > > > > > IGNITE_HOME (configs, scripts, modules, etc.)
> must
> > be
> > > > > > merged
> > > > > > > > with a
> > > > > > > > > new
> > > > > > > > > > version of the package. There is no standard way
> of
> > > > doing
> > > > > > > this.
> > > > > > > > > > >
> > > > > > > > > > > However, I'm a bit concerned with your
> suggestion
> > > > > > regarding
> > > > > > > > custom
> > > > > > > > > > dependency management. Can you please elaborate
> on
> > > how
> > > > > you
> > > > > > > > think it
> > > > > > > > > should
> > > > > > > > > > work? Are there tools we can reuse for this
> > purpose?
> > > I
> > > > > > would
> > > > > > > > try to
> > > > > > > > > avoid
> > > > > > > > > > reinventing the wheel.
> > > > > > > > > >
> > > > > > > > > > I see it as a a2enmod | 2dismod analog of
> Apache2.
> > > > > > > > > >
> > > > > > > > > > We build and store Apache Ignite and its modules
> as
> > > > > > separate
> > > > > > > > binaries
> > > > > > > > > > (binary per module) then use custom script that
> > will
> > > > know
> > > > > > > > where to
> > > > > > > > > download
> > > > > > > > > > necessary module. Or possibly use modified
> > ignite.sh
> > > to
> > > > > > > specify
> > > > > > > > > required
> > > > > > > > > > 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.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > -Val
> > > > > > > > > > >
> > > > > > > > > > > On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov <
> > > > > > > > mr.weider@gmail.com
> > > > > > > > > > <ma...@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
> > > > > > > > > starting
> > > > > > > > > > Ignite and all other modules and parts of the
> > project
> > > > > > > > (benchmarks,
> > > > > > > > > > examples, etc.) packed in their own binary which
> > can
> > > be
> > > > > > added
> > > > > > > > via
> > > > > > > > > custom
> > > > > > > > > > dependency management tool (i.e. modules.sh)
> > > > > > > > > > > — same distribution for RPM and DEB packages
> but
> > > > with
> > > > > > > > modules
> > > > > > > > > packed as
> > > > > > > > > > separate ones (PHP for example)
> > > > > > > > > > > — separate thin client release cycle with
> custom
> > > > > > > versioning
> > > > > > > > > > > Possibly, we can we add additional section to
> the
> > > > > > document
> > > > > > > > you
> > > > > > > > > > introduced for this part.
> > > > > > > > > > >
> > > > > > > > > > > Also, it seems that full JDK11 support
> (including
> > > > > > building)
> > > > > > > > would
> > > > > > > > > be a
> > > > > > > > > > huge milestone and a sign of healthy modern
> project
> > > > that
> > > > > > > tends
> > > > > > > > to be
> > > > > > > > > on the
> > > > > > > > > > verge of mainstream technologies and not the
> > > stockpile
> > > > of
> > > > > > > > legacy
> > > > > > > > > leftovers
> > > > > > > > > > (fully support Iliya in removing all that was
> > > > deprecated
> > > > > > > and/or
> > > > > > > > > marked as
> > > > > > > > > > unused anymore).
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > On 8 Aug 2020, at 02:00, Valentin Kulichenko
> <
> > > > > > > > > > valentin.kulichenko@gmail.com <mailto:
> > > > > > > > valentin.kulichenko@gmail.com
> > > > > > > > > >>
> > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Igniters,
> > > > > > > > > > > >
> > > > > > > > > > > > I've created the page:
> > > > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> > > > > > > > > <
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 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 the consensus on the
> > > > > proposed
> > > > > > > > changes,
> > > > > > > > > I will
> > > > > > > > > > > > start creating tickets in Jira and a more
> > > detailed
> > > > > > plan.
> > > > > > > > > > > >
> > > > > > > > > > > > -Val
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra
> <
> > > > > > > > > saikat.maitra@gmail.com
> > > > > > > > > > <ma...@gmail.com>>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >> Hi Denis, Val
> > > > > > > > > > > >>
> > > > > > > > > > > >> Thank you for your reply and really
> appreciate
> > > it.
> > > > > It
> > > > > > > > will be
> > > > > > > > > very
> > > > > > > > > > cool to
> > > > > > > > > > > >> be able to connect and plan release together
> > and
> > > > > learn
> > > > > > > > more
> > > > > > > > > about
> > > > > > > > > > Ignite in
> > > > > > > > > > > >> the process :)
> > > > > > > > > > > >>
> > > > > > > > > > > >> Regards
> > > > > > > > > > > >> Saikat
> > > > > > > > > > > >>
> > > > > > > > > > > >>
> > > > > > > > > > > >>
> > > > > > > > > > > >> On Thu, Aug 6, 2020 at 7:12 PM Valentin
> > > > Kulichenko <
> > > > > > > > > > > >> valentin.kulichenko@gmail.com <mailto:
> > > > > > > > > valentin.kulichenko@gmail.com>>
> > > > > > > > > > wrote:
> > > > > > > > > > > >>
> > > > > > > > > > > >>> Hi Saikat,
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> That surely is a great idea. We will work
> > > > together
> > > > > > with
> > > > > > > > Denis
> > > > > > > > > on
> > > > > > > > > > setting
> > > > > > > > > > > >>> this up in the nearest future.
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> -Val
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> On Thu, Aug 6, 2020 at 10:21 AM Denis
> Magda <
> > > > > > > > dmagda@apache.org
> > > > > > > > > > <ma...@apache.org>> wrote:
> > > > > > > > > > > >>>
> > > > > > > > > > > >>>> Saikat,
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>> Fully support your idea on a virtual
> meetup!
> > > > Once
> > > > > > Val
> > > > > > > > > collects and
> > > > > > > > > > > >>> outlines
> > > > > > > > > > > >>>> the main changes with directions on wiki,
> > > we’ll
> > > > go
> > > > > > > > ahead and
> > > > > > > > > > schedule
> > > > > > > > > > > >> the
> > > > > > > > > > > >>>> meetup to talk things out in a bit more
> > > detail.
> > > > > > We’ll
> > > > > > > > use our
> > > > > > > > > new
> > > > > > > > > > > >> Virtual
> > > > > > > > > > > >>>> Ignite Meetup group for that inviting both
> > > > Ignite
> > > > > > > > > contributors and
> > > > > > > > > > > >>>> application developers.
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>> Denis
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>> On Thursday, August 6, 2020, Saikat
> Maitra <
> > > > > > > > > saikat.maitra@gmail.com
> > > > > > > > > > <ma...@gmail.com>>
> > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>>> Hi Valentin
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>> Thank you for sharing and starting the
> > > thread.
> > > > I
> > > > > am
> > > > > > > > thinking
> > > > > > > > > if it
> > > > > > > > > > > >> will
> > > > > > > > > > > >>>> be
> > > > > > > > > > > >>>>> a good idea to have a virtual meet setup
> to
> > > > > discuss
> > > > > > > on
> > > > > > > > the
> > > > > > > > > release
> > > > > > > > > > > >>>>> planning.
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>> It will help to learn more individual
> > > features
> > > > to
> > > > > > be
> > > > > > > > added
> > > > > > > > > and also
> > > > > > > > > > > >> to
> > > > > > > > > > > >>>>> understand about features that have been
> > > > > deprecated
> > > > > > > and
> > > > > > > > > scheduled
> > > > > > > > > > for
> > > > > > > > > > > >>>>> removal in Ignite 3.0 release. Also it
> will
> > > > help
> > > > > > > > community
> > > > > > > > > member
> > > > > > > > > > to
> > > > > > > > > > > >>>>> connect in real time and ask questions
> and
> > > > share
> > > > > > > > feedback.
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>> Regards,
> > > > > > > > > > > >>>>> Saikat
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya
> > > Kasnacheev
> > > > <
> > > > > > > > > > > >>>> ilya.kasnacheev@gmail.com <mailto:
> > > > > > > > ilya.kasnacheev@gmail.com>>
> > > > > > > > > > > >>>>> wrote:
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>>> Hello!
> > > > > > > > > > > >>>>>>
> > > > > > > > > > > >>>>>> I hope to see Apache Ignite release 3.0
> as
> > > API
> > > > > > > > trimming
> > > > > > > > > release.
> > > > > > > > > > > >> Let
> > > > > > > > > > > >>> us
> > > > > > > > > > > >>>>>> correct external and internal APIs for
> > which
> > > > we
> > > > > > have
> > > > > > > > better
> > > > > > > > > ideas
> > > > > > > > > > > >>> now,
> > > > > > > > > > > >>>> as
> > > > > > > > > > > >>>>>> well as remove old and deprecated code.
> > > > > > > > > > > >>>>>>
> > > > > > > > > > > >>>>>> We may also introduce new configuration
> > > > > mechanisms
> > > > > > > and
> > > > > > > > > user-facing
> > > > > > > > > > > >>> API
> > > > > > > > > > > >>>>>> (such as cache-less native SQL queries),
> > but
> > > > > this
> > > > > > we
> > > > > > > > could
> > > > > > > > > > > >> prototype
> > > > > > > > > > > >>>>> before
> > > > > > > > > > > >>>>>> starting the 3.0 task.
> > > > > > > > > > > >>>>>>
> > > > > > > > > > > >>>>>> I will advise against targeting large
> new
> > > > > features
> > > > > > > at
> > > > > > > > 3.0.
> > > > > > > > > They
> > > > > > > > > > can
> > > > > > > > > > > >>> be
> > > > > > > > > > > >>>>>> added in subsequent point releases,
> > whereas
> > > we
> > > > > > can't
> > > > > > > > really
> > > > > > > > > remove
> > > > > > > > > > > >> or
> > > > > > > > > > > >>>>>> remodel stuff in point releases.
> > > > > > > > > > > >>>>>>
> > > > > > > > > > > >>>>>> Regards,
> > > > > > > > > > > >>>>>> --
> > > > > > > > > > > >>>>>> Ilya Kasnacheev
> > > > > > > > > > > >>>>>>
> > > > > > > > > > > >>>>>>
> > > > > > > > > > > >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin
> > > > Kulichenko
> > > > > <
> > > > > > > > > > > >>>>>> valentin.kulichenko@gmail.com <mailto:
> > > > > > > > > > valentin.kulichenko@gmail.com>>:
> > > > > > > > > > > >>>>>>
> > > > > > > > > > > >>>>>>> Igniters,
> > > > > > > > > > > >>>>>>>
> > > > > > > > > > > >>>>>>> I would like to kick off a discussion
> > > > regarding
> > > > > > > > Ignite 3.0.
> > > > > > > > > > > >> Ignite
> > > > > > > > > > > >>>> 2.0
> > > > > > > > > > > >>>>>>> exists for more than 3 years now and
> > we've
> > > > > > already
> > > > > > > > > collected a
> > > > > > > > > > > >>>>>> significant
> > > > > > > > > > > >>>>>>> list [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://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> > > > > > > > > <
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> > > > > > > > > >
> > > > > > > > > > > >>>>> Apache+Ignite+3.0+Wishlist
> > > > > > > > > > > >>>>>>>
> > > > > > > > > > > >>>>>>> Regards,
> > > > > > > > > > > >>>>>>> Val
> > > > > > > > > > > >>>>>>>
> > > > > > > > > > > >>>>>>
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>> --
> > > > > > > > > > > >>>> -
> > > > > > > > > > > >>>> Denis
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
> <http://www.trimble.com/>
> Raymond Wilson
> Solution Architect, Civil Construction Software Systems (CCSS)
> 11 Birmingham Drive | Christchurch, New Zealand
> +64-21-2013317 Mobile
> raymond_wilson@trimble.com
>
> <
> https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch
> >
>
Re: Apache Ignite 3.0
Posted by Raymond Wilson <ra...@trimble.com>.
For what it is worth, we use messaging in Ignite to provide grid
notifications for various purposes. These might stimulate compute
operations in the message recipients, but they don't represent compute.
If messaging is removed, how would Ignite provide the ability for a node to
listen to events without the event sender being explicitly aware that the
listener does, or should, exist, to produce a compute projection to send
messages-as-compute-requests to?
On Wed, Sep 16, 2020 at 9:28 AM Kseniya Romanova <ro...@gmail.com>
wrote:
> Just wanted to submit a link to the video about some offered changes.
> @valentin.kulichenko@gmail.com <va...@gmail.com> please add
> it to the wiki page. I created timestamps in the description, so one can
> browse the presentation fast or link the particular section:
> https://youtu.be/zPuLJgUfLaM
> Thanks a lot for the presentation!
>
> вт, 18 авг. 2020 г. в 14:13, Ilya Kasnacheev <il...@gmail.com>:
>
> > Hello!
> >
> > Maybe we can implement messaging via compute? Share underlying code but
> > have a different API for convenience (maybe in extras).
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > вт, 18 авг. 2020 г. в 11:59, Pavel Tupitsyn <pt...@apache.org>:
> >
> > > Val,
> > >
> > > > Is see the ".NET Modernization for Ignite 3.0" item in the roadmap,
> but
> > > it
> > > > doesn't provide much detail. What are the actual changes in .NET that
> > you
> > > > propose for 3.0?
> > >
> > > I've updated the roadmap with a brief description.
> > > We want to move away from an old, long unsupported .NET version,
> > > and remove integrations with legacy technologies (old ASP.NET and EF).
> > >
> > > > As for the messaging, so far I haven't seen use cases that would
> > require
> > > > this API. Sometimes users attempt to use it for remote code
> invocation,
> > > but
> > > > compute is usually 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.
> > >
> > > Messaging can be more convenient, since it is pub-sub - 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
> > >
> > >
> > >
> > > On Tue, Aug 18, 2020 at 3:16 AM Saikat Maitra <saikat.maitra@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 Tupitsyn <
> ptupitsyn@apache.org>
> > > > wrote:
> > > >
> > > > > Saikat, yes, most definitely.
> > > > > This is mentioned in the wishlist under ".NET: Target .NET Standard
> > > 2.0,
> > > > > discontinue .NET 4.0 support".
> > > > > I'm already working towards this goal by making more code and tests
> > > work
> > > > > properly under .NET Core,
> > > > > so when the time for breaking changes comes, it will be simpler.
> > > > >
> > > > > On Sat, Aug 15, 2020 at 10:06 PM Saikat Maitra <
> > > saikat.maitra@gmail.com>
> > > > > 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
> > > > > > release?
> > > > > >
> > > > > >
> > > >
> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap
> > > > > >
> > > > > > Regards,
> > > > > > Saikat
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, Aug 14, 2020 at 10:04 AM Carbone, Adam <
> > > > > > Adam.Carbone@bottomline.com>
> > > > > > wrote:
> > > > > >
> > > > > > > If you want to make is simpler to have the components that you
> > > want,
> > > > > but
> > > > > > > have that be immutable at install time you could take an
> approach
> > > > > similar
> > > > > > > to the way spring does it with their initializer (
> > > > > > > https://start.spring.io/ ) as an example... Basically the
> > concept
> > > > > being
> > > > > > > something that produces a set of configurations that are used
> to
> > > > define
> > > > > > > what the environment looks like ( these could be k8s objects )
> > they
> > > > > could
> > > > > > > be spring-configuration objects? They could be something that
> you
> > > > > develop
> > > > > > > all upon ignite ( probably wouldn’t recommend this approach )
> > > there
> > > > > > seems
> > > > > > > to be plenty of these types of things already
> > > > > > >
> > > > > > > Example
> > > > > > > * https://spring.io/guides/gs/centralized-configuration
> > > > > > > *
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cocoon.apache.org/subprojects/configuration/spring-configurator/index.html
> > > > > > >
> > > > > > > And I'm by no means saying to use spring these are just
> examples
> > > > that I
> > > > > > > came across
> > > > > > >
> > > > > > > I'm thinking the outcome needs to be a platform config of
> source
> > (
> > > > that
> > > > > > > can be checked in for those doing gitops ) and maybe ends up
> as a
> > > > > config
> > > > > > > map for those doing k8s, and some other fashion for those doing
> > > > > something
> > > > > > > else.
> > > > > > >
> > > > > > > Honestly I am not deep enough into the internals of ignite to
> > know
> > > > how
> > > > > > > this might work for the platform, was more describing what I'm
> > > seeing
> > > > > > from
> > > > > > > a bigger picture trend
> > > > > > >
> > > > > > > Regards
> > > > > > >
> > > > > > > Adam Carbone | Director of Innovation – Intelligent Platform
> > Team |
> > > > > > > Bottomline Technologies
> > > > > > > Office: 603-501-6446 | Mobile: 603-570-8418
> > > > > > > www.bottomline.com
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 8/13/20, 7:55 PM, "Valentin Kulichenko" <
> > > > > > valentin.kulichenko@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > Hi Ilya,
> > > > > > >
> > > > > > > Can you please describe your vision of how it should work?
> > > > > > >
> > > > > > > Let's say, I want to set up a cluster of several standalone
> > > > server
> > > > > > > nodes
> > > > > > > with a couple of optional modules enabled. What are my
> steps?
> > > > > > >
> > > > > > > -Val
> > > > > > >
> > > > > > > On Thu, Aug 13, 2020 at 6:03 AM Carbone, Adam <
> > > > > > > Adam.Carbone@bottomline.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Good Morning from the EastCoast
> > > > > > > >
> > > > > > > > I have to agree that the larger industry is tending
> towards
> > > > > > > immutability,
> > > > > > > > and that you build once and test, then you
> promote/migrate
> > > that
> > > > > > > immutable
> > > > > > > > binary object, be is a library or a docker image etc...
> > > however
> > > > > > > there are
> > > > > > > > still patterns that allow you to determine at install/or
> > > > > deployment
> > > > > > > time (
> > > > > > > > helm as an example, you choose based on your values what
> > the
> > > > > > package
> > > > > > > > installs/provides ) It just isn't decided at runtime but
> > > > install
> > > > > > and
> > > > > > > often
> > > > > > > > in a gitops type world that is determined by
> configuration
> > as
> > > > > code.
> > > > > > > I think
> > > > > > > > run time is difficult to manage especially in our
> > > increasingly
> > > > > > > > containerized world.
> > > > > > > >
> > > > > > > > Regards.
> > > > > > > >
> > > > > > > > Adam Carbone | Director of Innovation – Intelligent
> > Platform
> > > > > Team |
> > > > > > > > Bottomline Technologies
> > > > > > > > Office: 603-501-6446 | Mobile: 603-570-8418
> > > > > > > > www.bottomline.com
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 8/13/20, 8:01 AM, "Ilya Kasnacheev" <
> > > > > ilya.kasnacheev@gmail.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hello!
> > > > > > > >
> > > > > > > > On the contrary, I would suggest that apache2 way was
> > > > > outdated
> > > > > > > even at
> > > > > > > > times when apache was all rage.
> > > > > > > >
> > > > > > > > Now the nginx approach is prevalent: on devops phase,
> > > > > assemble
> > > > > > a
> > > > > > > custom
> > > > > > > > bundle with all plugins included, store it somewhere,
> > and
> > > > > ship
> > > > > > > it to
> > > > > > > > production as a whole to remove any on-the-fly
> > > uncertainty
> > > > > from
> > > > > > > > production.
> > > > > > > >
> > > > > > > > This is what docker does, but also maven, which
> > downloads
> > > > > > > dependencies
> > > > > > > > during build. You do not need to download anything in
> > > > > runtime,
> > > > > > > except
> > > > > > > > for
> > > > > > > > experimental deployments. You need to be all set
> before
> > > > > runtime
> > > > > > > starts.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > --
> > > > > > > > Ilya Kasnacheev
> > > > > > > >
> > > > > > > >
> > > > > > > > ср, 12 авг. 2020 г. в 09:48, Petr Ivanov <
> > > > > mr.weider@gmail.com
> > > > > > >:
> > > > > > > >
> > > > > > > > > Hi, Val.
> > > > > > > > >
> > > > > > > > > > On 12 Aug 2020, at 01:31, Valentin Kulichenko <
> > > > > > > > > valentin.kulichenko@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Petr,
> > > > > > > > > >
> > > > > > > > > > I agree -- we should better modularize the
> > platform.
> > > > The
> > > > > > > current
> > > > > > > > way if
> > > > > > > > > very error-prone, especially during upgrades -- any
> > > > changes
> > > > > > > made
> > > > > > > > within
> > > > > > > > > IGNITE_HOME (configs, scripts, modules, etc.) must
> be
> > > > > merged
> > > > > > > with a
> > > > > > > > new
> > > > > > > > > version of the package. There is no standard way of
> > > doing
> > > > > > this.
> > > > > > > > > >
> > > > > > > > > > However, I'm a bit concerned with your suggestion
> > > > > regarding
> > > > > > > custom
> > > > > > > > > dependency management. Can you please elaborate on
> > how
> > > > you
> > > > > > > think it
> > > > > > > > should
> > > > > > > > > work? Are there tools we can reuse for this
> purpose?
> > I
> > > > > would
> > > > > > > try to
> > > > > > > > avoid
> > > > > > > > > reinventing the wheel.
> > > > > > > > >
> > > > > > > > > I see it as a a2enmod | 2dismod analog of Apache2.
> > > > > > > > >
> > > > > > > > > We build and store Apache Ignite and its modules as
> > > > > separate
> > > > > > > binaries
> > > > > > > > > (binary per module) then use custom script that
> will
> > > know
> > > > > > > where to
> > > > > > > > download
> > > > > > > > > necessary module. Or possibly use modified
> ignite.sh
> > to
> > > > > > specify
> > > > > > > > required
> > > > > > > > > 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.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > -Val
> > > > > > > > > >
> > > > > > > > > > On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov <
> > > > > > > mr.weider@gmail.com
> > > > > > > > > <ma...@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
> > > > > > > > starting
> > > > > > > > > Ignite and all other modules and parts of the
> project
> > > > > > > (benchmarks,
> > > > > > > > > examples, etc.) packed in their own binary which
> can
> > be
> > > > > added
> > > > > > > via
> > > > > > > > custom
> > > > > > > > > dependency management tool (i.e. modules.sh)
> > > > > > > > > > — same distribution for RPM and DEB packages but
> > > with
> > > > > > > modules
> > > > > > > > packed as
> > > > > > > > > separate ones (PHP for example)
> > > > > > > > > > — separate thin client release cycle with custom
> > > > > > versioning
> > > > > > > > > > Possibly, we can we add additional section to the
> > > > > document
> > > > > > > you
> > > > > > > > > introduced for this part.
> > > > > > > > > >
> > > > > > > > > > Also, it seems that full JDK11 support (including
> > > > > building)
> > > > > > > would
> > > > > > > > be a
> > > > > > > > > huge milestone and a sign of healthy modern project
> > > that
> > > > > > tends
> > > > > > > to be
> > > > > > > > on the
> > > > > > > > > verge of mainstream technologies and not the
> > stockpile
> > > of
> > > > > > > legacy
> > > > > > > > leftovers
> > > > > > > > > (fully support Iliya in removing all that was
> > > deprecated
> > > > > > and/or
> > > > > > > > marked as
> > > > > > > > > unused anymore).
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > On 8 Aug 2020, at 02:00, Valentin Kulichenko <
> > > > > > > > > valentin.kulichenko@gmail.com <mailto:
> > > > > > > valentin.kulichenko@gmail.com
> > > > > > > > >>
> > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Igniters,
> > > > > > > > > > >
> > > > > > > > > > > I've created the page:
> > > > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> > > > > > > > <
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 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 the consensus on the
> > > > proposed
> > > > > > > changes,
> > > > > > > > I will
> > > > > > > > > > > start creating tickets in Jira and a more
> > detailed
> > > > > plan.
> > > > > > > > > > >
> > > > > > > > > > > -Val
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <
> > > > > > > > saikat.maitra@gmail.com
> > > > > > > > > <ma...@gmail.com>>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > >> Hi Denis, Val
> > > > > > > > > > >>
> > > > > > > > > > >> Thank you for your reply and really appreciate
> > it.
> > > > It
> > > > > > > will be
> > > > > > > > very
> > > > > > > > > cool to
> > > > > > > > > > >> be able to connect and plan release together
> and
> > > > learn
> > > > > > > more
> > > > > > > > about
> > > > > > > > > Ignite in
> > > > > > > > > > >> the process :)
> > > > > > > > > > >>
> > > > > > > > > > >> Regards
> > > > > > > > > > >> Saikat
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >> On Thu, Aug 6, 2020 at 7:12 PM Valentin
> > > Kulichenko <
> > > > > > > > > > >> valentin.kulichenko@gmail.com <mailto:
> > > > > > > > valentin.kulichenko@gmail.com>>
> > > > > > > > > wrote:
> > > > > > > > > > >>
> > > > > > > > > > >>> Hi Saikat,
> > > > > > > > > > >>>
> > > > > > > > > > >>> That surely is a great idea. We will work
> > > together
> > > > > with
> > > > > > > Denis
> > > > > > > > on
> > > > > > > > > setting
> > > > > > > > > > >>> this up in the nearest future.
> > > > > > > > > > >>>
> > > > > > > > > > >>> -Val
> > > > > > > > > > >>>
> > > > > > > > > > >>> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <
> > > > > > > dmagda@apache.org
> > > > > > > > > <ma...@apache.org>> wrote:
> > > > > > > > > > >>>
> > > > > > > > > > >>>> Saikat,
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Fully support your idea on a virtual meetup!
> > > Once
> > > > > Val
> > > > > > > > collects and
> > > > > > > > > > >>> outlines
> > > > > > > > > > >>>> the main changes with directions on wiki,
> > we’ll
> > > go
> > > > > > > ahead and
> > > > > > > > > schedule
> > > > > > > > > > >> the
> > > > > > > > > > >>>> meetup to talk things out in a bit more
> > detail.
> > > > > We’ll
> > > > > > > use our
> > > > > > > > new
> > > > > > > > > > >> Virtual
> > > > > > > > > > >>>> Ignite Meetup group for that inviting both
> > > Ignite
> > > > > > > > contributors and
> > > > > > > > > > >>>> application developers.
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Denis
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> On Thursday, August 6, 2020, Saikat Maitra <
> > > > > > > > saikat.maitra@gmail.com
> > > > > > > > > <ma...@gmail.com>>
> > > > > > > > > > >>>> wrote:
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>> Hi Valentin
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> Thank you for sharing and starting the
> > thread.
> > > I
> > > > am
> > > > > > > thinking
> > > > > > > > if it
> > > > > > > > > > >> will
> > > > > > > > > > >>>> be
> > > > > > > > > > >>>>> a good idea to have a virtual meet setup to
> > > > discuss
> > > > > > on
> > > > > > > the
> > > > > > > > release
> > > > > > > > > > >>>>> planning.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> It will help to learn more individual
> > features
> > > to
> > > > > be
> > > > > > > added
> > > > > > > > and also
> > > > > > > > > > >> to
> > > > > > > > > > >>>>> understand about features that have been
> > > > deprecated
> > > > > > and
> > > > > > > > scheduled
> > > > > > > > > for
> > > > > > > > > > >>>>> removal in Ignite 3.0 release. Also it will
> > > help
> > > > > > > community
> > > > > > > > member
> > > > > > > > > to
> > > > > > > > > > >>>>> connect in real time and ask questions and
> > > share
> > > > > > > feedback.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> Regards,
> > > > > > > > > > >>>>> Saikat
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya
> > Kasnacheev
> > > <
> > > > > > > > > > >>>> ilya.kasnacheev@gmail.com <mailto:
> > > > > > > ilya.kasnacheev@gmail.com>>
> > > > > > > > > > >>>>> wrote:
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>> Hello!
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>> I hope to see Apache Ignite release 3.0 as
> > API
> > > > > > > trimming
> > > > > > > > release.
> > > > > > > > > > >> Let
> > > > > > > > > > >>> us
> > > > > > > > > > >>>>>> correct external and internal APIs for
> which
> > > we
> > > > > have
> > > > > > > better
> > > > > > > > ideas
> > > > > > > > > > >>> now,
> > > > > > > > > > >>>> as
> > > > > > > > > > >>>>>> well as remove old and deprecated code.
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>> We may also introduce new configuration
> > > > mechanisms
> > > > > > and
> > > > > > > > user-facing
> > > > > > > > > > >>> API
> > > > > > > > > > >>>>>> (such as cache-less native SQL queries),
> but
> > > > this
> > > > > we
> > > > > > > could
> > > > > > > > > > >> prototype
> > > > > > > > > > >>>>> before
> > > > > > > > > > >>>>>> starting the 3.0 task.
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>> I will advise against targeting large new
> > > > features
> > > > > > at
> > > > > > > 3.0.
> > > > > > > > They
> > > > > > > > > can
> > > > > > > > > > >>> be
> > > > > > > > > > >>>>>> added in subsequent point releases,
> whereas
> > we
> > > > > can't
> > > > > > > really
> > > > > > > > remove
> > > > > > > > > > >> or
> > > > > > > > > > >>>>>> remodel stuff in point releases.
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>> Regards,
> > > > > > > > > > >>>>>> --
> > > > > > > > > > >>>>>> Ilya Kasnacheev
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin
> > > Kulichenko
> > > > <
> > > > > > > > > > >>>>>> valentin.kulichenko@gmail.com <mailto:
> > > > > > > > > valentin.kulichenko@gmail.com>>:
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>>> Igniters,
> > > > > > > > > > >>>>>>>
> > > > > > > > > > >>>>>>> I would like to kick off a discussion
> > > regarding
> > > > > > > Ignite 3.0.
> > > > > > > > > > >> Ignite
> > > > > > > > > > >>>> 2.0
> > > > > > > > > > >>>>>>> exists for more than 3 years now and
> we've
> > > > > already
> > > > > > > > collected a
> > > > > > > > > > >>>>>> significant
> > > > > > > > > > >>>>>>> list [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://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> > > > > > > > <
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> > > > > > > > >
> > > > > > > > > > >>>>> Apache+Ignite+3.0+Wishlist
> > > > > > > > > > >>>>>>>
> > > > > > > > > > >>>>>>> Regards,
> > > > > > > > > > >>>>>>> Val
> > > > > > > > > > >>>>>>>
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> --
> > > > > > > > > > >>>> -
> > > > > > > > > > >>>> Denis
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
--
<http://www.trimble.com/>
Raymond Wilson
Solution Architect, Civil Construction Software Systems (CCSS)
11 Birmingham Drive | Christchurch, New Zealand
+64-21-2013317 Mobile
raymond_wilson@trimble.com
<https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch>
Re: Apache Ignite 3.0
Posted by Kseniya Romanova <ro...@gmail.com>.
Just wanted to submit a link to the video about some offered changes.
@valentin.kulichenko@gmail.com <va...@gmail.com> please add
it to the wiki page. I created timestamps in the description, so one can
browse the presentation fast or link the particular section:
https://youtu.be/zPuLJgUfLaM
Thanks a lot for the presentation!
вт, 18 авг. 2020 г. в 14:13, Ilya Kasnacheev <il...@gmail.com>:
> Hello!
>
> Maybe we can implement messaging via compute? Share underlying code but
> have a different API for convenience (maybe in extras).
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вт, 18 авг. 2020 г. в 11:59, Pavel Tupitsyn <pt...@apache.org>:
>
> > Val,
> >
> > > Is see the ".NET Modernization for Ignite 3.0" item in the roadmap, but
> > it
> > > doesn't provide much detail. What are the actual changes in .NET that
> you
> > > propose for 3.0?
> >
> > I've updated the roadmap with a brief description.
> > We want to move away from an old, long unsupported .NET version,
> > and remove integrations with legacy technologies (old ASP.NET and EF).
> >
> > > As for the messaging, so far I haven't seen use cases that would
> require
> > > this API. Sometimes users attempt to use it for remote code invocation,
> > but
> > > compute is usually 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.
> >
> > Messaging can be more convenient, since it is pub-sub - 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
> >
> >
> >
> > On Tue, Aug 18, 2020 at 3:16 AM Saikat Maitra <sa...@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 Tupitsyn <pt...@apache.org>
> > > wrote:
> > >
> > > > Saikat, yes, most definitely.
> > > > This is mentioned in the wishlist under ".NET: Target .NET Standard
> > 2.0,
> > > > discontinue .NET 4.0 support".
> > > > I'm already working towards this goal by making more code and tests
> > work
> > > > properly under .NET Core,
> > > > so when the time for breaking changes comes, it will be simpler.
> > > >
> > > > On Sat, Aug 15, 2020 at 10:06 PM Saikat Maitra <
> > saikat.maitra@gmail.com>
> > > > 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
> > > > > release?
> > > > >
> > > > >
> > >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap
> > > > >
> > > > > Regards,
> > > > > Saikat
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Aug 14, 2020 at 10:04 AM Carbone, Adam <
> > > > > Adam.Carbone@bottomline.com>
> > > > > wrote:
> > > > >
> > > > > > If you want to make is simpler to have the components that you
> > want,
> > > > but
> > > > > > have that be immutable at install time you could take an approach
> > > > similar
> > > > > > to the way spring does it with their initializer (
> > > > > > https://start.spring.io/ ) as an example... Basically the
> concept
> > > > being
> > > > > > something that produces a set of configurations that are used to
> > > define
> > > > > > what the environment looks like ( these could be k8s objects )
> they
> > > > could
> > > > > > be spring-configuration objects? They could be something that you
> > > > develop
> > > > > > all upon ignite ( probably wouldn’t recommend this approach )
> > there
> > > > > seems
> > > > > > to be plenty of these types of things already
> > > > > >
> > > > > > Example
> > > > > > * https://spring.io/guides/gs/centralized-configuration
> > > > > > *
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cocoon.apache.org/subprojects/configuration/spring-configurator/index.html
> > > > > >
> > > > > > And I'm by no means saying to use spring these are just examples
> > > that I
> > > > > > came across
> > > > > >
> > > > > > I'm thinking the outcome needs to be a platform config of source
> (
> > > that
> > > > > > can be checked in for those doing gitops ) and maybe ends up as a
> > > > config
> > > > > > map for those doing k8s, and some other fashion for those doing
> > > > something
> > > > > > else.
> > > > > >
> > > > > > Honestly I am not deep enough into the internals of ignite to
> know
> > > how
> > > > > > this might work for the platform, was more describing what I'm
> > seeing
> > > > > from
> > > > > > a bigger picture trend
> > > > > >
> > > > > > Regards
> > > > > >
> > > > > > Adam Carbone | Director of Innovation – Intelligent Platform
> Team |
> > > > > > Bottomline Technologies
> > > > > > Office: 603-501-6446 | Mobile: 603-570-8418
> > > > > > www.bottomline.com
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 8/13/20, 7:55 PM, "Valentin Kulichenko" <
> > > > > valentin.kulichenko@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > Hi Ilya,
> > > > > >
> > > > > > Can you please describe your vision of how it should work?
> > > > > >
> > > > > > Let's say, I want to set up a cluster of several standalone
> > > server
> > > > > > nodes
> > > > > > with a couple of optional modules enabled. What are my steps?
> > > > > >
> > > > > > -Val
> > > > > >
> > > > > > On Thu, Aug 13, 2020 at 6:03 AM Carbone, Adam <
> > > > > > Adam.Carbone@bottomline.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Good Morning from the EastCoast
> > > > > > >
> > > > > > > I have to agree that the larger industry is tending towards
> > > > > > immutability,
> > > > > > > and that you build once and test, then you promote/migrate
> > that
> > > > > > immutable
> > > > > > > binary object, be is a library or a docker image etc...
> > however
> > > > > > there are
> > > > > > > still patterns that allow you to determine at install/or
> > > > deployment
> > > > > > time (
> > > > > > > helm as an example, you choose based on your values what
> the
> > > > > package
> > > > > > > installs/provides ) It just isn't decided at runtime but
> > > install
> > > > > and
> > > > > > often
> > > > > > > in a gitops type world that is determined by configuration
> as
> > > > code.
> > > > > > I think
> > > > > > > run time is difficult to manage especially in our
> > increasingly
> > > > > > > containerized world.
> > > > > > >
> > > > > > > Regards.
> > > > > > >
> > > > > > > Adam Carbone | Director of Innovation – Intelligent
> Platform
> > > > Team |
> > > > > > > Bottomline Technologies
> > > > > > > Office: 603-501-6446 | Mobile: 603-570-8418
> > > > > > > www.bottomline.com
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 8/13/20, 8:01 AM, "Ilya Kasnacheev" <
> > > > ilya.kasnacheev@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > Hello!
> > > > > > >
> > > > > > > On the contrary, I would suggest that apache2 way was
> > > > outdated
> > > > > > even at
> > > > > > > times when apache was all rage.
> > > > > > >
> > > > > > > Now the nginx approach is prevalent: on devops phase,
> > > > assemble
> > > > > a
> > > > > > custom
> > > > > > > bundle with all plugins included, store it somewhere,
> and
> > > > ship
> > > > > > it to
> > > > > > > production as a whole to remove any on-the-fly
> > uncertainty
> > > > from
> > > > > > > production.
> > > > > > >
> > > > > > > This is what docker does, but also maven, which
> downloads
> > > > > > dependencies
> > > > > > > during build. You do not need to download anything in
> > > > runtime,
> > > > > > except
> > > > > > > for
> > > > > > > experimental deployments. You need to be all set before
> > > > runtime
> > > > > > starts.
> > > > > > >
> > > > > > > Regards,
> > > > > > > --
> > > > > > > Ilya Kasnacheev
> > > > > > >
> > > > > > >
> > > > > > > ср, 12 авг. 2020 г. в 09:48, Petr Ivanov <
> > > > mr.weider@gmail.com
> > > > > >:
> > > > > > >
> > > > > > > > Hi, Val.
> > > > > > > >
> > > > > > > > > On 12 Aug 2020, at 01:31, Valentin Kulichenko <
> > > > > > > > valentin.kulichenko@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Hi Petr,
> > > > > > > > >
> > > > > > > > > I agree -- we should better modularize the
> platform.
> > > The
> > > > > > current
> > > > > > > way if
> > > > > > > > very error-prone, especially during upgrades -- any
> > > changes
> > > > > > made
> > > > > > > within
> > > > > > > > IGNITE_HOME (configs, scripts, modules, etc.) must be
> > > > merged
> > > > > > with a
> > > > > > > new
> > > > > > > > version of the package. There is no standard way of
> > doing
> > > > > this.
> > > > > > > > >
> > > > > > > > > However, I'm a bit concerned with your suggestion
> > > > regarding
> > > > > > custom
> > > > > > > > dependency management. Can you please elaborate on
> how
> > > you
> > > > > > think it
> > > > > > > should
> > > > > > > > work? Are there tools we can reuse for this purpose?
> I
> > > > would
> > > > > > try to
> > > > > > > avoid
> > > > > > > > reinventing the wheel.
> > > > > > > >
> > > > > > > > I see it as a a2enmod | 2dismod analog of Apache2.
> > > > > > > >
> > > > > > > > We build and store Apache Ignite and its modules as
> > > > separate
> > > > > > binaries
> > > > > > > > (binary per module) then use custom script that will
> > know
> > > > > > where to
> > > > > > > download
> > > > > > > > necessary module. Or possibly use modified ignite.sh
> to
> > > > > specify
> > > > > > > required
> > > > > > > > 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.
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > -Val
> > > > > > > > >
> > > > > > > > > On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov <
> > > > > > mr.weider@gmail.com
> > > > > > > > <ma...@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
> > > > > > > starting
> > > > > > > > Ignite and all other modules and parts of the project
> > > > > > (benchmarks,
> > > > > > > > examples, etc.) packed in their own binary which can
> be
> > > > added
> > > > > > via
> > > > > > > custom
> > > > > > > > dependency management tool (i.e. modules.sh)
> > > > > > > > > — same distribution for RPM and DEB packages but
> > with
> > > > > > modules
> > > > > > > packed as
> > > > > > > > separate ones (PHP for example)
> > > > > > > > > — separate thin client release cycle with custom
> > > > > versioning
> > > > > > > > > Possibly, we can we add additional section to the
> > > > document
> > > > > > you
> > > > > > > > introduced for this part.
> > > > > > > > >
> > > > > > > > > Also, it seems that full JDK11 support (including
> > > > building)
> > > > > > would
> > > > > > > be a
> > > > > > > > huge milestone and a sign of healthy modern project
> > that
> > > > > tends
> > > > > > to be
> > > > > > > on the
> > > > > > > > verge of mainstream technologies and not the
> stockpile
> > of
> > > > > > legacy
> > > > > > > leftovers
> > > > > > > > (fully support Iliya in removing all that was
> > deprecated
> > > > > and/or
> > > > > > > marked as
> > > > > > > > unused anymore).
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > On 8 Aug 2020, at 02:00, Valentin Kulichenko <
> > > > > > > > valentin.kulichenko@gmail.com <mailto:
> > > > > > valentin.kulichenko@gmail.com
> > > > > > > >>
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Igniters,
> > > > > > > > > >
> > > > > > > > > > I've created the page:
> > > > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> > > > > > > <
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 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 the consensus on the
> > > proposed
> > > > > > changes,
> > > > > > > I will
> > > > > > > > > > start creating tickets in Jira and a more
> detailed
> > > > plan.
> > > > > > > > > >
> > > > > > > > > > -Val
> > > > > > > > > >
> > > > > > > > > > On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <
> > > > > > > saikat.maitra@gmail.com
> > > > > > > > <ma...@gmail.com>>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > >> Hi Denis, Val
> > > > > > > > > >>
> > > > > > > > > >> Thank you for your reply and really appreciate
> it.
> > > It
> > > > > > will be
> > > > > > > very
> > > > > > > > cool to
> > > > > > > > > >> be able to connect and plan release together and
> > > learn
> > > > > > more
> > > > > > > about
> > > > > > > > Ignite in
> > > > > > > > > >> the process :)
> > > > > > > > > >>
> > > > > > > > > >> Regards
> > > > > > > > > >> Saikat
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >> On Thu, Aug 6, 2020 at 7:12 PM Valentin
> > Kulichenko <
> > > > > > > > > >> valentin.kulichenko@gmail.com <mailto:
> > > > > > > valentin.kulichenko@gmail.com>>
> > > > > > > > wrote:
> > > > > > > > > >>
> > > > > > > > > >>> Hi Saikat,
> > > > > > > > > >>>
> > > > > > > > > >>> That surely is a great idea. We will work
> > together
> > > > with
> > > > > > Denis
> > > > > > > on
> > > > > > > > setting
> > > > > > > > > >>> this up in the nearest future.
> > > > > > > > > >>>
> > > > > > > > > >>> -Val
> > > > > > > > > >>>
> > > > > > > > > >>> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <
> > > > > > dmagda@apache.org
> > > > > > > > <ma...@apache.org>> wrote:
> > > > > > > > > >>>
> > > > > > > > > >>>> Saikat,
> > > > > > > > > >>>>
> > > > > > > > > >>>> Fully support your idea on a virtual meetup!
> > Once
> > > > Val
> > > > > > > collects and
> > > > > > > > > >>> outlines
> > > > > > > > > >>>> the main changes with directions on wiki,
> we’ll
> > go
> > > > > > ahead and
> > > > > > > > schedule
> > > > > > > > > >> the
> > > > > > > > > >>>> meetup to talk things out in a bit more
> detail.
> > > > We’ll
> > > > > > use our
> > > > > > > new
> > > > > > > > > >> Virtual
> > > > > > > > > >>>> Ignite Meetup group for that inviting both
> > Ignite
> > > > > > > contributors and
> > > > > > > > > >>>> application developers.
> > > > > > > > > >>>>
> > > > > > > > > >>>> Denis
> > > > > > > > > >>>>
> > > > > > > > > >>>> On Thursday, August 6, 2020, Saikat Maitra <
> > > > > > > saikat.maitra@gmail.com
> > > > > > > > <ma...@gmail.com>>
> > > > > > > > > >>>> wrote:
> > > > > > > > > >>>>
> > > > > > > > > >>>>> Hi Valentin
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> Thank you for sharing and starting the
> thread.
> > I
> > > am
> > > > > > thinking
> > > > > > > if it
> > > > > > > > > >> will
> > > > > > > > > >>>> be
> > > > > > > > > >>>>> a good idea to have a virtual meet setup to
> > > discuss
> > > > > on
> > > > > > the
> > > > > > > release
> > > > > > > > > >>>>> planning.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> It will help to learn more individual
> features
> > to
> > > > be
> > > > > > added
> > > > > > > and also
> > > > > > > > > >> to
> > > > > > > > > >>>>> understand about features that have been
> > > deprecated
> > > > > and
> > > > > > > scheduled
> > > > > > > > for
> > > > > > > > > >>>>> removal in Ignite 3.0 release. Also it will
> > help
> > > > > > community
> > > > > > > member
> > > > > > > > to
> > > > > > > > > >>>>> connect in real time and ask questions and
> > share
> > > > > > feedback.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> Regards,
> > > > > > > > > >>>>> Saikat
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya
> Kasnacheev
> > <
> > > > > > > > > >>>> ilya.kasnacheev@gmail.com <mailto:
> > > > > > ilya.kasnacheev@gmail.com>>
> > > > > > > > > >>>>> wrote:
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>> Hello!
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>> I hope to see Apache Ignite release 3.0 as
> API
> > > > > > trimming
> > > > > > > release.
> > > > > > > > > >> Let
> > > > > > > > > >>> us
> > > > > > > > > >>>>>> correct external and internal APIs for which
> > we
> > > > have
> > > > > > better
> > > > > > > ideas
> > > > > > > > > >>> now,
> > > > > > > > > >>>> as
> > > > > > > > > >>>>>> well as remove old and deprecated code.
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>> We may also introduce new configuration
> > > mechanisms
> > > > > and
> > > > > > > user-facing
> > > > > > > > > >>> API
> > > > > > > > > >>>>>> (such as cache-less native SQL queries), but
> > > this
> > > > we
> > > > > > could
> > > > > > > > > >> prototype
> > > > > > > > > >>>>> before
> > > > > > > > > >>>>>> starting the 3.0 task.
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>> I will advise against targeting large new
> > > features
> > > > > at
> > > > > > 3.0.
> > > > > > > They
> > > > > > > > can
> > > > > > > > > >>> be
> > > > > > > > > >>>>>> added in subsequent point releases, whereas
> we
> > > > can't
> > > > > > really
> > > > > > > remove
> > > > > > > > > >> or
> > > > > > > > > >>>>>> remodel stuff in point releases.
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>> Regards,
> > > > > > > > > >>>>>> --
> > > > > > > > > >>>>>> Ilya Kasnacheev
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin
> > Kulichenko
> > > <
> > > > > > > > > >>>>>> valentin.kulichenko@gmail.com <mailto:
> > > > > > > > valentin.kulichenko@gmail.com>>:
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>>> Igniters,
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>> I would like to kick off a discussion
> > regarding
> > > > > > Ignite 3.0.
> > > > > > > > > >> Ignite
> > > > > > > > > >>>> 2.0
> > > > > > > > > >>>>>>> exists for more than 3 years now and we've
> > > > already
> > > > > > > collected a
> > > > > > > > > >>>>>> significant
> > > > > > > > > >>>>>>> list [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://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> > > > > > > <
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> > > > > > > >
> > > > > > > > > >>>>> Apache+Ignite+3.0+Wishlist
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>> Regards,
> > > > > > > > > >>>>>>> Val
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>> --
> > > > > > > > > >>>> -
> > > > > > > > > >>>> Denis
> > > > > > > > > >>>>
> > > > > > > > > >>>
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Apache Ignite 3.0
Posted by Ilya Kasnacheev <il...@gmail.com>.
Hello!
Maybe we can implement messaging via compute? Share underlying code but
have a different API for convenience (maybe in extras).
Regards,
--
Ilya Kasnacheev
вт, 18 авг. 2020 г. в 11:59, Pavel Tupitsyn <pt...@apache.org>:
> Val,
>
> > Is see the ".NET Modernization for Ignite 3.0" item in the roadmap, but
> it
> > doesn't provide much detail. What are the actual changes in .NET that you
> > propose for 3.0?
>
> I've updated the roadmap with a brief description.
> We want to move away from an old, long unsupported .NET version,
> and remove integrations with legacy technologies (old ASP.NET and EF).
>
> > As for the messaging, so far I haven't seen use cases that would require
> > this API. Sometimes users attempt to use it for remote code invocation,
> but
> > compute is usually 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.
>
> Messaging can be more convenient, since it is pub-sub - 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
>
>
>
> On Tue, Aug 18, 2020 at 3:16 AM Saikat Maitra <sa...@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 Tupitsyn <pt...@apache.org>
> > wrote:
> >
> > > Saikat, yes, most definitely.
> > > This is mentioned in the wishlist under ".NET: Target .NET Standard
> 2.0,
> > > discontinue .NET 4.0 support".
> > > I'm already working towards this goal by making more code and tests
> work
> > > properly under .NET Core,
> > > so when the time for breaking changes comes, it will be simpler.
> > >
> > > On Sat, Aug 15, 2020 at 10:06 PM Saikat Maitra <
> saikat.maitra@gmail.com>
> > > 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
> > > > release?
> > > >
> > > >
> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap
> > > >
> > > > Regards,
> > > > Saikat
> > > >
> > > >
> > > >
> > > > On Fri, Aug 14, 2020 at 10:04 AM Carbone, Adam <
> > > > Adam.Carbone@bottomline.com>
> > > > wrote:
> > > >
> > > > > If you want to make is simpler to have the components that you
> want,
> > > but
> > > > > have that be immutable at install time you could take an approach
> > > similar
> > > > > to the way spring does it with their initializer (
> > > > > https://start.spring.io/ ) as an example... Basically the concept
> > > being
> > > > > something that produces a set of configurations that are used to
> > define
> > > > > what the environment looks like ( these could be k8s objects ) they
> > > could
> > > > > be spring-configuration objects? They could be something that you
> > > develop
> > > > > all upon ignite ( probably wouldn’t recommend this approach )
> there
> > > > seems
> > > > > to be plenty of these types of things already
> > > > >
> > > > > Example
> > > > > * https://spring.io/guides/gs/centralized-configuration
> > > > > *
> > > > >
> > > >
> > >
> >
> https://cocoon.apache.org/subprojects/configuration/spring-configurator/index.html
> > > > >
> > > > > And I'm by no means saying to use spring these are just examples
> > that I
> > > > > came across
> > > > >
> > > > > I'm thinking the outcome needs to be a platform config of source (
> > that
> > > > > can be checked in for those doing gitops ) and maybe ends up as a
> > > config
> > > > > map for those doing k8s, and some other fashion for those doing
> > > something
> > > > > else.
> > > > >
> > > > > Honestly I am not deep enough into the internals of ignite to know
> > how
> > > > > this might work for the platform, was more describing what I'm
> seeing
> > > > from
> > > > > a bigger picture trend
> > > > >
> > > > > Regards
> > > > >
> > > > > Adam Carbone | Director of Innovation – Intelligent Platform Team |
> > > > > Bottomline Technologies
> > > > > Office: 603-501-6446 | Mobile: 603-570-8418
> > > > > www.bottomline.com
> > > > >
> > > > >
> > > > >
> > > > > On 8/13/20, 7:55 PM, "Valentin Kulichenko" <
> > > > valentin.kulichenko@gmail.com>
> > > > > wrote:
> > > > >
> > > > > Hi Ilya,
> > > > >
> > > > > Can you please describe your vision of how it should work?
> > > > >
> > > > > Let's say, I want to set up a cluster of several standalone
> > server
> > > > > nodes
> > > > > with a couple of optional modules enabled. What are my steps?
> > > > >
> > > > > -Val
> > > > >
> > > > > On Thu, Aug 13, 2020 at 6:03 AM Carbone, Adam <
> > > > > Adam.Carbone@bottomline.com>
> > > > > wrote:
> > > > >
> > > > > > Good Morning from the EastCoast
> > > > > >
> > > > > > I have to agree that the larger industry is tending towards
> > > > > immutability,
> > > > > > and that you build once and test, then you promote/migrate
> that
> > > > > immutable
> > > > > > binary object, be is a library or a docker image etc...
> however
> > > > > there are
> > > > > > still patterns that allow you to determine at install/or
> > > deployment
> > > > > time (
> > > > > > helm as an example, you choose based on your values what the
> > > > package
> > > > > > installs/provides ) It just isn't decided at runtime but
> > install
> > > > and
> > > > > often
> > > > > > in a gitops type world that is determined by configuration as
> > > code.
> > > > > I think
> > > > > > run time is difficult to manage especially in our
> increasingly
> > > > > > containerized world.
> > > > > >
> > > > > > Regards.
> > > > > >
> > > > > > Adam Carbone | Director of Innovation – Intelligent Platform
> > > Team |
> > > > > > Bottomline Technologies
> > > > > > Office: 603-501-6446 | Mobile: 603-570-8418
> > > > > > www.bottomline.com
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 8/13/20, 8:01 AM, "Ilya Kasnacheev" <
> > > ilya.kasnacheev@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > Hello!
> > > > > >
> > > > > > On the contrary, I would suggest that apache2 way was
> > > outdated
> > > > > even at
> > > > > > times when apache was all rage.
> > > > > >
> > > > > > Now the nginx approach is prevalent: on devops phase,
> > > assemble
> > > > a
> > > > > custom
> > > > > > bundle with all plugins included, store it somewhere, and
> > > ship
> > > > > it to
> > > > > > production as a whole to remove any on-the-fly
> uncertainty
> > > from
> > > > > > production.
> > > > > >
> > > > > > This is what docker does, but also maven, which downloads
> > > > > dependencies
> > > > > > during build. You do not need to download anything in
> > > runtime,
> > > > > except
> > > > > > for
> > > > > > experimental deployments. You need to be all set before
> > > runtime
> > > > > starts.
> > > > > >
> > > > > > Regards,
> > > > > > --
> > > > > > Ilya Kasnacheev
> > > > > >
> > > > > >
> > > > > > ср, 12 авг. 2020 г. в 09:48, Petr Ivanov <
> > > mr.weider@gmail.com
> > > > >:
> > > > > >
> > > > > > > Hi, Val.
> > > > > > >
> > > > > > > > On 12 Aug 2020, at 01:31, Valentin Kulichenko <
> > > > > > > valentin.kulichenko@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Hi Petr,
> > > > > > > >
> > > > > > > > I agree -- we should better modularize the platform.
> > The
> > > > > current
> > > > > > way if
> > > > > > > very error-prone, especially during upgrades -- any
> > changes
> > > > > made
> > > > > > within
> > > > > > > IGNITE_HOME (configs, scripts, modules, etc.) must be
> > > merged
> > > > > with a
> > > > > > new
> > > > > > > version of the package. There is no standard way of
> doing
> > > > this.
> > > > > > > >
> > > > > > > > However, I'm a bit concerned with your suggestion
> > > regarding
> > > > > custom
> > > > > > > dependency management. Can you please elaborate on how
> > you
> > > > > think it
> > > > > > should
> > > > > > > work? Are there tools we can reuse for this purpose? I
> > > would
> > > > > try to
> > > > > > avoid
> > > > > > > reinventing the wheel.
> > > > > > >
> > > > > > > I see it as a a2enmod | 2dismod analog of Apache2.
> > > > > > >
> > > > > > > We build and store Apache Ignite and its modules as
> > > separate
> > > > > binaries
> > > > > > > (binary per module) then use custom script that will
> know
> > > > > where to
> > > > > > download
> > > > > > > necessary module. Or possibly use modified ignite.sh to
> > > > specify
> > > > > > required
> > > > > > > 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.
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > -Val
> > > > > > > >
> > > > > > > > On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov <
> > > > > mr.weider@gmail.com
> > > > > > > <ma...@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
> > > > > > starting
> > > > > > > Ignite and all other modules and parts of the project
> > > > > (benchmarks,
> > > > > > > examples, etc.) packed in their own binary which can be
> > > added
> > > > > via
> > > > > > custom
> > > > > > > dependency management tool (i.e. modules.sh)
> > > > > > > > — same distribution for RPM and DEB packages but
> with
> > > > > modules
> > > > > > packed as
> > > > > > > separate ones (PHP for example)
> > > > > > > > — separate thin client release cycle with custom
> > > > versioning
> > > > > > > > Possibly, we can we add additional section to the
> > > document
> > > > > you
> > > > > > > introduced for this part.
> > > > > > > >
> > > > > > > > Also, it seems that full JDK11 support (including
> > > building)
> > > > > would
> > > > > > be a
> > > > > > > huge milestone and a sign of healthy modern project
> that
> > > > tends
> > > > > to be
> > > > > > on the
> > > > > > > verge of mainstream technologies and not the stockpile
> of
> > > > > legacy
> > > > > > leftovers
> > > > > > > (fully support Iliya in removing all that was
> deprecated
> > > > and/or
> > > > > > marked as
> > > > > > > unused anymore).
> > > > > > > >
> > > > > > > >
> > > > > > > > > On 8 Aug 2020, at 02:00, Valentin Kulichenko <
> > > > > > > valentin.kulichenko@gmail.com <mailto:
> > > > > valentin.kulichenko@gmail.com
> > > > > > >>
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Igniters,
> > > > > > > > >
> > > > > > > > > I've created the page:
> > > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> > > > > > <
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> > > > > > >
> > > > > > > > >
> > > > > > > > > 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 the consensus on the
> > proposed
> > > > > changes,
> > > > > > I will
> > > > > > > > > start creating tickets in Jira and a more detailed
> > > plan.
> > > > > > > > >
> > > > > > > > > -Val
> > > > > > > > >
> > > > > > > > > On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <
> > > > > > saikat.maitra@gmail.com
> > > > > > > <ma...@gmail.com>>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > >> Hi Denis, Val
> > > > > > > > >>
> > > > > > > > >> Thank you for your reply and really appreciate it.
> > It
> > > > > will be
> > > > > > very
> > > > > > > cool to
> > > > > > > > >> be able to connect and plan release together and
> > learn
> > > > > more
> > > > > > about
> > > > > > > Ignite in
> > > > > > > > >> the process :)
> > > > > > > > >>
> > > > > > > > >> Regards
> > > > > > > > >> Saikat
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> On Thu, Aug 6, 2020 at 7:12 PM Valentin
> Kulichenko <
> > > > > > > > >> valentin.kulichenko@gmail.com <mailto:
> > > > > > valentin.kulichenko@gmail.com>>
> > > > > > > wrote:
> > > > > > > > >>
> > > > > > > > >>> Hi Saikat,
> > > > > > > > >>>
> > > > > > > > >>> That surely is a great idea. We will work
> together
> > > with
> > > > > Denis
> > > > > > on
> > > > > > > setting
> > > > > > > > >>> this up in the nearest future.
> > > > > > > > >>>
> > > > > > > > >>> -Val
> > > > > > > > >>>
> > > > > > > > >>> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <
> > > > > dmagda@apache.org
> > > > > > > <ma...@apache.org>> wrote:
> > > > > > > > >>>
> > > > > > > > >>>> Saikat,
> > > > > > > > >>>>
> > > > > > > > >>>> Fully support your idea on a virtual meetup!
> Once
> > > Val
> > > > > > collects and
> > > > > > > > >>> outlines
> > > > > > > > >>>> the main changes with directions on wiki, we’ll
> go
> > > > > ahead and
> > > > > > > schedule
> > > > > > > > >> the
> > > > > > > > >>>> meetup to talk things out in a bit more detail.
> > > We’ll
> > > > > use our
> > > > > > new
> > > > > > > > >> Virtual
> > > > > > > > >>>> Ignite Meetup group for that inviting both
> Ignite
> > > > > > contributors and
> > > > > > > > >>>> application developers.
> > > > > > > > >>>>
> > > > > > > > >>>> Denis
> > > > > > > > >>>>
> > > > > > > > >>>> On Thursday, August 6, 2020, Saikat Maitra <
> > > > > > saikat.maitra@gmail.com
> > > > > > > <ma...@gmail.com>>
> > > > > > > > >>>> wrote:
> > > > > > > > >>>>
> > > > > > > > >>>>> Hi Valentin
> > > > > > > > >>>>>
> > > > > > > > >>>>> Thank you for sharing and starting the thread.
> I
> > am
> > > > > thinking
> > > > > > if it
> > > > > > > > >> will
> > > > > > > > >>>> be
> > > > > > > > >>>>> a good idea to have a virtual meet setup to
> > discuss
> > > > on
> > > > > the
> > > > > > release
> > > > > > > > >>>>> planning.
> > > > > > > > >>>>>
> > > > > > > > >>>>> It will help to learn more individual features
> to
> > > be
> > > > > added
> > > > > > and also
> > > > > > > > >> to
> > > > > > > > >>>>> understand about features that have been
> > deprecated
> > > > and
> > > > > > scheduled
> > > > > > > for
> > > > > > > > >>>>> removal in Ignite 3.0 release. Also it will
> help
> > > > > community
> > > > > > member
> > > > > > > to
> > > > > > > > >>>>> connect in real time and ask questions and
> share
> > > > > feedback.
> > > > > > > > >>>>>
> > > > > > > > >>>>> Regards,
> > > > > > > > >>>>> Saikat
> > > > > > > > >>>>>
> > > > > > > > >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev
> <
> > > > > > > > >>>> ilya.kasnacheev@gmail.com <mailto:
> > > > > ilya.kasnacheev@gmail.com>>
> > > > > > > > >>>>> wrote:
> > > > > > > > >>>>>
> > > > > > > > >>>>>> Hello!
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> I hope to see Apache Ignite release 3.0 as API
> > > > > trimming
> > > > > > release.
> > > > > > > > >> Let
> > > > > > > > >>> us
> > > > > > > > >>>>>> correct external and internal APIs for which
> we
> > > have
> > > > > better
> > > > > > ideas
> > > > > > > > >>> now,
> > > > > > > > >>>> as
> > > > > > > > >>>>>> well as remove old and deprecated code.
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> We may also introduce new configuration
> > mechanisms
> > > > and
> > > > > > user-facing
> > > > > > > > >>> API
> > > > > > > > >>>>>> (such as cache-less native SQL queries), but
> > this
> > > we
> > > > > could
> > > > > > > > >> prototype
> > > > > > > > >>>>> before
> > > > > > > > >>>>>> starting the 3.0 task.
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> I will advise against targeting large new
> > features
> > > > at
> > > > > 3.0.
> > > > > > They
> > > > > > > can
> > > > > > > > >>> be
> > > > > > > > >>>>>> added in subsequent point releases, whereas we
> > > can't
> > > > > really
> > > > > > remove
> > > > > > > > >> or
> > > > > > > > >>>>>> remodel stuff in point releases.
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> Regards,
> > > > > > > > >>>>>> --
> > > > > > > > >>>>>> Ilya Kasnacheev
> > > > > > > > >>>>>>
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin
> Kulichenko
> > <
> > > > > > > > >>>>>> valentin.kulichenko@gmail.com <mailto:
> > > > > > > valentin.kulichenko@gmail.com>>:
> > > > > > > > >>>>>>
> > > > > > > > >>>>>>> Igniters,
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>> I would like to kick off a discussion
> regarding
> > > > > Ignite 3.0.
> > > > > > > > >> Ignite
> > > > > > > > >>>> 2.0
> > > > > > > > >>>>>>> exists for more than 3 years now and we've
> > > already
> > > > > > collected a
> > > > > > > > >>>>>> significant
> > > > > > > > >>>>>>> list [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://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> > > > > > <
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> > > > > > >
> > > > > > > > >>>>> Apache+Ignite+3.0+Wishlist
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>> Regards,
> > > > > > > > >>>>>>> Val
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>>> --
> > > > > > > > >>>> -
> > > > > > > > >>>> Denis
> > > > > > > > >>>>
> > > > > > > > >>>
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Apache Ignite 3.0
Posted by Pavel Tupitsyn <pt...@apache.org>.
Val,
> Is see the ".NET Modernization for Ignite 3.0" item in the roadmap, but it
> doesn't provide much detail. What are the actual changes in .NET that you
> propose for 3.0?
I've updated the roadmap with a brief description.
We want to move away from an old, long unsupported .NET version,
and remove integrations with legacy technologies (old ASP.NET and EF).
> As for the messaging, so far I haven't seen use cases that would require
> this API. Sometimes users attempt to use it for remote code invocation,
but
> compute is usually 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.
Messaging can be more convenient, since it is pub-sub - 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
On Tue, Aug 18, 2020 at 3:16 AM Saikat Maitra <sa...@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 Tupitsyn <pt...@apache.org>
> wrote:
>
> > Saikat, yes, most definitely.
> > This is mentioned in the wishlist under ".NET: Target .NET Standard 2.0,
> > discontinue .NET 4.0 support".
> > I'm already working towards this goal by making more code and tests work
> > properly under .NET Core,
> > so when the time for breaking changes comes, it will be simpler.
> >
> > On Sat, Aug 15, 2020 at 10:06 PM Saikat Maitra <sa...@gmail.com>
> > 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
> > > release?
> > >
> > >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap
> > >
> > > Regards,
> > > Saikat
> > >
> > >
> > >
> > > On Fri, Aug 14, 2020 at 10:04 AM Carbone, Adam <
> > > Adam.Carbone@bottomline.com>
> > > wrote:
> > >
> > > > If you want to make is simpler to have the components that you want,
> > but
> > > > have that be immutable at install time you could take an approach
> > similar
> > > > to the way spring does it with their initializer (
> > > > https://start.spring.io/ ) as an example... Basically the concept
> > being
> > > > something that produces a set of configurations that are used to
> define
> > > > what the environment looks like ( these could be k8s objects ) they
> > could
> > > > be spring-configuration objects? They could be something that you
> > develop
> > > > all upon ignite ( probably wouldn’t recommend this approach ) there
> > > seems
> > > > to be plenty of these types of things already
> > > >
> > > > Example
> > > > * https://spring.io/guides/gs/centralized-configuration
> > > > *
> > > >
> > >
> >
> https://cocoon.apache.org/subprojects/configuration/spring-configurator/index.html
> > > >
> > > > And I'm by no means saying to use spring these are just examples
> that I
> > > > came across
> > > >
> > > > I'm thinking the outcome needs to be a platform config of source (
> that
> > > > can be checked in for those doing gitops ) and maybe ends up as a
> > config
> > > > map for those doing k8s, and some other fashion for those doing
> > something
> > > > else.
> > > >
> > > > Honestly I am not deep enough into the internals of ignite to know
> how
> > > > this might work for the platform, was more describing what I'm seeing
> > > from
> > > > a bigger picture trend
> > > >
> > > > Regards
> > > >
> > > > Adam Carbone | Director of Innovation – Intelligent Platform Team |
> > > > Bottomline Technologies
> > > > Office: 603-501-6446 | Mobile: 603-570-8418
> > > > www.bottomline.com
> > > >
> > > >
> > > >
> > > > On 8/13/20, 7:55 PM, "Valentin Kulichenko" <
> > > valentin.kulichenko@gmail.com>
> > > > wrote:
> > > >
> > > > Hi Ilya,
> > > >
> > > > Can you please describe your vision of how it should work?
> > > >
> > > > Let's say, I want to set up a cluster of several standalone
> server
> > > > nodes
> > > > with a couple of optional modules enabled. What are my steps?
> > > >
> > > > -Val
> > > >
> > > > On Thu, Aug 13, 2020 at 6:03 AM Carbone, Adam <
> > > > Adam.Carbone@bottomline.com>
> > > > wrote:
> > > >
> > > > > Good Morning from the EastCoast
> > > > >
> > > > > I have to agree that the larger industry is tending towards
> > > > immutability,
> > > > > and that you build once and test, then you promote/migrate that
> > > > immutable
> > > > > binary object, be is a library or a docker image etc... however
> > > > there are
> > > > > still patterns that allow you to determine at install/or
> > deployment
> > > > time (
> > > > > helm as an example, you choose based on your values what the
> > > package
> > > > > installs/provides ) It just isn't decided at runtime but
> install
> > > and
> > > > often
> > > > > in a gitops type world that is determined by configuration as
> > code.
> > > > I think
> > > > > run time is difficult to manage especially in our increasingly
> > > > > containerized world.
> > > > >
> > > > > Regards.
> > > > >
> > > > > Adam Carbone | Director of Innovation – Intelligent Platform
> > Team |
> > > > > Bottomline Technologies
> > > > > Office: 603-501-6446 | Mobile: 603-570-8418
> > > > > www.bottomline.com
> > > > >
> > > > >
> > > > >
> > > > > On 8/13/20, 8:01 AM, "Ilya Kasnacheev" <
> > ilya.kasnacheev@gmail.com>
> > > > wrote:
> > > > >
> > > > > Hello!
> > > > >
> > > > > On the contrary, I would suggest that apache2 way was
> > outdated
> > > > even at
> > > > > times when apache was all rage.
> > > > >
> > > > > Now the nginx approach is prevalent: on devops phase,
> > assemble
> > > a
> > > > custom
> > > > > bundle with all plugins included, store it somewhere, and
> > ship
> > > > it to
> > > > > production as a whole to remove any on-the-fly uncertainty
> > from
> > > > > production.
> > > > >
> > > > > This is what docker does, but also maven, which downloads
> > > > dependencies
> > > > > during build. You do not need to download anything in
> > runtime,
> > > > except
> > > > > for
> > > > > experimental deployments. You need to be all set before
> > runtime
> > > > starts.
> > > > >
> > > > > Regards,
> > > > > --
> > > > > Ilya Kasnacheev
> > > > >
> > > > >
> > > > > ср, 12 авг. 2020 г. в 09:48, Petr Ivanov <
> > mr.weider@gmail.com
> > > >:
> > > > >
> > > > > > Hi, Val.
> > > > > >
> > > > > > > On 12 Aug 2020, at 01:31, Valentin Kulichenko <
> > > > > > valentin.kulichenko@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi Petr,
> > > > > > >
> > > > > > > I agree -- we should better modularize the platform.
> The
> > > > current
> > > > > way if
> > > > > > very error-prone, especially during upgrades -- any
> changes
> > > > made
> > > > > within
> > > > > > IGNITE_HOME (configs, scripts, modules, etc.) must be
> > merged
> > > > with a
> > > > > new
> > > > > > version of the package. There is no standard way of doing
> > > this.
> > > > > > >
> > > > > > > However, I'm a bit concerned with your suggestion
> > regarding
> > > > custom
> > > > > > dependency management. Can you please elaborate on how
> you
> > > > think it
> > > > > should
> > > > > > work? Are there tools we can reuse for this purpose? I
> > would
> > > > try to
> > > > > avoid
> > > > > > reinventing the wheel.
> > > > > >
> > > > > > I see it as a a2enmod | 2dismod analog of Apache2.
> > > > > >
> > > > > > We build and store Apache Ignite and its modules as
> > separate
> > > > binaries
> > > > > > (binary per module) then use custom script that will know
> > > > where to
> > > > > download
> > > > > > necessary module. Or possibly use modified ignite.sh to
> > > specify
> > > > > required
> > > > > > 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.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > -Val
> > > > > > >
> > > > > > > On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov <
> > > > mr.weider@gmail.com
> > > > > > <ma...@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
> > > > > starting
> > > > > > Ignite and all other modules and parts of the project
> > > > (benchmarks,
> > > > > > examples, etc.) packed in their own binary which can be
> > added
> > > > via
> > > > > custom
> > > > > > dependency management tool (i.e. modules.sh)
> > > > > > > — same distribution for RPM and DEB packages but with
> > > > modules
> > > > > packed as
> > > > > > separate ones (PHP for example)
> > > > > > > — separate thin client release cycle with custom
> > > versioning
> > > > > > > Possibly, we can we add additional section to the
> > document
> > > > you
> > > > > > introduced for this part.
> > > > > > >
> > > > > > > Also, it seems that full JDK11 support (including
> > building)
> > > > would
> > > > > be a
> > > > > > huge milestone and a sign of healthy modern project that
> > > tends
> > > > to be
> > > > > on the
> > > > > > verge of mainstream technologies and not the stockpile of
> > > > legacy
> > > > > leftovers
> > > > > > (fully support Iliya in removing all that was deprecated
> > > and/or
> > > > > marked as
> > > > > > unused anymore).
> > > > > > >
> > > > > > >
> > > > > > > > On 8 Aug 2020, at 02:00, Valentin Kulichenko <
> > > > > > valentin.kulichenko@gmail.com <mailto:
> > > > valentin.kulichenko@gmail.com
> > > > > >>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > Igniters,
> > > > > > > >
> > > > > > > > I've created the page:
> > > > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> > > > > >
> > > > > > > >
> > > > > > > > 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 the consensus on the
> proposed
> > > > changes,
> > > > > I will
> > > > > > > > start creating tickets in Jira and a more detailed
> > plan.
> > > > > > > >
> > > > > > > > -Val
> > > > > > > >
> > > > > > > > On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <
> > > > > saikat.maitra@gmail.com
> > > > > > <ma...@gmail.com>>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > >> Hi Denis, Val
> > > > > > > >>
> > > > > > > >> Thank you for your reply and really appreciate it.
> It
> > > > will be
> > > > > very
> > > > > > cool to
> > > > > > > >> be able to connect and plan release together and
> learn
> > > > more
> > > > > about
> > > > > > Ignite in
> > > > > > > >> the process :)
> > > > > > > >>
> > > > > > > >> Regards
> > > > > > > >> Saikat
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko <
> > > > > > > >> valentin.kulichenko@gmail.com <mailto:
> > > > > valentin.kulichenko@gmail.com>>
> > > > > > wrote:
> > > > > > > >>
> > > > > > > >>> Hi Saikat,
> > > > > > > >>>
> > > > > > > >>> That surely is a great idea. We will work together
> > with
> > > > Denis
> > > > > on
> > > > > > setting
> > > > > > > >>> this up in the nearest future.
> > > > > > > >>>
> > > > > > > >>> -Val
> > > > > > > >>>
> > > > > > > >>> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <
> > > > dmagda@apache.org
> > > > > > <ma...@apache.org>> wrote:
> > > > > > > >>>
> > > > > > > >>>> Saikat,
> > > > > > > >>>>
> > > > > > > >>>> Fully support your idea on a virtual meetup! Once
> > Val
> > > > > collects and
> > > > > > > >>> outlines
> > > > > > > >>>> the main changes with directions on wiki, we’ll go
> > > > ahead and
> > > > > > schedule
> > > > > > > >> the
> > > > > > > >>>> meetup to talk things out in a bit more detail.
> > We’ll
> > > > use our
> > > > > new
> > > > > > > >> Virtual
> > > > > > > >>>> Ignite Meetup group for that inviting both Ignite
> > > > > contributors and
> > > > > > > >>>> application developers.
> > > > > > > >>>>
> > > > > > > >>>> Denis
> > > > > > > >>>>
> > > > > > > >>>> On Thursday, August 6, 2020, Saikat Maitra <
> > > > > saikat.maitra@gmail.com
> > > > > > <ma...@gmail.com>>
> > > > > > > >>>> wrote:
> > > > > > > >>>>
> > > > > > > >>>>> Hi Valentin
> > > > > > > >>>>>
> > > > > > > >>>>> Thank you for sharing and starting the thread. I
> am
> > > > thinking
> > > > > if it
> > > > > > > >> will
> > > > > > > >>>> be
> > > > > > > >>>>> a good idea to have a virtual meet setup to
> discuss
> > > on
> > > > the
> > > > > release
> > > > > > > >>>>> planning.
> > > > > > > >>>>>
> > > > > > > >>>>> It will help to learn more individual features to
> > be
> > > > added
> > > > > and also
> > > > > > > >> to
> > > > > > > >>>>> understand about features that have been
> deprecated
> > > and
> > > > > scheduled
> > > > > > for
> > > > > > > >>>>> removal in Ignite 3.0 release. Also it will help
> > > > community
> > > > > member
> > > > > > to
> > > > > > > >>>>> connect in real time and ask questions and share
> > > > feedback.
> > > > > > > >>>>>
> > > > > > > >>>>> Regards,
> > > > > > > >>>>> Saikat
> > > > > > > >>>>>
> > > > > > > >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <
> > > > > > > >>>> ilya.kasnacheev@gmail.com <mailto:
> > > > ilya.kasnacheev@gmail.com>>
> > > > > > > >>>>> wrote:
> > > > > > > >>>>>
> > > > > > > >>>>>> Hello!
> > > > > > > >>>>>>
> > > > > > > >>>>>> I hope to see Apache Ignite release 3.0 as API
> > > > trimming
> > > > > release.
> > > > > > > >> Let
> > > > > > > >>> us
> > > > > > > >>>>>> correct external and internal APIs for which we
> > have
> > > > better
> > > > > ideas
> > > > > > > >>> now,
> > > > > > > >>>> as
> > > > > > > >>>>>> well as remove old and deprecated code.
> > > > > > > >>>>>>
> > > > > > > >>>>>> We may also introduce new configuration
> mechanisms
> > > and
> > > > > user-facing
> > > > > > > >>> API
> > > > > > > >>>>>> (such as cache-less native SQL queries), but
> this
> > we
> > > > could
> > > > > > > >> prototype
> > > > > > > >>>>> before
> > > > > > > >>>>>> starting the 3.0 task.
> > > > > > > >>>>>>
> > > > > > > >>>>>> I will advise against targeting large new
> features
> > > at
> > > > 3.0.
> > > > > They
> > > > > > can
> > > > > > > >>> be
> > > > > > > >>>>>> added in subsequent point releases, whereas we
> > can't
> > > > really
> > > > > remove
> > > > > > > >> or
> > > > > > > >>>>>> remodel stuff in point releases.
> > > > > > > >>>>>>
> > > > > > > >>>>>> Regards,
> > > > > > > >>>>>> --
> > > > > > > >>>>>> Ilya Kasnacheev
> > > > > > > >>>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko
> <
> > > > > > > >>>>>> valentin.kulichenko@gmail.com <mailto:
> > > > > > valentin.kulichenko@gmail.com>>:
> > > > > > > >>>>>>
> > > > > > > >>>>>>> Igniters,
> > > > > > > >>>>>>>
> > > > > > > >>>>>>> I would like to kick off a discussion regarding
> > > > Ignite 3.0.
> > > > > > > >> Ignite
> > > > > > > >>>> 2.0
> > > > > > > >>>>>>> exists for more than 3 years now and we've
> > already
> > > > > collected a
> > > > > > > >>>>>> significant
> > > > > > > >>>>>>> list [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://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> > > > > >
> > > > > > > >>>>> Apache+Ignite+3.0+Wishlist
> > > > > > > >>>>>>>
> > > > > > > >>>>>>> Regards,
> > > > > > > >>>>>>> Val
> > > > > > > >>>>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>>
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>> --
> > > > > > > >>>> -
> > > > > > > >>>> Denis
> > > > > > > >>>>
> > > > > > > >>>
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> >
>
Re: Apache Ignite 3.0
Posted by Saikat Maitra <sa...@gmail.com>.
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 <pt...@apache.org>
wrote:
> Saikat, yes, most definitely.
> This is mentioned in the wishlist under ".NET: Target .NET Standard 2.0,
> discontinue .NET 4.0 support".
> I'm already working towards this goal by making more code and tests work
> properly under .NET Core,
> so when the time for breaking changes comes, it will be simpler.
>
> On Sat, Aug 15, 2020 at 10:06 PM Saikat Maitra <sa...@gmail.com>
> 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
> > release?
> >
> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap
> >
> > Regards,
> > Saikat
> >
> >
> >
> > On Fri, Aug 14, 2020 at 10:04 AM Carbone, Adam <
> > Adam.Carbone@bottomline.com>
> > wrote:
> >
> > > If you want to make is simpler to have the components that you want,
> but
> > > have that be immutable at install time you could take an approach
> similar
> > > to the way spring does it with their initializer (
> > > https://start.spring.io/ ) as an example... Basically the concept
> being
> > > something that produces a set of configurations that are used to define
> > > what the environment looks like ( these could be k8s objects ) they
> could
> > > be spring-configuration objects? They could be something that you
> develop
> > > all upon ignite ( probably wouldn’t recommend this approach ) there
> > seems
> > > to be plenty of these types of things already
> > >
> > > Example
> > > * https://spring.io/guides/gs/centralized-configuration
> > > *
> > >
> >
> https://cocoon.apache.org/subprojects/configuration/spring-configurator/index.html
> > >
> > > And I'm by no means saying to use spring these are just examples that I
> > > came across
> > >
> > > I'm thinking the outcome needs to be a platform config of source ( that
> > > can be checked in for those doing gitops ) and maybe ends up as a
> config
> > > map for those doing k8s, and some other fashion for those doing
> something
> > > else.
> > >
> > > Honestly I am not deep enough into the internals of ignite to know how
> > > this might work for the platform, was more describing what I'm seeing
> > from
> > > a bigger picture trend
> > >
> > > Regards
> > >
> > > Adam Carbone | Director of Innovation – Intelligent Platform Team |
> > > Bottomline Technologies
> > > Office: 603-501-6446 | Mobile: 603-570-8418
> > > www.bottomline.com
> > >
> > >
> > >
> > > On 8/13/20, 7:55 PM, "Valentin Kulichenko" <
> > valentin.kulichenko@gmail.com>
> > > wrote:
> > >
> > > Hi Ilya,
> > >
> > > Can you please describe your vision of how it should work?
> > >
> > > Let's say, I want to set up a cluster of several standalone server
> > > nodes
> > > with a couple of optional modules enabled. What are my steps?
> > >
> > > -Val
> > >
> > > On Thu, Aug 13, 2020 at 6:03 AM Carbone, Adam <
> > > Adam.Carbone@bottomline.com>
> > > wrote:
> > >
> > > > Good Morning from the EastCoast
> > > >
> > > > I have to agree that the larger industry is tending towards
> > > immutability,
> > > > and that you build once and test, then you promote/migrate that
> > > immutable
> > > > binary object, be is a library or a docker image etc... however
> > > there are
> > > > still patterns that allow you to determine at install/or
> deployment
> > > time (
> > > > helm as an example, you choose based on your values what the
> > package
> > > > installs/provides ) It just isn't decided at runtime but install
> > and
> > > often
> > > > in a gitops type world that is determined by configuration as
> code.
> > > I think
> > > > run time is difficult to manage especially in our increasingly
> > > > containerized world.
> > > >
> > > > Regards.
> > > >
> > > > Adam Carbone | Director of Innovation – Intelligent Platform
> Team |
> > > > Bottomline Technologies
> > > > Office: 603-501-6446 | Mobile: 603-570-8418
> > > > www.bottomline.com
> > > >
> > > >
> > > >
> > > > On 8/13/20, 8:01 AM, "Ilya Kasnacheev" <
> ilya.kasnacheev@gmail.com>
> > > wrote:
> > > >
> > > > Hello!
> > > >
> > > > On the contrary, I would suggest that apache2 way was
> outdated
> > > even at
> > > > times when apache was all rage.
> > > >
> > > > Now the nginx approach is prevalent: on devops phase,
> assemble
> > a
> > > custom
> > > > bundle with all plugins included, store it somewhere, and
> ship
> > > it to
> > > > production as a whole to remove any on-the-fly uncertainty
> from
> > > > production.
> > > >
> > > > This is what docker does, but also maven, which downloads
> > > dependencies
> > > > during build. You do not need to download anything in
> runtime,
> > > except
> > > > for
> > > > experimental deployments. You need to be all set before
> runtime
> > > starts.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > ср, 12 авг. 2020 г. в 09:48, Petr Ivanov <
> mr.weider@gmail.com
> > >:
> > > >
> > > > > Hi, Val.
> > > > >
> > > > > > On 12 Aug 2020, at 01:31, Valentin Kulichenko <
> > > > > valentin.kulichenko@gmail.com> wrote:
> > > > > >
> > > > > > Hi Petr,
> > > > > >
> > > > > > I agree -- we should better modularize the platform. The
> > > current
> > > > way if
> > > > > very error-prone, especially during upgrades -- any changes
> > > made
> > > > within
> > > > > IGNITE_HOME (configs, scripts, modules, etc.) must be
> merged
> > > with a
> > > > new
> > > > > version of the package. There is no standard way of doing
> > this.
> > > > > >
> > > > > > However, I'm a bit concerned with your suggestion
> regarding
> > > custom
> > > > > dependency management. Can you please elaborate on how you
> > > think it
> > > > should
> > > > > work? Are there tools we can reuse for this purpose? I
> would
> > > try to
> > > > avoid
> > > > > reinventing the wheel.
> > > > >
> > > > > I see it as a a2enmod | 2dismod analog of Apache2.
> > > > >
> > > > > We build and store Apache Ignite and its modules as
> separate
> > > binaries
> > > > > (binary per module) then use custom script that will know
> > > where to
> > > > download
> > > > > necessary module. Or possibly use modified ignite.sh to
> > specify
> > > > required
> > > > > 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.
> > > > >
> > > > >
> > > > > >
> > > > > > -Val
> > > > > >
> > > > > > On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov <
> > > mr.weider@gmail.com
> > > > > <ma...@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
> > > > starting
> > > > > Ignite and all other modules and parts of the project
> > > (benchmarks,
> > > > > examples, etc.) packed in their own binary which can be
> added
> > > via
> > > > custom
> > > > > dependency management tool (i.e. modules.sh)
> > > > > > — same distribution for RPM and DEB packages but with
> > > modules
> > > > packed as
> > > > > separate ones (PHP for example)
> > > > > > — separate thin client release cycle with custom
> > versioning
> > > > > > Possibly, we can we add additional section to the
> document
> > > you
> > > > > introduced for this part.
> > > > > >
> > > > > > Also, it seems that full JDK11 support (including
> building)
> > > would
> > > > be a
> > > > > huge milestone and a sign of healthy modern project that
> > tends
> > > to be
> > > > on the
> > > > > verge of mainstream technologies and not the stockpile of
> > > legacy
> > > > leftovers
> > > > > (fully support Iliya in removing all that was deprecated
> > and/or
> > > > marked as
> > > > > unused anymore).
> > > > > >
> > > > > >
> > > > > > > On 8 Aug 2020, at 02:00, Valentin Kulichenko <
> > > > > valentin.kulichenko@gmail.com <mailto:
> > > valentin.kulichenko@gmail.com
> > > > >>
> > > > > wrote:
> > > > > > >
> > > > > > > Igniters,
> > > > > > >
> > > > > > > I've created the page:
> > > > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> > > > <
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> > > > >
> > > > > > >
> > > > > > > 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 the consensus on the proposed
> > > changes,
> > > > I will
> > > > > > > start creating tickets in Jira and a more detailed
> plan.
> > > > > > >
> > > > > > > -Val
> > > > > > >
> > > > > > > On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <
> > > > saikat.maitra@gmail.com
> > > > > <ma...@gmail.com>>
> > > > > > > wrote:
> > > > > > >
> > > > > > >> Hi Denis, Val
> > > > > > >>
> > > > > > >> Thank you for your reply and really appreciate it. It
> > > will be
> > > > very
> > > > > cool to
> > > > > > >> be able to connect and plan release together and learn
> > > more
> > > > about
> > > > > Ignite in
> > > > > > >> the process :)
> > > > > > >>
> > > > > > >> Regards
> > > > > > >> Saikat
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko <
> > > > > > >> valentin.kulichenko@gmail.com <mailto:
> > > > valentin.kulichenko@gmail.com>>
> > > > > wrote:
> > > > > > >>
> > > > > > >>> Hi Saikat,
> > > > > > >>>
> > > > > > >>> That surely is a great idea. We will work together
> with
> > > Denis
> > > > on
> > > > > setting
> > > > > > >>> this up in the nearest future.
> > > > > > >>>
> > > > > > >>> -Val
> > > > > > >>>
> > > > > > >>> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <
> > > dmagda@apache.org
> > > > > <ma...@apache.org>> wrote:
> > > > > > >>>
> > > > > > >>>> Saikat,
> > > > > > >>>>
> > > > > > >>>> Fully support your idea on a virtual meetup! Once
> Val
> > > > collects and
> > > > > > >>> outlines
> > > > > > >>>> the main changes with directions on wiki, we’ll go
> > > ahead and
> > > > > schedule
> > > > > > >> the
> > > > > > >>>> meetup to talk things out in a bit more detail.
> We’ll
> > > use our
> > > > new
> > > > > > >> Virtual
> > > > > > >>>> Ignite Meetup group for that inviting both Ignite
> > > > contributors and
> > > > > > >>>> application developers.
> > > > > > >>>>
> > > > > > >>>> Denis
> > > > > > >>>>
> > > > > > >>>> On Thursday, August 6, 2020, Saikat Maitra <
> > > > saikat.maitra@gmail.com
> > > > > <ma...@gmail.com>>
> > > > > > >>>> wrote:
> > > > > > >>>>
> > > > > > >>>>> Hi Valentin
> > > > > > >>>>>
> > > > > > >>>>> Thank you for sharing and starting the thread. I am
> > > thinking
> > > > if it
> > > > > > >> will
> > > > > > >>>> be
> > > > > > >>>>> a good idea to have a virtual meet setup to discuss
> > on
> > > the
> > > > release
> > > > > > >>>>> planning.
> > > > > > >>>>>
> > > > > > >>>>> It will help to learn more individual features to
> be
> > > added
> > > > and also
> > > > > > >> to
> > > > > > >>>>> understand about features that have been deprecated
> > and
> > > > scheduled
> > > > > for
> > > > > > >>>>> removal in Ignite 3.0 release. Also it will help
> > > community
> > > > member
> > > > > to
> > > > > > >>>>> connect in real time and ask questions and share
> > > feedback.
> > > > > > >>>>>
> > > > > > >>>>> Regards,
> > > > > > >>>>> Saikat
> > > > > > >>>>>
> > > > > > >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <
> > > > > > >>>> ilya.kasnacheev@gmail.com <mailto:
> > > ilya.kasnacheev@gmail.com>>
> > > > > > >>>>> wrote:
> > > > > > >>>>>
> > > > > > >>>>>> Hello!
> > > > > > >>>>>>
> > > > > > >>>>>> I hope to see Apache Ignite release 3.0 as API
> > > trimming
> > > > release.
> > > > > > >> Let
> > > > > > >>> us
> > > > > > >>>>>> correct external and internal APIs for which we
> have
> > > better
> > > > ideas
> > > > > > >>> now,
> > > > > > >>>> as
> > > > > > >>>>>> well as remove old and deprecated code.
> > > > > > >>>>>>
> > > > > > >>>>>> We may also introduce new configuration mechanisms
> > and
> > > > user-facing
> > > > > > >>> API
> > > > > > >>>>>> (such as cache-less native SQL queries), but this
> we
> > > could
> > > > > > >> prototype
> > > > > > >>>>> before
> > > > > > >>>>>> starting the 3.0 task.
> > > > > > >>>>>>
> > > > > > >>>>>> I will advise against targeting large new features
> > at
> > > 3.0.
> > > > They
> > > > > can
> > > > > > >>> be
> > > > > > >>>>>> added in subsequent point releases, whereas we
> can't
> > > really
> > > > remove
> > > > > > >> or
> > > > > > >>>>>> remodel stuff in point releases.
> > > > > > >>>>>>
> > > > > > >>>>>> Regards,
> > > > > > >>>>>> --
> > > > > > >>>>>> Ilya Kasnacheev
> > > > > > >>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
> > > > > > >>>>>> valentin.kulichenko@gmail.com <mailto:
> > > > > valentin.kulichenko@gmail.com>>:
> > > > > > >>>>>>
> > > > > > >>>>>>> Igniters,
> > > > > > >>>>>>>
> > > > > > >>>>>>> I would like to kick off a discussion regarding
> > > Ignite 3.0.
> > > > > > >> Ignite
> > > > > > >>>> 2.0
> > > > > > >>>>>>> exists for more than 3 years now and we've
> already
> > > > collected a
> > > > > > >>>>>> significant
> > > > > > >>>>>>> list [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://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> > > > <
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> > > > >
> > > > > > >>>>> Apache+Ignite+3.0+Wishlist
> > > > > > >>>>>>>
> > > > > > >>>>>>> Regards,
> > > > > > >>>>>>> Val
> > > > > > >>>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>> --
> > > > > > >>>> -
> > > > > > >>>> Denis
> > > > > > >>>>
> > > > > > >>>
> > > > > > >>
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
>
Re: Apache Ignite 3.0
Posted by Pavel Tupitsyn <pt...@apache.org>.
Saikat, yes, most definitely.
This is mentioned in the wishlist under ".NET: Target .NET Standard 2.0,
discontinue .NET 4.0 support".
I'm already working towards this goal by making more code and tests work
properly under .NET Core,
so when the time for breaking changes comes, it will be simpler.
On Sat, Aug 15, 2020 at 10:06 PM Saikat Maitra <sa...@gmail.com>
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
> release?
>
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap
>
> Regards,
> Saikat
>
>
>
> On Fri, Aug 14, 2020 at 10:04 AM Carbone, Adam <
> Adam.Carbone@bottomline.com>
> wrote:
>
> > If you want to make is simpler to have the components that you want, but
> > have that be immutable at install time you could take an approach similar
> > to the way spring does it with their initializer (
> > https://start.spring.io/ ) as an example... Basically the concept being
> > something that produces a set of configurations that are used to define
> > what the environment looks like ( these could be k8s objects ) they could
> > be spring-configuration objects? They could be something that you develop
> > all upon ignite ( probably wouldn’t recommend this approach ) there
> seems
> > to be plenty of these types of things already
> >
> > Example
> > * https://spring.io/guides/gs/centralized-configuration
> > *
> >
> https://cocoon.apache.org/subprojects/configuration/spring-configurator/index.html
> >
> > And I'm by no means saying to use spring these are just examples that I
> > came across
> >
> > I'm thinking the outcome needs to be a platform config of source ( that
> > can be checked in for those doing gitops ) and maybe ends up as a config
> > map for those doing k8s, and some other fashion for those doing something
> > else.
> >
> > Honestly I am not deep enough into the internals of ignite to know how
> > this might work for the platform, was more describing what I'm seeing
> from
> > a bigger picture trend
> >
> > Regards
> >
> > Adam Carbone | Director of Innovation – Intelligent Platform Team |
> > Bottomline Technologies
> > Office: 603-501-6446 | Mobile: 603-570-8418
> > www.bottomline.com
> >
> >
> >
> > On 8/13/20, 7:55 PM, "Valentin Kulichenko" <
> valentin.kulichenko@gmail.com>
> > wrote:
> >
> > Hi Ilya,
> >
> > Can you please describe your vision of how it should work?
> >
> > Let's say, I want to set up a cluster of several standalone server
> > nodes
> > with a couple of optional modules enabled. What are my steps?
> >
> > -Val
> >
> > On Thu, Aug 13, 2020 at 6:03 AM Carbone, Adam <
> > Adam.Carbone@bottomline.com>
> > wrote:
> >
> > > Good Morning from the EastCoast
> > >
> > > I have to agree that the larger industry is tending towards
> > immutability,
> > > and that you build once and test, then you promote/migrate that
> > immutable
> > > binary object, be is a library or a docker image etc... however
> > there are
> > > still patterns that allow you to determine at install/or deployment
> > time (
> > > helm as an example, you choose based on your values what the
> package
> > > installs/provides ) It just isn't decided at runtime but install
> and
> > often
> > > in a gitops type world that is determined by configuration as code.
> > I think
> > > run time is difficult to manage especially in our increasingly
> > > containerized world.
> > >
> > > Regards.
> > >
> > > Adam Carbone | Director of Innovation – Intelligent Platform Team |
> > > Bottomline Technologies
> > > Office: 603-501-6446 | Mobile: 603-570-8418
> > > www.bottomline.com
> > >
> > >
> > >
> > > On 8/13/20, 8:01 AM, "Ilya Kasnacheev" <il...@gmail.com>
> > wrote:
> > >
> > > Hello!
> > >
> > > On the contrary, I would suggest that apache2 way was outdated
> > even at
> > > times when apache was all rage.
> > >
> > > Now the nginx approach is prevalent: on devops phase, assemble
> a
> > custom
> > > bundle with all plugins included, store it somewhere, and ship
> > it to
> > > production as a whole to remove any on-the-fly uncertainty from
> > > production.
> > >
> > > This is what docker does, but also maven, which downloads
> > dependencies
> > > during build. You do not need to download anything in runtime,
> > except
> > > for
> > > experimental deployments. You need to be all set before runtime
> > starts.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > ср, 12 авг. 2020 г. в 09:48, Petr Ivanov <mr.weider@gmail.com
> >:
> > >
> > > > Hi, Val.
> > > >
> > > > > On 12 Aug 2020, at 01:31, Valentin Kulichenko <
> > > > valentin.kulichenko@gmail.com> wrote:
> > > > >
> > > > > Hi Petr,
> > > > >
> > > > > I agree -- we should better modularize the platform. The
> > current
> > > way if
> > > > very error-prone, especially during upgrades -- any changes
> > made
> > > within
> > > > IGNITE_HOME (configs, scripts, modules, etc.) must be merged
> > with a
> > > new
> > > > version of the package. There is no standard way of doing
> this.
> > > > >
> > > > > However, I'm a bit concerned with your suggestion regarding
> > custom
> > > > dependency management. Can you please elaborate on how you
> > think it
> > > should
> > > > work? Are there tools we can reuse for this purpose? I would
> > try to
> > > avoid
> > > > reinventing the wheel.
> > > >
> > > > I see it as a a2enmod | 2dismod analog of Apache2.
> > > >
> > > > We build and store Apache Ignite and its modules as separate
> > binaries
> > > > (binary per module) then use custom script that will know
> > where to
> > > download
> > > > necessary module. Or possibly use modified ignite.sh to
> specify
> > > required
> > > > 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.
> > > >
> > > >
> > > > >
> > > > > -Val
> > > > >
> > > > > On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov <
> > mr.weider@gmail.com
> > > > <ma...@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
> > > starting
> > > > Ignite and all other modules and parts of the project
> > (benchmarks,
> > > > examples, etc.) packed in their own binary which can be added
> > via
> > > custom
> > > > dependency management tool (i.e. modules.sh)
> > > > > — same distribution for RPM and DEB packages but with
> > modules
> > > packed as
> > > > separate ones (PHP for example)
> > > > > — separate thin client release cycle with custom
> versioning
> > > > > Possibly, we can we add additional section to the document
> > you
> > > > introduced for this part.
> > > > >
> > > > > Also, it seems that full JDK11 support (including building)
> > would
> > > be a
> > > > huge milestone and a sign of healthy modern project that
> tends
> > to be
> > > on the
> > > > verge of mainstream technologies and not the stockpile of
> > legacy
> > > leftovers
> > > > (fully support Iliya in removing all that was deprecated
> and/or
> > > marked as
> > > > unused anymore).
> > > > >
> > > > >
> > > > > > On 8 Aug 2020, at 02:00, Valentin Kulichenko <
> > > > valentin.kulichenko@gmail.com <mailto:
> > valentin.kulichenko@gmail.com
> > > >>
> > > > wrote:
> > > > > >
> > > > > > Igniters,
> > > > > >
> > > > > > I've created the page:
> > > > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> > > <
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> > > >
> > > > > >
> > > > > > 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 the consensus on the proposed
> > changes,
> > > I will
> > > > > > start creating tickets in Jira and a more detailed plan.
> > > > > >
> > > > > > -Val
> > > > > >
> > > > > > On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <
> > > saikat.maitra@gmail.com
> > > > <ma...@gmail.com>>
> > > > > > wrote:
> > > > > >
> > > > > >> Hi Denis, Val
> > > > > >>
> > > > > >> Thank you for your reply and really appreciate it. It
> > will be
> > > very
> > > > cool to
> > > > > >> be able to connect and plan release together and learn
> > more
> > > about
> > > > Ignite in
> > > > > >> the process :)
> > > > > >>
> > > > > >> Regards
> > > > > >> Saikat
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko <
> > > > > >> valentin.kulichenko@gmail.com <mailto:
> > > valentin.kulichenko@gmail.com>>
> > > > wrote:
> > > > > >>
> > > > > >>> Hi Saikat,
> > > > > >>>
> > > > > >>> That surely is a great idea. We will work together with
> > Denis
> > > on
> > > > setting
> > > > > >>> this up in the nearest future.
> > > > > >>>
> > > > > >>> -Val
> > > > > >>>
> > > > > >>> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <
> > dmagda@apache.org
> > > > <ma...@apache.org>> wrote:
> > > > > >>>
> > > > > >>>> Saikat,
> > > > > >>>>
> > > > > >>>> Fully support your idea on a virtual meetup! Once Val
> > > collects and
> > > > > >>> outlines
> > > > > >>>> the main changes with directions on wiki, we’ll go
> > ahead and
> > > > schedule
> > > > > >> the
> > > > > >>>> meetup to talk things out in a bit more detail. We’ll
> > use our
> > > new
> > > > > >> Virtual
> > > > > >>>> Ignite Meetup group for that inviting both Ignite
> > > contributors and
> > > > > >>>> application developers.
> > > > > >>>>
> > > > > >>>> Denis
> > > > > >>>>
> > > > > >>>> On Thursday, August 6, 2020, Saikat Maitra <
> > > saikat.maitra@gmail.com
> > > > <ma...@gmail.com>>
> > > > > >>>> wrote:
> > > > > >>>>
> > > > > >>>>> Hi Valentin
> > > > > >>>>>
> > > > > >>>>> Thank you for sharing and starting the thread. I am
> > thinking
> > > if it
> > > > > >> will
> > > > > >>>> be
> > > > > >>>>> a good idea to have a virtual meet setup to discuss
> on
> > the
> > > release
> > > > > >>>>> planning.
> > > > > >>>>>
> > > > > >>>>> It will help to learn more individual features to be
> > added
> > > and also
> > > > > >> to
> > > > > >>>>> understand about features that have been deprecated
> and
> > > scheduled
> > > > for
> > > > > >>>>> removal in Ignite 3.0 release. Also it will help
> > community
> > > member
> > > > to
> > > > > >>>>> connect in real time and ask questions and share
> > feedback.
> > > > > >>>>>
> > > > > >>>>> Regards,
> > > > > >>>>> Saikat
> > > > > >>>>>
> > > > > >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <
> > > > > >>>> ilya.kasnacheev@gmail.com <mailto:
> > ilya.kasnacheev@gmail.com>>
> > > > > >>>>> wrote:
> > > > > >>>>>
> > > > > >>>>>> Hello!
> > > > > >>>>>>
> > > > > >>>>>> I hope to see Apache Ignite release 3.0 as API
> > trimming
> > > release.
> > > > > >> Let
> > > > > >>> us
> > > > > >>>>>> correct external and internal APIs for which we have
> > better
> > > ideas
> > > > > >>> now,
> > > > > >>>> as
> > > > > >>>>>> well as remove old and deprecated code.
> > > > > >>>>>>
> > > > > >>>>>> We may also introduce new configuration mechanisms
> and
> > > user-facing
> > > > > >>> API
> > > > > >>>>>> (such as cache-less native SQL queries), but this we
> > could
> > > > > >> prototype
> > > > > >>>>> before
> > > > > >>>>>> starting the 3.0 task.
> > > > > >>>>>>
> > > > > >>>>>> I will advise against targeting large new features
> at
> > 3.0.
> > > They
> > > > can
> > > > > >>> be
> > > > > >>>>>> added in subsequent point releases, whereas we can't
> > really
> > > remove
> > > > > >> or
> > > > > >>>>>> remodel stuff in point releases.
> > > > > >>>>>>
> > > > > >>>>>> Regards,
> > > > > >>>>>> --
> > > > > >>>>>> Ilya Kasnacheev
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
> > > > > >>>>>> valentin.kulichenko@gmail.com <mailto:
> > > > valentin.kulichenko@gmail.com>>:
> > > > > >>>>>>
> > > > > >>>>>>> Igniters,
> > > > > >>>>>>>
> > > > > >>>>>>> I would like to kick off a discussion regarding
> > Ignite 3.0.
> > > > > >> Ignite
> > > > > >>>> 2.0
> > > > > >>>>>>> exists for more than 3 years now and we've already
> > > collected a
> > > > > >>>>>> significant
> > > > > >>>>>>> list [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://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> > > <
> > > >
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> > > >
> > > > > >>>>> Apache+Ignite+3.0+Wishlist
> > > > > >>>>>>>
> > > > > >>>>>>> Regards,
> > > > > >>>>>>> Val
> > > > > >>>>>>>
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> --
> > > > > >>>> -
> > > > > >>>> Denis
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
>
Re: Apache Ignite 3.0
Posted by Saikat Maitra <sa...@gmail.com>.
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
Regards,
Saikat
On Fri, Aug 14, 2020 at 10:04 AM Carbone, Adam <Ad...@bottomline.com>
wrote:
> If you want to make is simpler to have the components that you want, but
> have that be immutable at install time you could take an approach similar
> to the way spring does it with their initializer (
> https://start.spring.io/ ) as an example... Basically the concept being
> something that produces a set of configurations that are used to define
> what the environment looks like ( these could be k8s objects ) they could
> be spring-configuration objects? They could be something that you develop
> all upon ignite ( probably wouldn’t recommend this approach ) there seems
> to be plenty of these types of things already
>
> Example
> * https://spring.io/guides/gs/centralized-configuration
> *
> https://cocoon.apache.org/subprojects/configuration/spring-configurator/index.html
>
> And I'm by no means saying to use spring these are just examples that I
> came across
>
> I'm thinking the outcome needs to be a platform config of source ( that
> can be checked in for those doing gitops ) and maybe ends up as a config
> map for those doing k8s, and some other fashion for those doing something
> else.
>
> Honestly I am not deep enough into the internals of ignite to know how
> this might work for the platform, was more describing what I'm seeing from
> a bigger picture trend
>
> Regards
>
> Adam Carbone | Director of Innovation – Intelligent Platform Team |
> Bottomline Technologies
> Office: 603-501-6446 | Mobile: 603-570-8418
> www.bottomline.com
>
>
>
> On 8/13/20, 7:55 PM, "Valentin Kulichenko" <va...@gmail.com>
> wrote:
>
> Hi Ilya,
>
> Can you please describe your vision of how it should work?
>
> Let's say, I want to set up a cluster of several standalone server
> nodes
> with a couple of optional modules enabled. What are my steps?
>
> -Val
>
> On Thu, Aug 13, 2020 at 6:03 AM Carbone, Adam <
> Adam.Carbone@bottomline.com>
> wrote:
>
> > Good Morning from the EastCoast
> >
> > I have to agree that the larger industry is tending towards
> immutability,
> > and that you build once and test, then you promote/migrate that
> immutable
> > binary object, be is a library or a docker image etc... however
> there are
> > still patterns that allow you to determine at install/or deployment
> time (
> > helm as an example, you choose based on your values what the package
> > installs/provides ) It just isn't decided at runtime but install and
> often
> > in a gitops type world that is determined by configuration as code.
> I think
> > run time is difficult to manage especially in our increasingly
> > containerized world.
> >
> > Regards.
> >
> > Adam Carbone | Director of Innovation – Intelligent Platform Team |
> > Bottomline Technologies
> > Office: 603-501-6446 | Mobile: 603-570-8418
> > www.bottomline.com
> >
> >
> >
> > On 8/13/20, 8:01 AM, "Ilya Kasnacheev" <il...@gmail.com>
> wrote:
> >
> > Hello!
> >
> > On the contrary, I would suggest that apache2 way was outdated
> even at
> > times when apache was all rage.
> >
> > Now the nginx approach is prevalent: on devops phase, assemble a
> custom
> > bundle with all plugins included, store it somewhere, and ship
> it to
> > production as a whole to remove any on-the-fly uncertainty from
> > production.
> >
> > This is what docker does, but also maven, which downloads
> dependencies
> > during build. You do not need to download anything in runtime,
> except
> > for
> > experimental deployments. You need to be all set before runtime
> starts.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > ср, 12 авг. 2020 г. в 09:48, Petr Ivanov <mr...@gmail.com>:
> >
> > > Hi, Val.
> > >
> > > > On 12 Aug 2020, at 01:31, Valentin Kulichenko <
> > > valentin.kulichenko@gmail.com> wrote:
> > > >
> > > > Hi Petr,
> > > >
> > > > I agree -- we should better modularize the platform. The
> current
> > way if
> > > very error-prone, especially during upgrades -- any changes
> made
> > within
> > > IGNITE_HOME (configs, scripts, modules, etc.) must be merged
> with a
> > new
> > > version of the package. There is no standard way of doing this.
> > > >
> > > > However, I'm a bit concerned with your suggestion regarding
> custom
> > > dependency management. Can you please elaborate on how you
> think it
> > should
> > > work? Are there tools we can reuse for this purpose? I would
> try to
> > avoid
> > > reinventing the wheel.
> > >
> > > I see it as a a2enmod | 2dismod analog of Apache2.
> > >
> > > We build and store Apache Ignite and its modules as separate
> binaries
> > > (binary per module) then use custom script that will know
> where to
> > download
> > > necessary module. Or possibly use modified ignite.sh to specify
> > required
> > > 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.
> > >
> > >
> > > >
> > > > -Val
> > > >
> > > > On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov <
> mr.weider@gmail.com
> > > <ma...@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
> > starting
> > > Ignite and all other modules and parts of the project
> (benchmarks,
> > > examples, etc.) packed in their own binary which can be added
> via
> > custom
> > > dependency management tool (i.e. modules.sh)
> > > > — same distribution for RPM and DEB packages but with
> modules
> > packed as
> > > separate ones (PHP for example)
> > > > — separate thin client release cycle with custom versioning
> > > > Possibly, we can we add additional section to the document
> you
> > > introduced for this part.
> > > >
> > > > Also, it seems that full JDK11 support (including building)
> would
> > be a
> > > huge milestone and a sign of healthy modern project that tends
> to be
> > on the
> > > verge of mainstream technologies and not the stockpile of
> legacy
> > leftovers
> > > (fully support Iliya in removing all that was deprecated and/or
> > marked as
> > > unused anymore).
> > > >
> > > >
> > > > > On 8 Aug 2020, at 02:00, Valentin Kulichenko <
> > > valentin.kulichenko@gmail.com <mailto:
> valentin.kulichenko@gmail.com
> > >>
> > > wrote:
> > > > >
> > > > > Igniters,
> > > > >
> > > > > I've created the page:
> > > > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> > <
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> > >
> > > > >
> > > > > 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 the consensus on the proposed
> changes,
> > I will
> > > > > start creating tickets in Jira and a more detailed plan.
> > > > >
> > > > > -Val
> > > > >
> > > > > On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <
> > saikat.maitra@gmail.com
> > > <ma...@gmail.com>>
> > > > > wrote:
> > > > >
> > > > >> Hi Denis, Val
> > > > >>
> > > > >> Thank you for your reply and really appreciate it. It
> will be
> > very
> > > cool to
> > > > >> be able to connect and plan release together and learn
> more
> > about
> > > Ignite in
> > > > >> the process :)
> > > > >>
> > > > >> Regards
> > > > >> Saikat
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko <
> > > > >> valentin.kulichenko@gmail.com <mailto:
> > valentin.kulichenko@gmail.com>>
> > > wrote:
> > > > >>
> > > > >>> Hi Saikat,
> > > > >>>
> > > > >>> That surely is a great idea. We will work together with
> Denis
> > on
> > > setting
> > > > >>> this up in the nearest future.
> > > > >>>
> > > > >>> -Val
> > > > >>>
> > > > >>> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <
> dmagda@apache.org
> > > <ma...@apache.org>> wrote:
> > > > >>>
> > > > >>>> Saikat,
> > > > >>>>
> > > > >>>> Fully support your idea on a virtual meetup! Once Val
> > collects and
> > > > >>> outlines
> > > > >>>> the main changes with directions on wiki, we’ll go
> ahead and
> > > schedule
> > > > >> the
> > > > >>>> meetup to talk things out in a bit more detail. We’ll
> use our
> > new
> > > > >> Virtual
> > > > >>>> Ignite Meetup group for that inviting both Ignite
> > contributors and
> > > > >>>> application developers.
> > > > >>>>
> > > > >>>> Denis
> > > > >>>>
> > > > >>>> On Thursday, August 6, 2020, Saikat Maitra <
> > saikat.maitra@gmail.com
> > > <ma...@gmail.com>>
> > > > >>>> wrote:
> > > > >>>>
> > > > >>>>> Hi Valentin
> > > > >>>>>
> > > > >>>>> Thank you for sharing and starting the thread. I am
> thinking
> > if it
> > > > >> will
> > > > >>>> be
> > > > >>>>> a good idea to have a virtual meet setup to discuss on
> the
> > release
> > > > >>>>> planning.
> > > > >>>>>
> > > > >>>>> It will help to learn more individual features to be
> added
> > and also
> > > > >> to
> > > > >>>>> understand about features that have been deprecated and
> > scheduled
> > > for
> > > > >>>>> removal in Ignite 3.0 release. Also it will help
> community
> > member
> > > to
> > > > >>>>> connect in real time and ask questions and share
> feedback.
> > > > >>>>>
> > > > >>>>> Regards,
> > > > >>>>> Saikat
> > > > >>>>>
> > > > >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <
> > > > >>>> ilya.kasnacheev@gmail.com <mailto:
> ilya.kasnacheev@gmail.com>>
> > > > >>>>> wrote:
> > > > >>>>>
> > > > >>>>>> Hello!
> > > > >>>>>>
> > > > >>>>>> I hope to see Apache Ignite release 3.0 as API
> trimming
> > release.
> > > > >> Let
> > > > >>> us
> > > > >>>>>> correct external and internal APIs for which we have
> better
> > ideas
> > > > >>> now,
> > > > >>>> as
> > > > >>>>>> well as remove old and deprecated code.
> > > > >>>>>>
> > > > >>>>>> We may also introduce new configuration mechanisms and
> > user-facing
> > > > >>> API
> > > > >>>>>> (such as cache-less native SQL queries), but this we
> could
> > > > >> prototype
> > > > >>>>> before
> > > > >>>>>> starting the 3.0 task.
> > > > >>>>>>
> > > > >>>>>> I will advise against targeting large new features at
> 3.0.
> > They
> > > can
> > > > >>> be
> > > > >>>>>> added in subsequent point releases, whereas we can't
> really
> > remove
> > > > >> or
> > > > >>>>>> remodel stuff in point releases.
> > > > >>>>>>
> > > > >>>>>> Regards,
> > > > >>>>>> --
> > > > >>>>>> Ilya Kasnacheev
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
> > > > >>>>>> valentin.kulichenko@gmail.com <mailto:
> > > valentin.kulichenko@gmail.com>>:
> > > > >>>>>>
> > > > >>>>>>> Igniters,
> > > > >>>>>>>
> > > > >>>>>>> I would like to kick off a discussion regarding
> Ignite 3.0.
> > > > >> Ignite
> > > > >>>> 2.0
> > > > >>>>>>> exists for more than 3 years now and we've already
> > collected a
> > > > >>>>>> significant
> > > > >>>>>>> list [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://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> > <
> > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> > >
> > > > >>>>> Apache+Ignite+3.0+Wishlist
> > > > >>>>>>>
> > > > >>>>>>> Regards,
> > > > >>>>>>> Val
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> --
> > > > >>>> -
> > > > >>>> Denis
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > >
> > >
> >
> >
> >
>
>
>
Re: Apache Ignite 3.0
Posted by "Carbone, Adam" <Ad...@bottomline.com>.
If you want to make is simpler to have the components that you want, but have that be immutable at install time you could take an approach similar to the way spring does it with their initializer ( https://start.spring.io/ ) as an example... Basically the concept being something that produces a set of configurations that are used to define what the environment looks like ( these could be k8s objects ) they could be spring-configuration objects? They could be something that you develop all upon ignite ( probably wouldn’t recommend this approach ) there seems to be plenty of these types of things already
Example
* https://spring.io/guides/gs/centralized-configuration
* https://cocoon.apache.org/subprojects/configuration/spring-configurator/index.html
And I'm by no means saying to use spring these are just examples that I came across
I'm thinking the outcome needs to be a platform config of source ( that can be checked in for those doing gitops ) and maybe ends up as a config map for those doing k8s, and some other fashion for those doing something else.
Honestly I am not deep enough into the internals of ignite to know how this might work for the platform, was more describing what I'm seeing from a bigger picture trend
Regards
Adam Carbone | Director of Innovation – Intelligent Platform Team | Bottomline Technologies
Office: 603-501-6446 | Mobile: 603-570-8418
www.bottomline.com
On 8/13/20, 7:55 PM, "Valentin Kulichenko" <va...@gmail.com> wrote:
Hi Ilya,
Can you please describe your vision of how it should work?
Let's say, I want to set up a cluster of several standalone server nodes
with a couple of optional modules enabled. What are my steps?
-Val
On Thu, Aug 13, 2020 at 6:03 AM Carbone, Adam <Ad...@bottomline.com>
wrote:
> Good Morning from the EastCoast
>
> I have to agree that the larger industry is tending towards immutability,
> and that you build once and test, then you promote/migrate that immutable
> binary object, be is a library or a docker image etc... however there are
> still patterns that allow you to determine at install/or deployment time (
> helm as an example, you choose based on your values what the package
> installs/provides ) It just isn't decided at runtime but install and often
> in a gitops type world that is determined by configuration as code. I think
> run time is difficult to manage especially in our increasingly
> containerized world.
>
> Regards.
>
> Adam Carbone | Director of Innovation – Intelligent Platform Team |
> Bottomline Technologies
> Office: 603-501-6446 | Mobile: 603-570-8418
> www.bottomline.com
>
>
>
> On 8/13/20, 8:01 AM, "Ilya Kasnacheev" <il...@gmail.com> wrote:
>
> Hello!
>
> On the contrary, I would suggest that apache2 way was outdated even at
> times when apache was all rage.
>
> Now the nginx approach is prevalent: on devops phase, assemble a custom
> bundle with all plugins included, store it somewhere, and ship it to
> production as a whole to remove any on-the-fly uncertainty from
> production.
>
> This is what docker does, but also maven, which downloads dependencies
> during build. You do not need to download anything in runtime, except
> for
> experimental deployments. You need to be all set before runtime starts.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 12 авг. 2020 г. в 09:48, Petr Ivanov <mr...@gmail.com>:
>
> > Hi, Val.
> >
> > > On 12 Aug 2020, at 01:31, Valentin Kulichenko <
> > valentin.kulichenko@gmail.com> wrote:
> > >
> > > Hi Petr,
> > >
> > > I agree -- we should better modularize the platform. The current
> way if
> > very error-prone, especially during upgrades -- any changes made
> within
> > IGNITE_HOME (configs, scripts, modules, etc.) must be merged with a
> new
> > version of the package. There is no standard way of doing this.
> > >
> > > However, I'm a bit concerned with your suggestion regarding custom
> > dependency management. Can you please elaborate on how you think it
> should
> > work? Are there tools we can reuse for this purpose? I would try to
> avoid
> > reinventing the wheel.
> >
> > I see it as a a2enmod | 2dismod analog of Apache2.
> >
> > We build and store Apache Ignite and its modules as separate binaries
> > (binary per module) then use custom script that will know where to
> download
> > necessary module. Or possibly use modified ignite.sh to specify
> required
> > 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.
> >
> >
> > >
> > > -Val
> > >
> > > On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov <mr.weider@gmail.com
> > <ma...@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
> starting
> > Ignite and all other modules and parts of the project (benchmarks,
> > examples, etc.) packed in their own binary which can be added via
> custom
> > dependency management tool (i.e. modules.sh)
> > > — same distribution for RPM and DEB packages but with modules
> packed as
> > separate ones (PHP for example)
> > > — separate thin client release cycle with custom versioning
> > > Possibly, we can we add additional section to the document you
> > introduced for this part.
> > >
> > > Also, it seems that full JDK11 support (including building) would
> be a
> > huge milestone and a sign of healthy modern project that tends to be
> on the
> > verge of mainstream technologies and not the stockpile of legacy
> leftovers
> > (fully support Iliya in removing all that was deprecated and/or
> marked as
> > unused anymore).
> > >
> > >
> > > > On 8 Aug 2020, at 02:00, Valentin Kulichenko <
> > valentin.kulichenko@gmail.com <mailto:valentin.kulichenko@gmail.com
> >>
> > wrote:
> > > >
> > > > Igniters,
> > > >
> > > > I've created the page:
> > > >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> <
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> >
> > > >
> > > > 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 the consensus on the proposed changes,
> I will
> > > > start creating tickets in Jira and a more detailed plan.
> > > >
> > > > -Val
> > > >
> > > > On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <
> saikat.maitra@gmail.com
> > <ma...@gmail.com>>
> > > > wrote:
> > > >
> > > >> Hi Denis, Val
> > > >>
> > > >> Thank you for your reply and really appreciate it. It will be
> very
> > cool to
> > > >> be able to connect and plan release together and learn more
> about
> > Ignite in
> > > >> the process :)
> > > >>
> > > >> Regards
> > > >> Saikat
> > > >>
> > > >>
> > > >>
> > > >> On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko <
> > > >> valentin.kulichenko@gmail.com <mailto:
> valentin.kulichenko@gmail.com>>
> > wrote:
> > > >>
> > > >>> Hi Saikat,
> > > >>>
> > > >>> That surely is a great idea. We will work together with Denis
> on
> > setting
> > > >>> this up in the nearest future.
> > > >>>
> > > >>> -Val
> > > >>>
> > > >>> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <dmagda@apache.org
> > <ma...@apache.org>> wrote:
> > > >>>
> > > >>>> Saikat,
> > > >>>>
> > > >>>> Fully support your idea on a virtual meetup! Once Val
> collects and
> > > >>> outlines
> > > >>>> the main changes with directions on wiki, we’ll go ahead and
> > schedule
> > > >> the
> > > >>>> meetup to talk things out in a bit more detail. We’ll use our
> new
> > > >> Virtual
> > > >>>> Ignite Meetup group for that inviting both Ignite
> contributors and
> > > >>>> application developers.
> > > >>>>
> > > >>>> Denis
> > > >>>>
> > > >>>> On Thursday, August 6, 2020, Saikat Maitra <
> saikat.maitra@gmail.com
> > <ma...@gmail.com>>
> > > >>>> wrote:
> > > >>>>
> > > >>>>> Hi Valentin
> > > >>>>>
> > > >>>>> Thank you for sharing and starting the thread. I am thinking
> if it
> > > >> will
> > > >>>> be
> > > >>>>> a good idea to have a virtual meet setup to discuss on the
> release
> > > >>>>> planning.
> > > >>>>>
> > > >>>>> It will help to learn more individual features to be added
> and also
> > > >> to
> > > >>>>> understand about features that have been deprecated and
> scheduled
> > for
> > > >>>>> removal in Ignite 3.0 release. Also it will help community
> member
> > to
> > > >>>>> connect in real time and ask questions and share feedback.
> > > >>>>>
> > > >>>>> Regards,
> > > >>>>> Saikat
> > > >>>>>
> > > >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <
> > > >>>> ilya.kasnacheev@gmail.com <ma...@gmail.com>>
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>>> Hello!
> > > >>>>>>
> > > >>>>>> I hope to see Apache Ignite release 3.0 as API trimming
> release.
> > > >> Let
> > > >>> us
> > > >>>>>> correct external and internal APIs for which we have better
> ideas
> > > >>> now,
> > > >>>> as
> > > >>>>>> well as remove old and deprecated code.
> > > >>>>>>
> > > >>>>>> We may also introduce new configuration mechanisms and
> user-facing
> > > >>> API
> > > >>>>>> (such as cache-less native SQL queries), but this we could
> > > >> prototype
> > > >>>>> before
> > > >>>>>> starting the 3.0 task.
> > > >>>>>>
> > > >>>>>> I will advise against targeting large new features at 3.0.
> They
> > can
> > > >>> be
> > > >>>>>> added in subsequent point releases, whereas we can't really
> remove
> > > >> or
> > > >>>>>> remodel stuff in point releases.
> > > >>>>>>
> > > >>>>>> Regards,
> > > >>>>>> --
> > > >>>>>> Ilya Kasnacheev
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
> > > >>>>>> valentin.kulichenko@gmail.com <mailto:
> > valentin.kulichenko@gmail.com>>:
> > > >>>>>>
> > > >>>>>>> Igniters,
> > > >>>>>>>
> > > >>>>>>> I would like to kick off a discussion regarding Ignite 3.0.
> > > >> Ignite
> > > >>>> 2.0
> > > >>>>>>> exists for more than 3 years now and we've already
> collected a
> > > >>>>>> significant
> > > >>>>>>> list [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://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> <
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> >
> > > >>>>> Apache+Ignite+3.0+Wishlist
> > > >>>>>>>
> > > >>>>>>> Regards,
> > > >>>>>>> Val
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> -
> > > >>>> Denis
> > > >>>>
> > > >>>
> > > >>
> > >
> >
> >
>
>
>
Re: Apache Ignite 3.0
Posted by Valentin Kulichenko <va...@gmail.com>.
Hi Ilya,
Can you please describe your vision of how it should work?
Let's say, I want to set up a cluster of several standalone server nodes
with a couple of optional modules enabled. What are my steps?
-Val
On Thu, Aug 13, 2020 at 6:03 AM Carbone, Adam <Ad...@bottomline.com>
wrote:
> Good Morning from the EastCoast
>
> I have to agree that the larger industry is tending towards immutability,
> and that you build once and test, then you promote/migrate that immutable
> binary object, be is a library or a docker image etc... however there are
> still patterns that allow you to determine at install/or deployment time (
> helm as an example, you choose based on your values what the package
> installs/provides ) It just isn't decided at runtime but install and often
> in a gitops type world that is determined by configuration as code. I think
> run time is difficult to manage especially in our increasingly
> containerized world.
>
> Regards.
>
> Adam Carbone | Director of Innovation – Intelligent Platform Team |
> Bottomline Technologies
> Office: 603-501-6446 | Mobile: 603-570-8418
> www.bottomline.com
>
>
>
> On 8/13/20, 8:01 AM, "Ilya Kasnacheev" <il...@gmail.com> wrote:
>
> Hello!
>
> On the contrary, I would suggest that apache2 way was outdated even at
> times when apache was all rage.
>
> Now the nginx approach is prevalent: on devops phase, assemble a custom
> bundle with all plugins included, store it somewhere, and ship it to
> production as a whole to remove any on-the-fly uncertainty from
> production.
>
> This is what docker does, but also maven, which downloads dependencies
> during build. You do not need to download anything in runtime, except
> for
> experimental deployments. You need to be all set before runtime starts.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 12 авг. 2020 г. в 09:48, Petr Ivanov <mr...@gmail.com>:
>
> > Hi, Val.
> >
> > > On 12 Aug 2020, at 01:31, Valentin Kulichenko <
> > valentin.kulichenko@gmail.com> wrote:
> > >
> > > Hi Petr,
> > >
> > > I agree -- we should better modularize the platform. The current
> way if
> > very error-prone, especially during upgrades -- any changes made
> within
> > IGNITE_HOME (configs, scripts, modules, etc.) must be merged with a
> new
> > version of the package. There is no standard way of doing this.
> > >
> > > However, I'm a bit concerned with your suggestion regarding custom
> > dependency management. Can you please elaborate on how you think it
> should
> > work? Are there tools we can reuse for this purpose? I would try to
> avoid
> > reinventing the wheel.
> >
> > I see it as a a2enmod | 2dismod analog of Apache2.
> >
> > We build and store Apache Ignite and its modules as separate binaries
> > (binary per module) then use custom script that will know where to
> download
> > necessary module. Or possibly use modified ignite.sh to specify
> required
> > 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.
> >
> >
> > >
> > > -Val
> > >
> > > On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov <mr.weider@gmail.com
> > <ma...@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
> starting
> > Ignite and all other modules and parts of the project (benchmarks,
> > examples, etc.) packed in their own binary which can be added via
> custom
> > dependency management tool (i.e. modules.sh)
> > > — same distribution for RPM and DEB packages but with modules
> packed as
> > separate ones (PHP for example)
> > > — separate thin client release cycle with custom versioning
> > > Possibly, we can we add additional section to the document you
> > introduced for this part.
> > >
> > > Also, it seems that full JDK11 support (including building) would
> be a
> > huge milestone and a sign of healthy modern project that tends to be
> on the
> > verge of mainstream technologies and not the stockpile of legacy
> leftovers
> > (fully support Iliya in removing all that was deprecated and/or
> marked as
> > unused anymore).
> > >
> > >
> > > > On 8 Aug 2020, at 02:00, Valentin Kulichenko <
> > valentin.kulichenko@gmail.com <mailto:valentin.kulichenko@gmail.com
> >>
> > wrote:
> > > >
> > > > Igniters,
> > > >
> > > > I've created the page:
> > > >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> <
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$
> >
> > > >
> > > > 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 the consensus on the proposed changes,
> I will
> > > > start creating tickets in Jira and a more detailed plan.
> > > >
> > > > -Val
> > > >
> > > > On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <
> saikat.maitra@gmail.com
> > <ma...@gmail.com>>
> > > > wrote:
> > > >
> > > >> Hi Denis, Val
> > > >>
> > > >> Thank you for your reply and really appreciate it. It will be
> very
> > cool to
> > > >> be able to connect and plan release together and learn more
> about
> > Ignite in
> > > >> the process :)
> > > >>
> > > >> Regards
> > > >> Saikat
> > > >>
> > > >>
> > > >>
> > > >> On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko <
> > > >> valentin.kulichenko@gmail.com <mailto:
> valentin.kulichenko@gmail.com>>
> > wrote:
> > > >>
> > > >>> Hi Saikat,
> > > >>>
> > > >>> That surely is a great idea. We will work together with Denis
> on
> > setting
> > > >>> this up in the nearest future.
> > > >>>
> > > >>> -Val
> > > >>>
> > > >>> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <dmagda@apache.org
> > <ma...@apache.org>> wrote:
> > > >>>
> > > >>>> Saikat,
> > > >>>>
> > > >>>> Fully support your idea on a virtual meetup! Once Val
> collects and
> > > >>> outlines
> > > >>>> the main changes with directions on wiki, we’ll go ahead and
> > schedule
> > > >> the
> > > >>>> meetup to talk things out in a bit more detail. We’ll use our
> new
> > > >> Virtual
> > > >>>> Ignite Meetup group for that inviting both Ignite
> contributors and
> > > >>>> application developers.
> > > >>>>
> > > >>>> Denis
> > > >>>>
> > > >>>> On Thursday, August 6, 2020, Saikat Maitra <
> saikat.maitra@gmail.com
> > <ma...@gmail.com>>
> > > >>>> wrote:
> > > >>>>
> > > >>>>> Hi Valentin
> > > >>>>>
> > > >>>>> Thank you for sharing and starting the thread. I am thinking
> if it
> > > >> will
> > > >>>> be
> > > >>>>> a good idea to have a virtual meet setup to discuss on the
> release
> > > >>>>> planning.
> > > >>>>>
> > > >>>>> It will help to learn more individual features to be added
> and also
> > > >> to
> > > >>>>> understand about features that have been deprecated and
> scheduled
> > for
> > > >>>>> removal in Ignite 3.0 release. Also it will help community
> member
> > to
> > > >>>>> connect in real time and ask questions and share feedback.
> > > >>>>>
> > > >>>>> Regards,
> > > >>>>> Saikat
> > > >>>>>
> > > >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <
> > > >>>> ilya.kasnacheev@gmail.com <ma...@gmail.com>>
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>>> Hello!
> > > >>>>>>
> > > >>>>>> I hope to see Apache Ignite release 3.0 as API trimming
> release.
> > > >> Let
> > > >>> us
> > > >>>>>> correct external and internal APIs for which we have better
> ideas
> > > >>> now,
> > > >>>> as
> > > >>>>>> well as remove old and deprecated code.
> > > >>>>>>
> > > >>>>>> We may also introduce new configuration mechanisms and
> user-facing
> > > >>> API
> > > >>>>>> (such as cache-less native SQL queries), but this we could
> > > >> prototype
> > > >>>>> before
> > > >>>>>> starting the 3.0 task.
> > > >>>>>>
> > > >>>>>> I will advise against targeting large new features at 3.0.
> They
> > can
> > > >>> be
> > > >>>>>> added in subsequent point releases, whereas we can't really
> remove
> > > >> or
> > > >>>>>> remodel stuff in point releases.
> > > >>>>>>
> > > >>>>>> Regards,
> > > >>>>>> --
> > > >>>>>> Ilya Kasnacheev
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
> > > >>>>>> valentin.kulichenko@gmail.com <mailto:
> > valentin.kulichenko@gmail.com>>:
> > > >>>>>>
> > > >>>>>>> Igniters,
> > > >>>>>>>
> > > >>>>>>> I would like to kick off a discussion regarding Ignite 3.0.
> > > >> Ignite
> > > >>>> 2.0
> > > >>>>>>> exists for more than 3 years now and we've already
> collected a
> > > >>>>>> significant
> > > >>>>>>> list [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://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> <
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$
> >
> > > >>>>> Apache+Ignite+3.0+Wishlist
> > > >>>>>>>
> > > >>>>>>> Regards,
> > > >>>>>>> Val
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> -
> > > >>>> Denis
> > > >>>>
> > > >>>
> > > >>
> > >
> >
> >
>
>
>
Re: Apache Ignite 3.0
Posted by "Carbone, Adam" <Ad...@bottomline.com>.
Good Morning from the EastCoast
I have to agree that the larger industry is tending towards immutability, and that you build once and test, then you promote/migrate that immutable binary object, be is a library or a docker image etc... however there are still patterns that allow you to determine at install/or deployment time ( helm as an example, you choose based on your values what the package installs/provides ) It just isn't decided at runtime but install and often in a gitops type world that is determined by configuration as code. I think run time is difficult to manage especially in our increasingly containerized world.
Regards.
Adam Carbone | Director of Innovation – Intelligent Platform Team | Bottomline Technologies
Office: 603-501-6446 | Mobile: 603-570-8418
www.bottomline.com
On 8/13/20, 8:01 AM, "Ilya Kasnacheev" <il...@gmail.com> wrote:
Hello!
On the contrary, I would suggest that apache2 way was outdated even at
times when apache was all rage.
Now the nginx approach is prevalent: on devops phase, assemble a custom
bundle with all plugins included, store it somewhere, and ship it to
production as a whole to remove any on-the-fly uncertainty from production.
This is what docker does, but also maven, which downloads dependencies
during build. You do not need to download anything in runtime, except for
experimental deployments. You need to be all set before runtime starts.
Regards,
--
Ilya Kasnacheev
ср, 12 авг. 2020 г. в 09:48, Petr Ivanov <mr...@gmail.com>:
> Hi, Val.
>
> > On 12 Aug 2020, at 01:31, Valentin Kulichenko <
> valentin.kulichenko@gmail.com> wrote:
> >
> > Hi Petr,
> >
> > I agree -- we should better modularize the platform. The current way if
> very error-prone, especially during upgrades -- any changes made within
> IGNITE_HOME (configs, scripts, modules, etc.) must be merged with a new
> version of the package. There is no standard way of doing this.
> >
> > However, I'm a bit concerned with your suggestion regarding custom
> dependency management. Can you please elaborate on how you think it should
> work? Are there tools we can reuse for this purpose? I would try to avoid
> reinventing the wheel.
>
> I see it as a a2enmod | 2dismod analog of Apache2.
>
> We build and store Apache Ignite and its modules as separate binaries
> (binary per module) then use custom script that will know where to download
> necessary module. Or possibly use modified ignite.sh to specify required
> 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.
>
>
> >
> > -Val
> >
> > On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov <mr.weider@gmail.com
> <ma...@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 starting
> Ignite and all other modules and parts of the project (benchmarks,
> examples, etc.) packed in their own binary which can be added via custom
> dependency management tool (i.e. modules.sh)
> > — same distribution for RPM and DEB packages but with modules packed as
> separate ones (PHP for example)
> > — separate thin client release cycle with custom versioning
> > Possibly, we can we add additional section to the document you
> introduced for this part.
> >
> > Also, it seems that full JDK11 support (including building) would be a
> huge milestone and a sign of healthy modern project that tends to be on the
> verge of mainstream technologies and not the stockpile of legacy leftovers
> (fully support Iliya in removing all that was deprecated and/or marked as
> unused anymore).
> >
> >
> > > On 8 Aug 2020, at 02:00, Valentin Kulichenko <
> valentin.kulichenko@gmail.com <ma...@gmail.com>>
> wrote:
> > >
> > > Igniters,
> > >
> > > I've created the page:
> > > https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$ <
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0__;Kys!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpm9uWJo_$ >
> > >
> > > 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 the consensus on the proposed changes, I will
> > > start creating tickets in Jira and a more detailed plan.
> > >
> > > -Val
> > >
> > > On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <saikat.maitra@gmail.com
> <ma...@gmail.com>>
> > > wrote:
> > >
> > >> Hi Denis, Val
> > >>
> > >> Thank you for your reply and really appreciate it. It will be very
> cool to
> > >> be able to connect and plan release together and learn more about
> Ignite in
> > >> the process :)
> > >>
> > >> Regards
> > >> Saikat
> > >>
> > >>
> > >>
> > >> On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko <
> > >> valentin.kulichenko@gmail.com <ma...@gmail.com>>
> wrote:
> > >>
> > >>> Hi Saikat,
> > >>>
> > >>> That surely is a great idea. We will work together with Denis on
> setting
> > >>> this up in the nearest future.
> > >>>
> > >>> -Val
> > >>>
> > >>> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <dmagda@apache.org
> <ma...@apache.org>> wrote:
> > >>>
> > >>>> Saikat,
> > >>>>
> > >>>> Fully support your idea on a virtual meetup! Once Val collects and
> > >>> outlines
> > >>>> the main changes with directions on wiki, we’ll go ahead and
> schedule
> > >> the
> > >>>> meetup to talk things out in a bit more detail. We’ll use our new
> > >> Virtual
> > >>>> Ignite Meetup group for that inviting both Ignite contributors and
> > >>>> application developers.
> > >>>>
> > >>>> Denis
> > >>>>
> > >>>> On Thursday, August 6, 2020, Saikat Maitra <saikat.maitra@gmail.com
> <ma...@gmail.com>>
> > >>>> wrote:
> > >>>>
> > >>>>> Hi Valentin
> > >>>>>
> > >>>>> Thank you for sharing and starting the thread. I am thinking if it
> > >> will
> > >>>> be
> > >>>>> a good idea to have a virtual meet setup to discuss on the release
> > >>>>> planning.
> > >>>>>
> > >>>>> It will help to learn more individual features to be added and also
> > >> to
> > >>>>> understand about features that have been deprecated and scheduled
> for
> > >>>>> removal in Ignite 3.0 release. Also it will help community member
> to
> > >>>>> connect in real time and ask questions and share feedback.
> > >>>>>
> > >>>>> Regards,
> > >>>>> Saikat
> > >>>>>
> > >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <
> > >>>> ilya.kasnacheev@gmail.com <ma...@gmail.com>>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> Hello!
> > >>>>>>
> > >>>>>> I hope to see Apache Ignite release 3.0 as API trimming release.
> > >> Let
> > >>> us
> > >>>>>> correct external and internal APIs for which we have better ideas
> > >>> now,
> > >>>> as
> > >>>>>> well as remove old and deprecated code.
> > >>>>>>
> > >>>>>> We may also introduce new configuration mechanisms and user-facing
> > >>> API
> > >>>>>> (such as cache-less native SQL queries), but this we could
> > >> prototype
> > >>>>> before
> > >>>>>> starting the 3.0 task.
> > >>>>>>
> > >>>>>> I will advise against targeting large new features at 3.0. They
> can
> > >>> be
> > >>>>>> added in subsequent point releases, whereas we can't really remove
> > >> or
> > >>>>>> remodel stuff in point releases.
> > >>>>>>
> > >>>>>> Regards,
> > >>>>>> --
> > >>>>>> Ilya Kasnacheev
> > >>>>>>
> > >>>>>>
> > >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
> > >>>>>> valentin.kulichenko@gmail.com <mailto:
> valentin.kulichenko@gmail.com>>:
> > >>>>>>
> > >>>>>>> Igniters,
> > >>>>>>>
> > >>>>>>> I would like to kick off a discussion regarding Ignite 3.0.
> > >> Ignite
> > >>>> 2.0
> > >>>>>>> exists for more than 3 years now and we've already collected a
> > >>>>>> significant
> > >>>>>>> list [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://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$ <
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/__;!!O3mv9RujDHg!2GlQzPzSAyxjW5tzyIzjaVVuR5_U_s65MCFLww8yIHRMzDqSrm5C2nkXYQErpp6mV7IJ$ >
> > >>>>> Apache+Ignite+3.0+Wishlist
> > >>>>>>>
> > >>>>>>> Regards,
> > >>>>>>> Val
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> -
> > >>>> Denis
> > >>>>
> > >>>
> > >>
> >
>
>
Re: Apache Ignite 3.0
Posted by Ilya Kasnacheev <il...@gmail.com>.
Hello!
On the contrary, I would suggest that apache2 way was outdated even at
times when apache was all rage.
Now the nginx approach is prevalent: on devops phase, assemble a custom
bundle with all plugins included, store it somewhere, and ship it to
production as a whole to remove any on-the-fly uncertainty from production.
This is what docker does, but also maven, which downloads dependencies
during build. You do not need to download anything in runtime, except for
experimental deployments. You need to be all set before runtime starts.
Regards,
--
Ilya Kasnacheev
ср, 12 авг. 2020 г. в 09:48, Petr Ivanov <mr...@gmail.com>:
> Hi, Val.
>
> > On 12 Aug 2020, at 01:31, Valentin Kulichenko <
> valentin.kulichenko@gmail.com> wrote:
> >
> > Hi Petr,
> >
> > I agree -- we should better modularize the platform. The current way if
> very error-prone, especially during upgrades -- any changes made within
> IGNITE_HOME (configs, scripts, modules, etc.) must be merged with a new
> version of the package. There is no standard way of doing this.
> >
> > However, I'm a bit concerned with your suggestion regarding custom
> dependency management. Can you please elaborate on how you think it should
> work? Are there tools we can reuse for this purpose? I would try to avoid
> reinventing the wheel.
>
> I see it as a a2enmod | 2dismod analog of Apache2.
>
> We build and store Apache Ignite and its modules as separate binaries
> (binary per module) then use custom script that will know where to download
> necessary module. Or possibly use modified ignite.sh to specify required
> 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.
>
>
> >
> > -Val
> >
> > On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov <mr.weider@gmail.com
> <ma...@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 starting
> Ignite and all other modules and parts of the project (benchmarks,
> examples, etc.) packed in their own binary which can be added via custom
> dependency management tool (i.e. modules.sh)
> > — same distribution for RPM and DEB packages but with modules packed as
> separate ones (PHP for example)
> > — separate thin client release cycle with custom versioning
> > Possibly, we can we add additional section to the document you
> introduced for this part.
> >
> > Also, it seems that full JDK11 support (including building) would be a
> huge milestone and a sign of healthy modern project that tends to be on the
> verge of mainstream technologies and not the stockpile of legacy leftovers
> (fully support Iliya in removing all that was deprecated and/or marked as
> unused anymore).
> >
> >
> > > On 8 Aug 2020, at 02:00, Valentin Kulichenko <
> valentin.kulichenko@gmail.com <ma...@gmail.com>>
> wrote:
> > >
> > > Igniters,
> > >
> > > I've created the page:
> > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0 <
> 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 the consensus on the proposed changes, I will
> > > start creating tickets in Jira and a more detailed plan.
> > >
> > > -Val
> > >
> > > On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <saikat.maitra@gmail.com
> <ma...@gmail.com>>
> > > wrote:
> > >
> > >> Hi Denis, Val
> > >>
> > >> Thank you for your reply and really appreciate it. It will be very
> cool to
> > >> be able to connect and plan release together and learn more about
> Ignite in
> > >> the process :)
> > >>
> > >> Regards
> > >> Saikat
> > >>
> > >>
> > >>
> > >> On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko <
> > >> valentin.kulichenko@gmail.com <ma...@gmail.com>>
> wrote:
> > >>
> > >>> Hi Saikat,
> > >>>
> > >>> That surely is a great idea. We will work together with Denis on
> setting
> > >>> this up in the nearest future.
> > >>>
> > >>> -Val
> > >>>
> > >>> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <dmagda@apache.org
> <ma...@apache.org>> wrote:
> > >>>
> > >>>> Saikat,
> > >>>>
> > >>>> Fully support your idea on a virtual meetup! Once Val collects and
> > >>> outlines
> > >>>> the main changes with directions on wiki, we’ll go ahead and
> schedule
> > >> the
> > >>>> meetup to talk things out in a bit more detail. We’ll use our new
> > >> Virtual
> > >>>> Ignite Meetup group for that inviting both Ignite contributors and
> > >>>> application developers.
> > >>>>
> > >>>> Denis
> > >>>>
> > >>>> On Thursday, August 6, 2020, Saikat Maitra <saikat.maitra@gmail.com
> <ma...@gmail.com>>
> > >>>> wrote:
> > >>>>
> > >>>>> Hi Valentin
> > >>>>>
> > >>>>> Thank you for sharing and starting the thread. I am thinking if it
> > >> will
> > >>>> be
> > >>>>> a good idea to have a virtual meet setup to discuss on the release
> > >>>>> planning.
> > >>>>>
> > >>>>> It will help to learn more individual features to be added and also
> > >> to
> > >>>>> understand about features that have been deprecated and scheduled
> for
> > >>>>> removal in Ignite 3.0 release. Also it will help community member
> to
> > >>>>> connect in real time and ask questions and share feedback.
> > >>>>>
> > >>>>> Regards,
> > >>>>> Saikat
> > >>>>>
> > >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <
> > >>>> ilya.kasnacheev@gmail.com <ma...@gmail.com>>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> Hello!
> > >>>>>>
> > >>>>>> I hope to see Apache Ignite release 3.0 as API trimming release.
> > >> Let
> > >>> us
> > >>>>>> correct external and internal APIs for which we have better ideas
> > >>> now,
> > >>>> as
> > >>>>>> well as remove old and deprecated code.
> > >>>>>>
> > >>>>>> We may also introduce new configuration mechanisms and user-facing
> > >>> API
> > >>>>>> (such as cache-less native SQL queries), but this we could
> > >> prototype
> > >>>>> before
> > >>>>>> starting the 3.0 task.
> > >>>>>>
> > >>>>>> I will advise against targeting large new features at 3.0. They
> can
> > >>> be
> > >>>>>> added in subsequent point releases, whereas we can't really remove
> > >> or
> > >>>>>> remodel stuff in point releases.
> > >>>>>>
> > >>>>>> Regards,
> > >>>>>> --
> > >>>>>> Ilya Kasnacheev
> > >>>>>>
> > >>>>>>
> > >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
> > >>>>>> valentin.kulichenko@gmail.com <mailto:
> valentin.kulichenko@gmail.com>>:
> > >>>>>>
> > >>>>>>> Igniters,
> > >>>>>>>
> > >>>>>>> I would like to kick off a discussion regarding Ignite 3.0.
> > >> Ignite
> > >>>> 2.0
> > >>>>>>> exists for more than 3 years now and we've already collected a
> > >>>>>> significant
> > >>>>>>> list [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/ <
> https://cwiki.apache.org/confluence/display/IGNITE/>
> > >>>>> Apache+Ignite+3.0+Wishlist
> > >>>>>>>
> > >>>>>>> Regards,
> > >>>>>>> Val
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> -
> > >>>> Denis
> > >>>>
> > >>>
> > >>
> >
>
>
Re: Apache Ignite 3.0
Posted by Petr Ivanov <mr...@gmail.com>.
RPM/DEB will be easy to refactor that way —internal dependency management will help with that.
We can start with simple task — divide package into at least the following modules:
— apache-ignite: slim package with only necessary runtime libs and scripts (just like slim binary)
— apache-ignite-optional: package with optional libs
— apache-ignite-benchmarks
— apache-ignite-examples
— apache-ignite-platforms
Later, we can further modularise apache-ignite-optional into per-lib package and add support for extensions that are now in separate repository.
Everything will be stored at Apache Bintray in correct repository layout and benefit from corresponding package management systems to install.
Also, for packages, I'd like to introduce version into naming, i.e. future package should have name like apache-ignite3-3.0.0 — that should allow to have both AI 2.X and AI 3.X the same time which can help users to migrate between major versions faster.
> On 12 Aug 2020, at 21:15, Valentin Kulichenko <va...@gmail.com> wrote:
>
> Hi Petr,
>
> Got it, that makes sense. I think we should rely on Maven for this. Basically, like the mvnw wrapper, but specific for Ignite purposes (enable/disable a module, start/stop a node, etc.). BTW, do you think RPM/DEB packages can use the same approach? Or they require that binaries are stored in specific repositories?
>
> -Val
>
> On Tue, Aug 11, 2020 at 11:48 PM Petr Ivanov <mr.weider@gmail.com <ma...@gmail.com>> wrote:
> Hi, Val.
>
>> On 12 Aug 2020, at 01:31, Valentin Kulichenko <valentin.kulichenko@gmail.com <ma...@gmail.com>> wrote:
>>
>> Hi Petr,
>>
>> I agree -- we should better modularize the platform. The current way if very error-prone, especially during upgrades -- any changes made within IGNITE_HOME (configs, scripts, modules, etc.) must be merged with a new version of the package. There is no standard way of doing this.
>>
>> However, I'm a bit concerned with your suggestion regarding custom dependency management. Can you please elaborate on how you think it should work? Are there tools we can reuse for this purpose? I would try to avoid reinventing the wheel.
>
> I see it as a a2enmod | 2dismod analog of Apache2.
>
> We build and store Apache Ignite and its modules as separate binaries (binary per module) then use custom script that will know where to download necessary module. Or possibly use modified ignite.sh to specify required 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.
>
>
>>
>> -Val
>>
>> On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov <mr.weider@gmail.com <ma...@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 starting Ignite and all other modules and parts of the project (benchmarks, examples, etc.) packed in their own binary which can be added via custom dependency management tool (i.e. modules.sh)
>> — same distribution for RPM and DEB packages but with modules packed as separate ones (PHP for example)
>> — separate thin client release cycle with custom versioning
>> Possibly, we can we add additional section to the document you introduced for this part.
>>
>> Also, it seems that full JDK11 support (including building) would be a huge milestone and a sign of healthy modern project that tends to be on the verge of mainstream technologies and not the stockpile of legacy leftovers (fully support Iliya in removing all that was deprecated and/or marked as unused anymore).
>>
>>
>> > On 8 Aug 2020, at 02:00, Valentin Kulichenko <valentin.kulichenko@gmail.com <ma...@gmail.com>> wrote:
>> >
>> > Igniters,
>> >
>> > I've created the page:
>> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0 <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 the consensus on the proposed changes, I will
>> > start creating tickets in Jira and a more detailed plan.
>> >
>> > -Val
>> >
>> > On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <saikat.maitra@gmail.com <ma...@gmail.com>>
>> > wrote:
>> >
>> >> Hi Denis, Val
>> >>
>> >> Thank you for your reply and really appreciate it. It will be very cool to
>> >> be able to connect and plan release together and learn more about Ignite in
>> >> the process :)
>> >>
>> >> Regards
>> >> Saikat
>> >>
>> >>
>> >>
>> >> On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko <
>> >> valentin.kulichenko@gmail.com <ma...@gmail.com>> wrote:
>> >>
>> >>> Hi Saikat,
>> >>>
>> >>> That surely is a great idea. We will work together with Denis on setting
>> >>> this up in the nearest future.
>> >>>
>> >>> -Val
>> >>>
>> >>> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <dmagda@apache.org <ma...@apache.org>> wrote:
>> >>>
>> >>>> Saikat,
>> >>>>
>> >>>> Fully support your idea on a virtual meetup! Once Val collects and
>> >>> outlines
>> >>>> the main changes with directions on wiki, we’ll go ahead and schedule
>> >> the
>> >>>> meetup to talk things out in a bit more detail. We’ll use our new
>> >> Virtual
>> >>>> Ignite Meetup group for that inviting both Ignite contributors and
>> >>>> application developers.
>> >>>>
>> >>>> Denis
>> >>>>
>> >>>> On Thursday, August 6, 2020, Saikat Maitra <saikat.maitra@gmail.com <ma...@gmail.com>>
>> >>>> wrote:
>> >>>>
>> >>>>> Hi Valentin
>> >>>>>
>> >>>>> Thank you for sharing and starting the thread. I am thinking if it
>> >> will
>> >>>> be
>> >>>>> a good idea to have a virtual meet setup to discuss on the release
>> >>>>> planning.
>> >>>>>
>> >>>>> It will help to learn more individual features to be added and also
>> >> to
>> >>>>> understand about features that have been deprecated and scheduled for
>> >>>>> removal in Ignite 3.0 release. Also it will help community member to
>> >>>>> connect in real time and ask questions and share feedback.
>> >>>>>
>> >>>>> Regards,
>> >>>>> Saikat
>> >>>>>
>> >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <
>> >>>> ilya.kasnacheev@gmail.com <ma...@gmail.com>>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> Hello!
>> >>>>>>
>> >>>>>> I hope to see Apache Ignite release 3.0 as API trimming release.
>> >> Let
>> >>> us
>> >>>>>> correct external and internal APIs for which we have better ideas
>> >>> now,
>> >>>> as
>> >>>>>> well as remove old and deprecated code.
>> >>>>>>
>> >>>>>> We may also introduce new configuration mechanisms and user-facing
>> >>> API
>> >>>>>> (such as cache-less native SQL queries), but this we could
>> >> prototype
>> >>>>> before
>> >>>>>> starting the 3.0 task.
>> >>>>>>
>> >>>>>> I will advise against targeting large new features at 3.0. They can
>> >>> be
>> >>>>>> added in subsequent point releases, whereas we can't really remove
>> >> or
>> >>>>>> remodel stuff in point releases.
>> >>>>>>
>> >>>>>> Regards,
>> >>>>>> --
>> >>>>>> Ilya Kasnacheev
>> >>>>>>
>> >>>>>>
>> >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
>> >>>>>> valentin.kulichenko@gmail.com <ma...@gmail.com>>:
>> >>>>>>
>> >>>>>>> Igniters,
>> >>>>>>>
>> >>>>>>> I would like to kick off a discussion regarding Ignite 3.0.
>> >> Ignite
>> >>>> 2.0
>> >>>>>>> exists for more than 3 years now and we've already collected a
>> >>>>>> significant
>> >>>>>>> list [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/ <https://cwiki.apache.org/confluence/display/IGNITE/>
>> >>>>> Apache+Ignite+3.0+Wishlist
>> >>>>>>>
>> >>>>>>> Regards,
>> >>>>>>> Val
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> -
>> >>>> Denis
>> >>>>
>> >>>
>> >>
>>
>
Re: Apache Ignite 3.0
Posted by Valentin Kulichenko <va...@gmail.com>.
Hi Petr,
Got it, that makes sense. I think we should rely on Maven for this.
Basically, like the mvnw wrapper, but specific for Ignite purposes
(enable/disable a module, start/stop a node, etc.). BTW, do you think
RPM/DEB packages can use the same approach? Or they require that binaries
are stored in specific repositories?
-Val
On Tue, Aug 11, 2020 at 11:48 PM Petr Ivanov <mr...@gmail.com> wrote:
> Hi, Val.
>
> On 12 Aug 2020, at 01:31, Valentin Kulichenko <
> valentin.kulichenko@gmail.com> wrote:
>
> Hi Petr,
>
> I agree -- we should better modularize the platform. The current way if
> very error-prone, especially during upgrades -- any changes made within
> IGNITE_HOME (configs, scripts, modules, etc.) must be merged with a new
> version of the package. There is no standard way of doing this.
>
> However, I'm a bit concerned with your suggestion regarding custom
> dependency management. Can you please elaborate on how you think it should
> work? Are there tools we can reuse for this purpose? I would try to avoid
> reinventing the wheel.
>
>
> I see it as a a2enmod | 2dismod analog of Apache2.
>
> We build and store Apache Ignite and its modules as separate binaries
> (binary per module) then use custom script that will know where to download
> necessary module. Or possibly use modified ignite.sh to specify required
> 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.
>
>
>
> -Val
>
> On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov <mr...@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 starting
>> Ignite and all other modules and parts of the project (benchmarks,
>> examples, etc.) packed in their own binary which can be added via custom
>> dependency management tool (i.e. modules.sh)
>> — same distribution for RPM and DEB packages but with modules packed as
>> separate ones (PHP for example)
>> — separate thin client release cycle with custom versioning
>> Possibly, we can we add additional section to the document you introduced
>> for this part.
>>
>> Also, it seems that full JDK11 support (including building) would be a
>> huge milestone and a sign of healthy modern project that tends to be on the
>> verge of mainstream technologies and not the stockpile of legacy leftovers
>> (fully support Iliya in removing all that was deprecated and/or marked as
>> unused anymore).
>>
>>
>> > On 8 Aug 2020, at 02:00, Valentin Kulichenko <
>> valentin.kulichenko@gmail.com> wrote:
>> >
>> > 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 the consensus on the proposed changes, I will
>> > start creating tickets in Jira and a more detailed plan.
>> >
>> > -Val
>> >
>> > On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <sa...@gmail.com>
>> > wrote:
>> >
>> >> Hi Denis, Val
>> >>
>> >> Thank you for your reply and really appreciate it. It will be very
>> cool to
>> >> be able to connect and plan release together and learn more about
>> Ignite in
>> >> the process :)
>> >>
>> >> Regards
>> >> Saikat
>> >>
>> >>
>> >>
>> >> On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko <
>> >> valentin.kulichenko@gmail.com> wrote:
>> >>
>> >>> Hi Saikat,
>> >>>
>> >>> That surely is a great idea. We will work together with Denis on
>> setting
>> >>> this up in the nearest future.
>> >>>
>> >>> -Val
>> >>>
>> >>> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <dm...@apache.org>
>> wrote:
>> >>>
>> >>>> Saikat,
>> >>>>
>> >>>> Fully support your idea on a virtual meetup! Once Val collects and
>> >>> outlines
>> >>>> the main changes with directions on wiki, we’ll go ahead and schedule
>> >> the
>> >>>> meetup to talk things out in a bit more detail. We’ll use our new
>> >> Virtual
>> >>>> Ignite Meetup group for that inviting both Ignite contributors and
>> >>>> application developers.
>> >>>>
>> >>>> Denis
>> >>>>
>> >>>> On Thursday, August 6, 2020, Saikat Maitra <sa...@gmail.com>
>> >>>> wrote:
>> >>>>
>> >>>>> Hi Valentin
>> >>>>>
>> >>>>> Thank you for sharing and starting the thread. I am thinking if it
>> >> will
>> >>>> be
>> >>>>> a good idea to have a virtual meet setup to discuss on the release
>> >>>>> planning.
>> >>>>>
>> >>>>> It will help to learn more individual features to be added and also
>> >> to
>> >>>>> understand about features that have been deprecated and scheduled
>> for
>> >>>>> removal in Ignite 3.0 release. Also it will help community member to
>> >>>>> connect in real time and ask questions and share feedback.
>> >>>>>
>> >>>>> Regards,
>> >>>>> Saikat
>> >>>>>
>> >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <
>> >>>> ilya.kasnacheev@gmail.com>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> Hello!
>> >>>>>>
>> >>>>>> I hope to see Apache Ignite release 3.0 as API trimming release.
>> >> Let
>> >>> us
>> >>>>>> correct external and internal APIs for which we have better ideas
>> >>> now,
>> >>>> as
>> >>>>>> well as remove old and deprecated code.
>> >>>>>>
>> >>>>>> We may also introduce new configuration mechanisms and user-facing
>> >>> API
>> >>>>>> (such as cache-less native SQL queries), but this we could
>> >> prototype
>> >>>>> before
>> >>>>>> starting the 3.0 task.
>> >>>>>>
>> >>>>>> I will advise against targeting large new features at 3.0. They can
>> >>> be
>> >>>>>> added in subsequent point releases, whereas we can't really remove
>> >> or
>> >>>>>> remodel stuff in point releases.
>> >>>>>>
>> >>>>>> Regards,
>> >>>>>> --
>> >>>>>> Ilya Kasnacheev
>> >>>>>>
>> >>>>>>
>> >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
>> >>>>>> valentin.kulichenko@gmail.com>:
>> >>>>>>
>> >>>>>>> Igniters,
>> >>>>>>>
>> >>>>>>> I would like to kick off a discussion regarding Ignite 3.0.
>> >> Ignite
>> >>>> 2.0
>> >>>>>>> exists for more than 3 years now and we've already collected a
>> >>>>>> significant
>> >>>>>>> list [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
>> >>>>
>> >>>
>> >>
>>
>>
>
Re: Apache Ignite 3.0
Posted by Petr Ivanov <mr...@gmail.com>.
Hi, Val.
> On 12 Aug 2020, at 01:31, Valentin Kulichenko <va...@gmail.com> wrote:
>
> Hi Petr,
>
> I agree -- we should better modularize the platform. The current way if very error-prone, especially during upgrades -- any changes made within IGNITE_HOME (configs, scripts, modules, etc.) must be merged with a new version of the package. There is no standard way of doing this.
>
> However, I'm a bit concerned with your suggestion regarding custom dependency management. Can you please elaborate on how you think it should work? Are there tools we can reuse for this purpose? I would try to avoid reinventing the wheel.
I see it as a a2enmod | 2dismod analog of Apache2.
We build and store Apache Ignite and its modules as separate binaries (binary per module) then use custom script that will know where to download necessary module. Or possibly use modified ignite.sh to specify required 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.
>
> -Val
>
> On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov <mr.weider@gmail.com <ma...@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 starting Ignite and all other modules and parts of the project (benchmarks, examples, etc.) packed in their own binary which can be added via custom dependency management tool (i.e. modules.sh)
> — same distribution for RPM and DEB packages but with modules packed as separate ones (PHP for example)
> — separate thin client release cycle with custom versioning
> Possibly, we can we add additional section to the document you introduced for this part.
>
> Also, it seems that full JDK11 support (including building) would be a huge milestone and a sign of healthy modern project that tends to be on the verge of mainstream technologies and not the stockpile of legacy leftovers (fully support Iliya in removing all that was deprecated and/or marked as unused anymore).
>
>
> > On 8 Aug 2020, at 02:00, Valentin Kulichenko <valentin.kulichenko@gmail.com <ma...@gmail.com>> wrote:
> >
> > Igniters,
> >
> > I've created the page:
> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0 <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 the consensus on the proposed changes, I will
> > start creating tickets in Jira and a more detailed plan.
> >
> > -Val
> >
> > On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <saikat.maitra@gmail.com <ma...@gmail.com>>
> > wrote:
> >
> >> Hi Denis, Val
> >>
> >> Thank you for your reply and really appreciate it. It will be very cool to
> >> be able to connect and plan release together and learn more about Ignite in
> >> the process :)
> >>
> >> Regards
> >> Saikat
> >>
> >>
> >>
> >> On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko <
> >> valentin.kulichenko@gmail.com <ma...@gmail.com>> wrote:
> >>
> >>> Hi Saikat,
> >>>
> >>> That surely is a great idea. We will work together with Denis on setting
> >>> this up in the nearest future.
> >>>
> >>> -Val
> >>>
> >>> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <dmagda@apache.org <ma...@apache.org>> wrote:
> >>>
> >>>> Saikat,
> >>>>
> >>>> Fully support your idea on a virtual meetup! Once Val collects and
> >>> outlines
> >>>> the main changes with directions on wiki, we’ll go ahead and schedule
> >> the
> >>>> meetup to talk things out in a bit more detail. We’ll use our new
> >> Virtual
> >>>> Ignite Meetup group for that inviting both Ignite contributors and
> >>>> application developers.
> >>>>
> >>>> Denis
> >>>>
> >>>> On Thursday, August 6, 2020, Saikat Maitra <saikat.maitra@gmail.com <ma...@gmail.com>>
> >>>> wrote:
> >>>>
> >>>>> Hi Valentin
> >>>>>
> >>>>> Thank you for sharing and starting the thread. I am thinking if it
> >> will
> >>>> be
> >>>>> a good idea to have a virtual meet setup to discuss on the release
> >>>>> planning.
> >>>>>
> >>>>> It will help to learn more individual features to be added and also
> >> to
> >>>>> understand about features that have been deprecated and scheduled for
> >>>>> removal in Ignite 3.0 release. Also it will help community member to
> >>>>> connect in real time and ask questions and share feedback.
> >>>>>
> >>>>> Regards,
> >>>>> Saikat
> >>>>>
> >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <
> >>>> ilya.kasnacheev@gmail.com <ma...@gmail.com>>
> >>>>> wrote:
> >>>>>
> >>>>>> Hello!
> >>>>>>
> >>>>>> I hope to see Apache Ignite release 3.0 as API trimming release.
> >> Let
> >>> us
> >>>>>> correct external and internal APIs for which we have better ideas
> >>> now,
> >>>> as
> >>>>>> well as remove old and deprecated code.
> >>>>>>
> >>>>>> We may also introduce new configuration mechanisms and user-facing
> >>> API
> >>>>>> (such as cache-less native SQL queries), but this we could
> >> prototype
> >>>>> before
> >>>>>> starting the 3.0 task.
> >>>>>>
> >>>>>> I will advise against targeting large new features at 3.0. They can
> >>> be
> >>>>>> added in subsequent point releases, whereas we can't really remove
> >> or
> >>>>>> remodel stuff in point releases.
> >>>>>>
> >>>>>> Regards,
> >>>>>> --
> >>>>>> Ilya Kasnacheev
> >>>>>>
> >>>>>>
> >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
> >>>>>> valentin.kulichenko@gmail.com <ma...@gmail.com>>:
> >>>>>>
> >>>>>>> Igniters,
> >>>>>>>
> >>>>>>> I would like to kick off a discussion regarding Ignite 3.0.
> >> Ignite
> >>>> 2.0
> >>>>>>> exists for more than 3 years now and we've already collected a
> >>>>>> significant
> >>>>>>> list [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/ <https://cwiki.apache.org/confluence/display/IGNITE/>
> >>>>> Apache+Ignite+3.0+Wishlist
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Val
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> -
> >>>> Denis
> >>>>
> >>>
> >>
>
Re: Apache Ignite 3.0
Posted by Valentin Kulichenko <va...@gmail.com>.
Hi Petr,
I agree -- we should better modularize the platform. The current way if
very error-prone, especially during upgrades -- any changes made within
IGNITE_HOME (configs, scripts, modules, etc.) must be merged with a new
version of the package. There is no standard way of doing this.
However, I'm a bit concerned with your suggestion regarding custom
dependency management. Can you please elaborate on how you think it should
work? Are there tools we can reuse for this purpose? I would try to avoid
reinventing the wheel.
-Val
On Sun, Aug 9, 2020 at 11:25 PM Petr Ivanov <mr...@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 starting
> Ignite and all other modules and parts of the project (benchmarks,
> examples, etc.) packed in their own binary which can be added via custom
> dependency management tool (i.e. modules.sh)
> — same distribution for RPM and DEB packages but with modules packed as
> separate ones (PHP for example)
> — separate thin client release cycle with custom versioning
> Possibly, we can we add additional section to the document you introduced
> for this part.
>
> Also, it seems that full JDK11 support (including building) would be a
> huge milestone and a sign of healthy modern project that tends to be on the
> verge of mainstream technologies and not the stockpile of legacy leftovers
> (fully support Iliya in removing all that was deprecated and/or marked as
> unused anymore).
>
>
> > On 8 Aug 2020, at 02:00, Valentin Kulichenko <
> valentin.kulichenko@gmail.com> wrote:
> >
> > 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 the consensus on the proposed changes, I will
> > start creating tickets in Jira and a more detailed plan.
> >
> > -Val
> >
> > On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <sa...@gmail.com>
> > wrote:
> >
> >> Hi Denis, Val
> >>
> >> Thank you for your reply and really appreciate it. It will be very cool
> to
> >> be able to connect and plan release together and learn more about
> Ignite in
> >> the process :)
> >>
> >> Regards
> >> Saikat
> >>
> >>
> >>
> >> On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko <
> >> valentin.kulichenko@gmail.com> wrote:
> >>
> >>> Hi Saikat,
> >>>
> >>> That surely is a great idea. We will work together with Denis on
> setting
> >>> this up in the nearest future.
> >>>
> >>> -Val
> >>>
> >>> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <dm...@apache.org> wrote:
> >>>
> >>>> Saikat,
> >>>>
> >>>> Fully support your idea on a virtual meetup! Once Val collects and
> >>> outlines
> >>>> the main changes with directions on wiki, we’ll go ahead and schedule
> >> the
> >>>> meetup to talk things out in a bit more detail. We’ll use our new
> >> Virtual
> >>>> Ignite Meetup group for that inviting both Ignite contributors and
> >>>> application developers.
> >>>>
> >>>> Denis
> >>>>
> >>>> On Thursday, August 6, 2020, Saikat Maitra <sa...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Hi Valentin
> >>>>>
> >>>>> Thank you for sharing and starting the thread. I am thinking if it
> >> will
> >>>> be
> >>>>> a good idea to have a virtual meet setup to discuss on the release
> >>>>> planning.
> >>>>>
> >>>>> It will help to learn more individual features to be added and also
> >> to
> >>>>> understand about features that have been deprecated and scheduled for
> >>>>> removal in Ignite 3.0 release. Also it will help community member to
> >>>>> connect in real time and ask questions and share feedback.
> >>>>>
> >>>>> Regards,
> >>>>> Saikat
> >>>>>
> >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <
> >>>> ilya.kasnacheev@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Hello!
> >>>>>>
> >>>>>> I hope to see Apache Ignite release 3.0 as API trimming release.
> >> Let
> >>> us
> >>>>>> correct external and internal APIs for which we have better ideas
> >>> now,
> >>>> as
> >>>>>> well as remove old and deprecated code.
> >>>>>>
> >>>>>> We may also introduce new configuration mechanisms and user-facing
> >>> API
> >>>>>> (such as cache-less native SQL queries), but this we could
> >> prototype
> >>>>> before
> >>>>>> starting the 3.0 task.
> >>>>>>
> >>>>>> I will advise against targeting large new features at 3.0. They can
> >>> be
> >>>>>> added in subsequent point releases, whereas we can't really remove
> >> or
> >>>>>> remodel stuff in point releases.
> >>>>>>
> >>>>>> Regards,
> >>>>>> --
> >>>>>> Ilya Kasnacheev
> >>>>>>
> >>>>>>
> >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
> >>>>>> valentin.kulichenko@gmail.com>:
> >>>>>>
> >>>>>>> Igniters,
> >>>>>>>
> >>>>>>> I would like to kick off a discussion regarding Ignite 3.0.
> >> Ignite
> >>>> 2.0
> >>>>>>> exists for more than 3 years now and we've already collected a
> >>>>>> significant
> >>>>>>> list [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
> >>>>
> >>>
> >>
>
>
Re: Apache Ignite 3.0
Posted by Valentin Kulichenko <va...@gmail.com>.
Denis,
Agree. Added this requirement to the page along with everything else
discussed so far.
-Val
On Tue, Aug 11, 2020 at 4:07 PM Denis Magda <dm...@apache.org> wrote:
> Val,
>
> I remember some of us wanted to rework the transactional API. Is it still
> relevant?
>
> Also, I would add the native image feature of GraalVM to the scope of the
> release. Presently, even Java *thin* clients fail if an app is compiled and
> started as the native image. Turns out that the thin client triggers some
> logic of the BinaryMarshaller that attempts to load classes dynamically
> which crashes the native application. So, I don't have any other choice but
> to use our legacy REST APIs to query records from Ignite. Not the best
> choice, right :)
>
> GraalVM's native image generation capability is a cornerstone feature for
> modern Java applications deployed in serverless environments and powered by
> contemporary frameworks such as Micronaut and Quarkus. That's the nearest
> future and I would encourage us to support the native image feature at
> least for the thin clients in Ignite 3.0. It might be much more difficult
> to enable the support for the thick clients but that waits.
>
>
> -
> Denis
>
>
> On Tue, Aug 11, 2020 at 3:34 PM Valentin Kulichenko <
> valentin.kulichenko@gmail.com> wrote:
>
> > Hi Saikat,
> >
> > Absolutely, we should revisit the existing APIs and decide which we want
> to
> > keep as-is, which we want to remove, and which we want to rework and
> > modernize. 3.0 is a rare opportunity to do such a cleanup :)
> >
> > -Val
> >
> > On Mon, Aug 10, 2020 at 6:54 PM Saikat Maitra <sa...@gmail.com>
> > wrote:
> >
> > > 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/display/IGNITE/Apache+Ignite+3.0+Wishlist
> > >
> > > Regards,
> > > Saikat
> > >
> > >
> > > On Mon, Aug 10, 2020 at 1:25 AM Petr Ivanov <mr...@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 starting
> > > > Ignite and all other modules and parts of the project (benchmarks,
> > > > examples, etc.) packed in their own binary which can be added via
> > custom
> > > > dependency management tool (i.e. modules.sh)
> > > > — same distribution for RPM and DEB packages but with modules packed
> > as
> > > > separate ones (PHP for example)
> > > > — separate thin client release cycle with custom versioning
> > > > Possibly, we can we add additional section to the document you
> > introduced
> > > > for this part.
> > > >
> > > > Also, it seems that full JDK11 support (including building) would be
> a
> > > > huge milestone and a sign of healthy modern project that tends to be
> on
> > > the
> > > > verge of mainstream technologies and not the stockpile of legacy
> > > leftovers
> > > > (fully support Iliya in removing all that was deprecated and/or
> marked
> > as
> > > > unused anymore).
> > > >
> > > >
> > > > > On 8 Aug 2020, at 02:00, Valentin Kulichenko <
> > > > valentin.kulichenko@gmail.com> wrote:
> > > > >
> > > > > 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 the consensus on the proposed changes, I
> > will
> > > > > start creating tickets in Jira and a more detailed plan.
> > > > >
> > > > > -Val
> > > > >
> > > > > On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <
> > saikat.maitra@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> Hi Denis, Val
> > > > >>
> > > > >> Thank you for your reply and really appreciate it. It will be very
> > > cool
> > > > to
> > > > >> be able to connect and plan release together and learn more about
> > > > Ignite in
> > > > >> the process :)
> > > > >>
> > > > >> Regards
> > > > >> Saikat
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko <
> > > > >> valentin.kulichenko@gmail.com> wrote:
> > > > >>
> > > > >>> Hi Saikat,
> > > > >>>
> > > > >>> That surely is a great idea. We will work together with Denis on
> > > > setting
> > > > >>> this up in the nearest future.
> > > > >>>
> > > > >>> -Val
> > > > >>>
> > > > >>> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <dm...@apache.org>
> > > wrote:
> > > > >>>
> > > > >>>> Saikat,
> > > > >>>>
> > > > >>>> Fully support your idea on a virtual meetup! Once Val collects
> and
> > > > >>> outlines
> > > > >>>> the main changes with directions on wiki, we’ll go ahead and
> > > schedule
> > > > >> the
> > > > >>>> meetup to talk things out in a bit more detail. We’ll use our
> new
> > > > >> Virtual
> > > > >>>> Ignite Meetup group for that inviting both Ignite contributors
> and
> > > > >>>> application developers.
> > > > >>>>
> > > > >>>> Denis
> > > > >>>>
> > > > >>>> On Thursday, August 6, 2020, Saikat Maitra <
> > saikat.maitra@gmail.com
> > > >
> > > > >>>> wrote:
> > > > >>>>
> > > > >>>>> Hi Valentin
> > > > >>>>>
> > > > >>>>> Thank you for sharing and starting the thread. I am thinking if
> > it
> > > > >> will
> > > > >>>> be
> > > > >>>>> a good idea to have a virtual meet setup to discuss on the
> > release
> > > > >>>>> planning.
> > > > >>>>>
> > > > >>>>> It will help to learn more individual features to be added and
> > also
> > > > >> to
> > > > >>>>> understand about features that have been deprecated and
> scheduled
> > > for
> > > > >>>>> removal in Ignite 3.0 release. Also it will help community
> member
> > > to
> > > > >>>>> connect in real time and ask questions and share feedback.
> > > > >>>>>
> > > > >>>>> Regards,
> > > > >>>>> Saikat
> > > > >>>>>
> > > > >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <
> > > > >>>> ilya.kasnacheev@gmail.com>
> > > > >>>>> wrote:
> > > > >>>>>
> > > > >>>>>> Hello!
> > > > >>>>>>
> > > > >>>>>> I hope to see Apache Ignite release 3.0 as API trimming
> release.
> > > > >> Let
> > > > >>> us
> > > > >>>>>> correct external and internal APIs for which we have better
> > ideas
> > > > >>> now,
> > > > >>>> as
> > > > >>>>>> well as remove old and deprecated code.
> > > > >>>>>>
> > > > >>>>>> We may also introduce new configuration mechanisms and
> > user-facing
> > > > >>> API
> > > > >>>>>> (such as cache-less native SQL queries), but this we could
> > > > >> prototype
> > > > >>>>> before
> > > > >>>>>> starting the 3.0 task.
> > > > >>>>>>
> > > > >>>>>> I will advise against targeting large new features at 3.0.
> They
> > > can
> > > > >>> be
> > > > >>>>>> added in subsequent point releases, whereas we can't really
> > remove
> > > > >> or
> > > > >>>>>> remodel stuff in point releases.
> > > > >>>>>>
> > > > >>>>>> Regards,
> > > > >>>>>> --
> > > > >>>>>> Ilya Kasnacheev
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
> > > > >>>>>> valentin.kulichenko@gmail.com>:
> > > > >>>>>>
> > > > >>>>>>> Igniters,
> > > > >>>>>>>
> > > > >>>>>>> I would like to kick off a discussion regarding Ignite 3.0.
> > > > >> Ignite
> > > > >>>> 2.0
> > > > >>>>>>> exists for more than 3 years now and we've already collected
> a
> > > > >>>>>> significant
> > > > >>>>>>> list [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
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> >
>
Re: Apache Ignite 3.0
Posted by Denis Magda <dm...@apache.org>.
Val,
I remember some of us wanted to rework the transactional API. Is it still
relevant?
Also, I would add the native image feature of GraalVM to the scope of the
release. Presently, even Java *thin* clients fail if an app is compiled and
started as the native image. Turns out that the thin client triggers some
logic of the BinaryMarshaller that attempts to load classes dynamically
which crashes the native application. So, I don't have any other choice but
to use our legacy REST APIs to query records from Ignite. Not the best
choice, right :)
GraalVM's native image generation capability is a cornerstone feature for
modern Java applications deployed in serverless environments and powered by
contemporary frameworks such as Micronaut and Quarkus. That's the nearest
future and I would encourage us to support the native image feature at
least for the thin clients in Ignite 3.0. It might be much more difficult
to enable the support for the thick clients but that waits.
-
Denis
On Tue, Aug 11, 2020 at 3:34 PM Valentin Kulichenko <
valentin.kulichenko@gmail.com> wrote:
> Hi Saikat,
>
> Absolutely, we should revisit the existing APIs and decide which we want to
> keep as-is, which we want to remove, and which we want to rework and
> modernize. 3.0 is a rare opportunity to do such a cleanup :)
>
> -Val
>
> On Mon, Aug 10, 2020 at 6:54 PM Saikat Maitra <sa...@gmail.com>
> wrote:
>
> > 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/display/IGNITE/Apache+Ignite+3.0+Wishlist
> >
> > Regards,
> > Saikat
> >
> >
> > On Mon, Aug 10, 2020 at 1:25 AM Petr Ivanov <mr...@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 starting
> > > Ignite and all other modules and parts of the project (benchmarks,
> > > examples, etc.) packed in their own binary which can be added via
> custom
> > > dependency management tool (i.e. modules.sh)
> > > — same distribution for RPM and DEB packages but with modules packed
> as
> > > separate ones (PHP for example)
> > > — separate thin client release cycle with custom versioning
> > > Possibly, we can we add additional section to the document you
> introduced
> > > for this part.
> > >
> > > Also, it seems that full JDK11 support (including building) would be a
> > > huge milestone and a sign of healthy modern project that tends to be on
> > the
> > > verge of mainstream technologies and not the stockpile of legacy
> > leftovers
> > > (fully support Iliya in removing all that was deprecated and/or marked
> as
> > > unused anymore).
> > >
> > >
> > > > On 8 Aug 2020, at 02:00, Valentin Kulichenko <
> > > valentin.kulichenko@gmail.com> wrote:
> > > >
> > > > 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 the consensus on the proposed changes, I
> will
> > > > start creating tickets in Jira and a more detailed plan.
> > > >
> > > > -Val
> > > >
> > > > On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <
> saikat.maitra@gmail.com>
> > > > wrote:
> > > >
> > > >> Hi Denis, Val
> > > >>
> > > >> Thank you for your reply and really appreciate it. It will be very
> > cool
> > > to
> > > >> be able to connect and plan release together and learn more about
> > > Ignite in
> > > >> the process :)
> > > >>
> > > >> Regards
> > > >> Saikat
> > > >>
> > > >>
> > > >>
> > > >> On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko <
> > > >> valentin.kulichenko@gmail.com> wrote:
> > > >>
> > > >>> Hi Saikat,
> > > >>>
> > > >>> That surely is a great idea. We will work together with Denis on
> > > setting
> > > >>> this up in the nearest future.
> > > >>>
> > > >>> -Val
> > > >>>
> > > >>> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <dm...@apache.org>
> > wrote:
> > > >>>
> > > >>>> Saikat,
> > > >>>>
> > > >>>> Fully support your idea on a virtual meetup! Once Val collects and
> > > >>> outlines
> > > >>>> the main changes with directions on wiki, we’ll go ahead and
> > schedule
> > > >> the
> > > >>>> meetup to talk things out in a bit more detail. We’ll use our new
> > > >> Virtual
> > > >>>> Ignite Meetup group for that inviting both Ignite contributors and
> > > >>>> application developers.
> > > >>>>
> > > >>>> Denis
> > > >>>>
> > > >>>> On Thursday, August 6, 2020, Saikat Maitra <
> saikat.maitra@gmail.com
> > >
> > > >>>> wrote:
> > > >>>>
> > > >>>>> Hi Valentin
> > > >>>>>
> > > >>>>> Thank you for sharing and starting the thread. I am thinking if
> it
> > > >> will
> > > >>>> be
> > > >>>>> a good idea to have a virtual meet setup to discuss on the
> release
> > > >>>>> planning.
> > > >>>>>
> > > >>>>> It will help to learn more individual features to be added and
> also
> > > >> to
> > > >>>>> understand about features that have been deprecated and scheduled
> > for
> > > >>>>> removal in Ignite 3.0 release. Also it will help community member
> > to
> > > >>>>> connect in real time and ask questions and share feedback.
> > > >>>>>
> > > >>>>> Regards,
> > > >>>>> Saikat
> > > >>>>>
> > > >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <
> > > >>>> ilya.kasnacheev@gmail.com>
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>>> Hello!
> > > >>>>>>
> > > >>>>>> I hope to see Apache Ignite release 3.0 as API trimming release.
> > > >> Let
> > > >>> us
> > > >>>>>> correct external and internal APIs for which we have better
> ideas
> > > >>> now,
> > > >>>> as
> > > >>>>>> well as remove old and deprecated code.
> > > >>>>>>
> > > >>>>>> We may also introduce new configuration mechanisms and
> user-facing
> > > >>> API
> > > >>>>>> (such as cache-less native SQL queries), but this we could
> > > >> prototype
> > > >>>>> before
> > > >>>>>> starting the 3.0 task.
> > > >>>>>>
> > > >>>>>> I will advise against targeting large new features at 3.0. They
> > can
> > > >>> be
> > > >>>>>> added in subsequent point releases, whereas we can't really
> remove
> > > >> or
> > > >>>>>> remodel stuff in point releases.
> > > >>>>>>
> > > >>>>>> Regards,
> > > >>>>>> --
> > > >>>>>> Ilya Kasnacheev
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
> > > >>>>>> valentin.kulichenko@gmail.com>:
> > > >>>>>>
> > > >>>>>>> Igniters,
> > > >>>>>>>
> > > >>>>>>> I would like to kick off a discussion regarding Ignite 3.0.
> > > >> Ignite
> > > >>>> 2.0
> > > >>>>>>> exists for more than 3 years now and we've already collected a
> > > >>>>>> significant
> > > >>>>>>> list [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
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> >
>
Re: Apache Ignite 3.0
Posted by Valentin Kulichenko <va...@gmail.com>.
Hi Saikat,
Absolutely, we should revisit the existing APIs and decide which we want to
keep as-is, which we want to remove, and which we want to rework and
modernize. 3.0 is a rare opportunity to do such a cleanup :)
-Val
On Mon, Aug 10, 2020 at 6:54 PM Saikat Maitra <sa...@gmail.com>
wrote:
> 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/display/IGNITE/Apache+Ignite+3.0+Wishlist
>
> Regards,
> Saikat
>
>
> On Mon, Aug 10, 2020 at 1:25 AM Petr Ivanov <mr...@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 starting
> > Ignite and all other modules and parts of the project (benchmarks,
> > examples, etc.) packed in their own binary which can be added via custom
> > dependency management tool (i.e. modules.sh)
> > — same distribution for RPM and DEB packages but with modules packed as
> > separate ones (PHP for example)
> > — separate thin client release cycle with custom versioning
> > Possibly, we can we add additional section to the document you introduced
> > for this part.
> >
> > Also, it seems that full JDK11 support (including building) would be a
> > huge milestone and a sign of healthy modern project that tends to be on
> the
> > verge of mainstream technologies and not the stockpile of legacy
> leftovers
> > (fully support Iliya in removing all that was deprecated and/or marked as
> > unused anymore).
> >
> >
> > > On 8 Aug 2020, at 02:00, Valentin Kulichenko <
> > valentin.kulichenko@gmail.com> wrote:
> > >
> > > 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 the consensus on the proposed changes, I will
> > > start creating tickets in Jira and a more detailed plan.
> > >
> > > -Val
> > >
> > > On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <sa...@gmail.com>
> > > wrote:
> > >
> > >> Hi Denis, Val
> > >>
> > >> Thank you for your reply and really appreciate it. It will be very
> cool
> > to
> > >> be able to connect and plan release together and learn more about
> > Ignite in
> > >> the process :)
> > >>
> > >> Regards
> > >> Saikat
> > >>
> > >>
> > >>
> > >> On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko <
> > >> valentin.kulichenko@gmail.com> wrote:
> > >>
> > >>> Hi Saikat,
> > >>>
> > >>> That surely is a great idea. We will work together with Denis on
> > setting
> > >>> this up in the nearest future.
> > >>>
> > >>> -Val
> > >>>
> > >>> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <dm...@apache.org>
> wrote:
> > >>>
> > >>>> Saikat,
> > >>>>
> > >>>> Fully support your idea on a virtual meetup! Once Val collects and
> > >>> outlines
> > >>>> the main changes with directions on wiki, we’ll go ahead and
> schedule
> > >> the
> > >>>> meetup to talk things out in a bit more detail. We’ll use our new
> > >> Virtual
> > >>>> Ignite Meetup group for that inviting both Ignite contributors and
> > >>>> application developers.
> > >>>>
> > >>>> Denis
> > >>>>
> > >>>> On Thursday, August 6, 2020, Saikat Maitra <saikat.maitra@gmail.com
> >
> > >>>> wrote:
> > >>>>
> > >>>>> Hi Valentin
> > >>>>>
> > >>>>> Thank you for sharing and starting the thread. I am thinking if it
> > >> will
> > >>>> be
> > >>>>> a good idea to have a virtual meet setup to discuss on the release
> > >>>>> planning.
> > >>>>>
> > >>>>> It will help to learn more individual features to be added and also
> > >> to
> > >>>>> understand about features that have been deprecated and scheduled
> for
> > >>>>> removal in Ignite 3.0 release. Also it will help community member
> to
> > >>>>> connect in real time and ask questions and share feedback.
> > >>>>>
> > >>>>> Regards,
> > >>>>> Saikat
> > >>>>>
> > >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <
> > >>>> ilya.kasnacheev@gmail.com>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> Hello!
> > >>>>>>
> > >>>>>> I hope to see Apache Ignite release 3.0 as API trimming release.
> > >> Let
> > >>> us
> > >>>>>> correct external and internal APIs for which we have better ideas
> > >>> now,
> > >>>> as
> > >>>>>> well as remove old and deprecated code.
> > >>>>>>
> > >>>>>> We may also introduce new configuration mechanisms and user-facing
> > >>> API
> > >>>>>> (such as cache-less native SQL queries), but this we could
> > >> prototype
> > >>>>> before
> > >>>>>> starting the 3.0 task.
> > >>>>>>
> > >>>>>> I will advise against targeting large new features at 3.0. They
> can
> > >>> be
> > >>>>>> added in subsequent point releases, whereas we can't really remove
> > >> or
> > >>>>>> remodel stuff in point releases.
> > >>>>>>
> > >>>>>> Regards,
> > >>>>>> --
> > >>>>>> Ilya Kasnacheev
> > >>>>>>
> > >>>>>>
> > >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
> > >>>>>> valentin.kulichenko@gmail.com>:
> > >>>>>>
> > >>>>>>> Igniters,
> > >>>>>>>
> > >>>>>>> I would like to kick off a discussion regarding Ignite 3.0.
> > >> Ignite
> > >>>> 2.0
> > >>>>>>> exists for more than 3 years now and we've already collected a
> > >>>>>> significant
> > >>>>>>> list [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
> > >>>>
> > >>>
> > >>
> >
> >
>
Re: Apache Ignite 3.0
Posted by Saikat Maitra <sa...@gmail.com>.
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/display/IGNITE/Apache+Ignite+3.0+Wishlist
Regards,
Saikat
On Mon, Aug 10, 2020 at 1:25 AM Petr Ivanov <mr...@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 starting
> Ignite and all other modules and parts of the project (benchmarks,
> examples, etc.) packed in their own binary which can be added via custom
> dependency management tool (i.e. modules.sh)
> — same distribution for RPM and DEB packages but with modules packed as
> separate ones (PHP for example)
> — separate thin client release cycle with custom versioning
> Possibly, we can we add additional section to the document you introduced
> for this part.
>
> Also, it seems that full JDK11 support (including building) would be a
> huge milestone and a sign of healthy modern project that tends to be on the
> verge of mainstream technologies and not the stockpile of legacy leftovers
> (fully support Iliya in removing all that was deprecated and/or marked as
> unused anymore).
>
>
> > On 8 Aug 2020, at 02:00, Valentin Kulichenko <
> valentin.kulichenko@gmail.com> wrote:
> >
> > 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 the consensus on the proposed changes, I will
> > start creating tickets in Jira and a more detailed plan.
> >
> > -Val
> >
> > On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <sa...@gmail.com>
> > wrote:
> >
> >> Hi Denis, Val
> >>
> >> Thank you for your reply and really appreciate it. It will be very cool
> to
> >> be able to connect and plan release together and learn more about
> Ignite in
> >> the process :)
> >>
> >> Regards
> >> Saikat
> >>
> >>
> >>
> >> On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko <
> >> valentin.kulichenko@gmail.com> wrote:
> >>
> >>> Hi Saikat,
> >>>
> >>> That surely is a great idea. We will work together with Denis on
> setting
> >>> this up in the nearest future.
> >>>
> >>> -Val
> >>>
> >>> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <dm...@apache.org> wrote:
> >>>
> >>>> Saikat,
> >>>>
> >>>> Fully support your idea on a virtual meetup! Once Val collects and
> >>> outlines
> >>>> the main changes with directions on wiki, we’ll go ahead and schedule
> >> the
> >>>> meetup to talk things out in a bit more detail. We’ll use our new
> >> Virtual
> >>>> Ignite Meetup group for that inviting both Ignite contributors and
> >>>> application developers.
> >>>>
> >>>> Denis
> >>>>
> >>>> On Thursday, August 6, 2020, Saikat Maitra <sa...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Hi Valentin
> >>>>>
> >>>>> Thank you for sharing and starting the thread. I am thinking if it
> >> will
> >>>> be
> >>>>> a good idea to have a virtual meet setup to discuss on the release
> >>>>> planning.
> >>>>>
> >>>>> It will help to learn more individual features to be added and also
> >> to
> >>>>> understand about features that have been deprecated and scheduled for
> >>>>> removal in Ignite 3.0 release. Also it will help community member to
> >>>>> connect in real time and ask questions and share feedback.
> >>>>>
> >>>>> Regards,
> >>>>> Saikat
> >>>>>
> >>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <
> >>>> ilya.kasnacheev@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Hello!
> >>>>>>
> >>>>>> I hope to see Apache Ignite release 3.0 as API trimming release.
> >> Let
> >>> us
> >>>>>> correct external and internal APIs for which we have better ideas
> >>> now,
> >>>> as
> >>>>>> well as remove old and deprecated code.
> >>>>>>
> >>>>>> We may also introduce new configuration mechanisms and user-facing
> >>> API
> >>>>>> (such as cache-less native SQL queries), but this we could
> >> prototype
> >>>>> before
> >>>>>> starting the 3.0 task.
> >>>>>>
> >>>>>> I will advise against targeting large new features at 3.0. They can
> >>> be
> >>>>>> added in subsequent point releases, whereas we can't really remove
> >> or
> >>>>>> remodel stuff in point releases.
> >>>>>>
> >>>>>> Regards,
> >>>>>> --
> >>>>>> Ilya Kasnacheev
> >>>>>>
> >>>>>>
> >>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
> >>>>>> valentin.kulichenko@gmail.com>:
> >>>>>>
> >>>>>>> Igniters,
> >>>>>>>
> >>>>>>> I would like to kick off a discussion regarding Ignite 3.0.
> >> Ignite
> >>>> 2.0
> >>>>>>> exists for more than 3 years now and we've already collected a
> >>>>>> significant
> >>>>>>> list [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
> >>>>
> >>>
> >>
>
>
Re: Apache Ignite 3.0
Posted by Petr Ivanov <mr...@gmail.com>.
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 binary which can be added via custom dependency management tool (i.e. modules.sh)
— same distribution for RPM and DEB packages but with modules packed as separate ones (PHP for example)
— separate thin client release cycle with custom versioning
Possibly, we can we add additional section to the document you introduced for this part.
Also, it seems that full JDK11 support (including building) would be a huge milestone and a sign of healthy modern project that tends to be on the verge of mainstream technologies and not the stockpile of legacy leftovers (fully support Iliya in removing all that was deprecated and/or marked as unused anymore).
> On 8 Aug 2020, at 02:00, Valentin Kulichenko <va...@gmail.com> wrote:
>
> 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 the consensus on the proposed changes, I will
> start creating tickets in Jira and a more detailed plan.
>
> -Val
>
> On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <sa...@gmail.com>
> wrote:
>
>> Hi Denis, Val
>>
>> Thank you for your reply and really appreciate it. It will be very cool to
>> be able to connect and plan release together and learn more about Ignite in
>> the process :)
>>
>> Regards
>> Saikat
>>
>>
>>
>> On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko <
>> valentin.kulichenko@gmail.com> wrote:
>>
>>> Hi Saikat,
>>>
>>> That surely is a great idea. We will work together with Denis on setting
>>> this up in the nearest future.
>>>
>>> -Val
>>>
>>> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <dm...@apache.org> wrote:
>>>
>>>> Saikat,
>>>>
>>>> Fully support your idea on a virtual meetup! Once Val collects and
>>> outlines
>>>> the main changes with directions on wiki, we’ll go ahead and schedule
>> the
>>>> meetup to talk things out in a bit more detail. We’ll use our new
>> Virtual
>>>> Ignite Meetup group for that inviting both Ignite contributors and
>>>> application developers.
>>>>
>>>> Denis
>>>>
>>>> On Thursday, August 6, 2020, Saikat Maitra <sa...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Valentin
>>>>>
>>>>> Thank you for sharing and starting the thread. I am thinking if it
>> will
>>>> be
>>>>> a good idea to have a virtual meet setup to discuss on the release
>>>>> planning.
>>>>>
>>>>> It will help to learn more individual features to be added and also
>> to
>>>>> understand about features that have been deprecated and scheduled for
>>>>> removal in Ignite 3.0 release. Also it will help community member to
>>>>> connect in real time and ask questions and share feedback.
>>>>>
>>>>> Regards,
>>>>> Saikat
>>>>>
>>>>> On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <
>>>> ilya.kasnacheev@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hello!
>>>>>>
>>>>>> I hope to see Apache Ignite release 3.0 as API trimming release.
>> Let
>>> us
>>>>>> correct external and internal APIs for which we have better ideas
>>> now,
>>>> as
>>>>>> well as remove old and deprecated code.
>>>>>>
>>>>>> We may also introduce new configuration mechanisms and user-facing
>>> API
>>>>>> (such as cache-less native SQL queries), but this we could
>> prototype
>>>>> before
>>>>>> starting the 3.0 task.
>>>>>>
>>>>>> I will advise against targeting large new features at 3.0. They can
>>> be
>>>>>> added in subsequent point releases, whereas we can't really remove
>> or
>>>>>> remodel stuff in point releases.
>>>>>>
>>>>>> Regards,
>>>>>> --
>>>>>> Ilya Kasnacheev
>>>>>>
>>>>>>
>>>>>> чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
>>>>>> valentin.kulichenko@gmail.com>:
>>>>>>
>>>>>>> Igniters,
>>>>>>>
>>>>>>> I would like to kick off a discussion regarding Ignite 3.0.
>> Ignite
>>>> 2.0
>>>>>>> exists for more than 3 years now and we've already collected a
>>>>>> significant
>>>>>>> list [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
>>>>
>>>
>>
Re: Apache Ignite 3.0
Posted by Valentin Kulichenko <va...@gmail.com>.
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 the consensus on the proposed changes, I will
start creating tickets in Jira and a more detailed plan.
-Val
On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra <sa...@gmail.com>
wrote:
> Hi Denis, Val
>
> Thank you for your reply and really appreciate it. It will be very cool to
> be able to connect and plan release together and learn more about Ignite in
> the process :)
>
> Regards
> Saikat
>
>
>
> On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko <
> valentin.kulichenko@gmail.com> wrote:
>
> > Hi Saikat,
> >
> > That surely is a great idea. We will work together with Denis on setting
> > this up in the nearest future.
> >
> > -Val
> >
> > On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <dm...@apache.org> wrote:
> >
> > > Saikat,
> > >
> > > Fully support your idea on a virtual meetup! Once Val collects and
> > outlines
> > > the main changes with directions on wiki, we’ll go ahead and schedule
> the
> > > meetup to talk things out in a bit more detail. We’ll use our new
> Virtual
> > > Ignite Meetup group for that inviting both Ignite contributors and
> > > application developers.
> > >
> > > Denis
> > >
> > > On Thursday, August 6, 2020, Saikat Maitra <sa...@gmail.com>
> > > wrote:
> > >
> > > > Hi Valentin
> > > >
> > > > Thank you for sharing and starting the thread. I am thinking if it
> will
> > > be
> > > > a good idea to have a virtual meet setup to discuss on the release
> > > > planning.
> > > >
> > > > It will help to learn more individual features to be added and also
> to
> > > > understand about features that have been deprecated and scheduled for
> > > > removal in Ignite 3.0 release. Also it will help community member to
> > > > connect in real time and ask questions and share feedback.
> > > >
> > > > Regards,
> > > > Saikat
> > > >
> > > > On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <
> > > ilya.kasnacheev@gmail.com>
> > > > wrote:
> > > >
> > > > > Hello!
> > > > >
> > > > > I hope to see Apache Ignite release 3.0 as API trimming release.
> Let
> > us
> > > > > correct external and internal APIs for which we have better ideas
> > now,
> > > as
> > > > > well as remove old and deprecated code.
> > > > >
> > > > > We may also introduce new configuration mechanisms and user-facing
> > API
> > > > > (such as cache-less native SQL queries), but this we could
> prototype
> > > > before
> > > > > starting the 3.0 task.
> > > > >
> > > > > I will advise against targeting large new features at 3.0. They can
> > be
> > > > > added in subsequent point releases, whereas we can't really remove
> or
> > > > > remodel stuff in point releases.
> > > > >
> > > > > Regards,
> > > > > --
> > > > > Ilya Kasnacheev
> > > > >
> > > > >
> > > > > чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
> > > > > valentin.kulichenko@gmail.com>:
> > > > >
> > > > > > Igniters,
> > > > > >
> > > > > > I would like to kick off a discussion regarding Ignite 3.0.
> Ignite
> > > 2.0
> > > > > > exists for more than 3 years now and we've already collected a
> > > > > significant
> > > > > > list [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
> > >
> >
>
Re: Apache Ignite 3.0
Posted by Saikat Maitra <sa...@gmail.com>.
Hi Denis, Val
Thank you for your reply and really appreciate it. It will be very cool to
be able to connect and plan release together and learn more about Ignite in
the process :)
Regards
Saikat
On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko <
valentin.kulichenko@gmail.com> wrote:
> Hi Saikat,
>
> That surely is a great idea. We will work together with Denis on setting
> this up in the nearest future.
>
> -Val
>
> On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <dm...@apache.org> wrote:
>
> > Saikat,
> >
> > Fully support your idea on a virtual meetup! Once Val collects and
> outlines
> > the main changes with directions on wiki, we’ll go ahead and schedule the
> > meetup to talk things out in a bit more detail. We’ll use our new Virtual
> > Ignite Meetup group for that inviting both Ignite contributors and
> > application developers.
> >
> > Denis
> >
> > On Thursday, August 6, 2020, Saikat Maitra <sa...@gmail.com>
> > wrote:
> >
> > > Hi Valentin
> > >
> > > Thank you for sharing and starting the thread. I am thinking if it will
> > be
> > > a good idea to have a virtual meet setup to discuss on the release
> > > planning.
> > >
> > > It will help to learn more individual features to be added and also to
> > > understand about features that have been deprecated and scheduled for
> > > removal in Ignite 3.0 release. Also it will help community member to
> > > connect in real time and ask questions and share feedback.
> > >
> > > Regards,
> > > Saikat
> > >
> > > On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <
> > ilya.kasnacheev@gmail.com>
> > > wrote:
> > >
> > > > Hello!
> > > >
> > > > I hope to see Apache Ignite release 3.0 as API trimming release. Let
> us
> > > > correct external and internal APIs for which we have better ideas
> now,
> > as
> > > > well as remove old and deprecated code.
> > > >
> > > > We may also introduce new configuration mechanisms and user-facing
> API
> > > > (such as cache-less native SQL queries), but this we could prototype
> > > before
> > > > starting the 3.0 task.
> > > >
> > > > I will advise against targeting large new features at 3.0. They can
> be
> > > > added in subsequent point releases, whereas we can't really remove or
> > > > remodel stuff in point releases.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
> > > > valentin.kulichenko@gmail.com>:
> > > >
> > > > > Igniters,
> > > > >
> > > > > I would like to kick off a discussion regarding Ignite 3.0. Ignite
> > 2.0
> > > > > exists for more than 3 years now and we've already collected a
> > > > significant
> > > > > list [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
> >
>
Re: Apache Ignite 3.0
Posted by Valentin Kulichenko <va...@gmail.com>.
Hi Saikat,
That surely is a great idea. We will work together with Denis on setting
this up in the nearest future.
-Val
On Thu, Aug 6, 2020 at 10:21 AM Denis Magda <dm...@apache.org> wrote:
> Saikat,
>
> Fully support your idea on a virtual meetup! Once Val collects and outlines
> the main changes with directions on wiki, we’ll go ahead and schedule the
> meetup to talk things out in a bit more detail. We’ll use our new Virtual
> Ignite Meetup group for that inviting both Ignite contributors and
> application developers.
>
> Denis
>
> On Thursday, August 6, 2020, Saikat Maitra <sa...@gmail.com>
> wrote:
>
> > Hi Valentin
> >
> > Thank you for sharing and starting the thread. I am thinking if it will
> be
> > a good idea to have a virtual meet setup to discuss on the release
> > planning.
> >
> > It will help to learn more individual features to be added and also to
> > understand about features that have been deprecated and scheduled for
> > removal in Ignite 3.0 release. Also it will help community member to
> > connect in real time and ask questions and share feedback.
> >
> > Regards,
> > Saikat
> >
> > On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <
> ilya.kasnacheev@gmail.com>
> > wrote:
> >
> > > Hello!
> > >
> > > I hope to see Apache Ignite release 3.0 as API trimming release. Let us
> > > correct external and internal APIs for which we have better ideas now,
> as
> > > well as remove old and deprecated code.
> > >
> > > We may also introduce new configuration mechanisms and user-facing API
> > > (such as cache-less native SQL queries), but this we could prototype
> > before
> > > starting the 3.0 task.
> > >
> > > I will advise against targeting large new features at 3.0. They can be
> > > added in subsequent point releases, whereas we can't really remove or
> > > remodel stuff in point releases.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
> > > valentin.kulichenko@gmail.com>:
> > >
> > > > Igniters,
> > > >
> > > > I would like to kick off a discussion regarding Ignite 3.0. Ignite
> 2.0
> > > > exists for more than 3 years now and we've already collected a
> > > significant
> > > > list [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
>
Re: Apache Ignite 3.0
Posted by Denis Magda <dm...@apache.org>.
Saikat,
Fully support your idea on a virtual meetup! Once Val collects and outlines
the main changes with directions on wiki, we’ll go ahead and schedule the
meetup to talk things out in a bit more detail. We’ll use our new Virtual
Ignite Meetup group for that inviting both Ignite contributors and
application developers.
Denis
On Thursday, August 6, 2020, Saikat Maitra <sa...@gmail.com> wrote:
> Hi Valentin
>
> Thank you for sharing and starting the thread. I am thinking if it will be
> a good idea to have a virtual meet setup to discuss on the release
> planning.
>
> It will help to learn more individual features to be added and also to
> understand about features that have been deprecated and scheduled for
> removal in Ignite 3.0 release. Also it will help community member to
> connect in real time and ask questions and share feedback.
>
> Regards,
> Saikat
>
> On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <il...@gmail.com>
> wrote:
>
> > Hello!
> >
> > I hope to see Apache Ignite release 3.0 as API trimming release. Let us
> > correct external and internal APIs for which we have better ideas now, as
> > well as remove old and deprecated code.
> >
> > We may also introduce new configuration mechanisms and user-facing API
> > (such as cache-less native SQL queries), but this we could prototype
> before
> > starting the 3.0 task.
> >
> > I will advise against targeting large new features at 3.0. They can be
> > added in subsequent point releases, whereas we can't really remove or
> > remodel stuff in point releases.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
> > valentin.kulichenko@gmail.com>:
> >
> > > Igniters,
> > >
> > > I would like to kick off a discussion regarding Ignite 3.0. Ignite 2.0
> > > exists for more than 3 years now and we've already collected a
> > significant
> > > list [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
Re: Apache Ignite 3.0
Posted by Saikat Maitra <sa...@gmail.com>.
Hi Valentin
Thank you for sharing and starting the thread. I am thinking if it will be
a good idea to have a virtual meet setup to discuss on the release
planning.
It will help to learn more individual features to be added and also to
understand about features that have been deprecated and scheduled for
removal in Ignite 3.0 release. Also it will help community member to
connect in real time and ask questions and share feedback.
Regards,
Saikat
On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev <il...@gmail.com>
wrote:
> Hello!
>
> I hope to see Apache Ignite release 3.0 as API trimming release. Let us
> correct external and internal APIs for which we have better ideas now, as
> well as remove old and deprecated code.
>
> We may also introduce new configuration mechanisms and user-facing API
> (such as cache-less native SQL queries), but this we could prototype before
> starting the 3.0 task.
>
> I will advise against targeting large new features at 3.0. They can be
> added in subsequent point releases, whereas we can't really remove or
> remodel stuff in point releases.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
> valentin.kulichenko@gmail.com>:
>
> > Igniters,
> >
> > I would like to kick off a discussion regarding Ignite 3.0. Ignite 2.0
> > exists for more than 3 years now and we've already collected a
> significant
> > list [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
> >
>
Re: Apache Ignite 3.0
Posted by Ilya Kasnacheev <il...@gmail.com>.
Hello!
I hope to see Apache Ignite release 3.0 as API trimming release. Let us
correct external and internal APIs for which we have better ideas now, as
well as remove old and deprecated code.
We may also introduce new configuration mechanisms and user-facing API
(such as cache-less native SQL queries), but this we could prototype before
starting the 3.0 task.
I will advise against targeting large new features at 3.0. They can be
added in subsequent point releases, whereas we can't really remove or
remodel stuff in point releases.
Regards,
--
Ilya Kasnacheev
чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko <
valentin.kulichenko@gmail.com>:
> Igniters,
>
> I would like to kick off a discussion regarding Ignite 3.0. Ignite 2.0
> exists for more than 3 years now and we've already collected a significant
> list [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
>