Re: [Announce] New committer: Iurii Gerzhedovich

[Maxim Muzafarov]

Congratulations, Iurii!

On Thu, 15 Feb 2024 at 09:31, Юрий  wrote:
>
> Thank you everyone, I'm very pleased!
>
> ср, 14 февр. 2024 г. в 17:28, Pavel Pereslegin :
>
> > Congratulations, Iurii!
> >
> > ср, 14 февр. 2024 г. в 09:29, Pavel Tupitsyn :
> > >
> > > Congratulations Iurii!
> > >
> > > On Wed, Feb 14, 2024 at 8:17 AM Roman Puchkovskiy <
> > > roman.puchkovs...@gmail.com> wrote:
> > >
> > > > Congratulations!
> > > >
> > > > вт, 13 февр. 2024 г. в 23:51, Dmitriy Pavlov :
> > > > >
> > > > > Dear Igniters,
> > > > >
> > > > > The Project Management Committee (PMC) for Apache Ignite
> > > > > has invited Iurii Gerzhedovich to become a committer and we are
> > pleased
> > > > > to announce that he has accepted.
> > > > >
> > > > > Being a committer enables easier contribution to the
> > > > > project since there is no need to go via the patch
> > > > > submission process. This should enable better productivity.
> > > > >
> > > > >
> > > > > Please join me in sincere congratulations to Iurii on his new role!
> > > > > Iurii, keep the pace!
> > > > >
> > > > >
> > > > > Sincerely,
> > > > > Dmitriy Pavlov on behalf of Apache Ignite PMC
> > > >
> >
>
>
> --
> Живи с улыбкой! :D

Re: [VOTE] Release Apache Ignite ML Extension 1.0.0 RC1

[Maxim Muzafarov]

+1

On Fri, 26 Jan 2024 at 13:05, Alex Plehanov  wrote:
>
> +1
>
> Checked sha512, signature. Built from sources. Checked examples.
>
> чт, 25 янв. 2024 г. в 20:56, Nikita Amelchev :
>
> >
> > +1 (binding)
> >
> > Checked compilation, tests and some examples.
> >
> > вт, 23 янв. 2024 г. в 16:57, Ivan Daschinsky :
> > >
> > > Sorry for my mistake, this vote will be open till Jan 26, 2024
> > >
> > > вт, 23 янв. 2024 г. в 16:27, Ivan Daschinsky :
> > >
> > > > Dear Community,
> > > > I am happy to start this voting thread.
> > > >
> > > > The release candidate have been uploaded to:
> > > >
> > > > https://dist.apache.org/repos/dist/dev/ignite/ignite-extensions/ignite-ml-ext-1.0.0-rc1/
> > > >
> > > > The staging maven repository is here:
> > > > https://repository.apache.org/content/repositories/orgapacheignite-1560
> > > >
> > > > The release notes are here:
> > > >
> > > > https://github.com/apache/ignite-extensions/blob/ignite-ml-ext-1.0.0-rc1/modules/ml-ext/ml/RELEASE_NOTES.txt
> > > >
> > > > The release checker results are here:
> > > > https://github.com/apache/ignite-extensions/actions/runs/7626105841
> > > >
> > > > The TC run is here:
> > > >
> > > > https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Ml/7716025?hideProblemsFromDependencies=false=false
> > > >
> > > >
> > > >
> > > > The vote is formal, see voting guidelines
> > > > https://www.apache.org/foundation/voting.html
> > > >
> > > > +1 - to accept
> > > > 0 - don't care either way
> > > > -1 - DO NOT accept (explain why)
> > > >
> > > > See notes on how to verify release here
> > > > https://www.apache.org/info/verification.html
> > > > and
> > > >
> > > > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
> > > >
> > > >
> > > > This vote will be open for at least 4 days till Fri Jan 26, 2022,
> > > > 17:00 UTC+3. Please, write me down the thread if you need
> > > > additional time to check the release.
> > > >
> > >
> > >
> > > --
> > > Sincerely yours, Ivan Daschinskiy
> >
> >
> >
> > --
> > Best wishes,
> > Amelchev Nikita

Re: [VOTE] Release Apache Ignite 2.16.0 RC0

[Maxim Muzafarov]

+1

Checked checksums, run locally.

On Sun, 24 Dec 2023 at 13:33, Anton Vinogradov  wrote:
>
> +1
>
> Вс, 24 дек. 2023 г. в 15:19, Николай Ижиков :
>
> > +1 (binding)
> >
> > Отправлено с iPhone
> >
> > > 24 дек. 2023 г., в 00:13, Ivan Daschinsky 
> > написал(а):
> > >
> > > +1 from me (binding)
> > >
> > > 1. Checked checksums
> > > 2. Checked C++/ODBC driver: built from source and ran examples on Ubuntu
> > > 22.04/gcc 11.4.0/OpenJDK-Temurin 17.0.8
> > > 3. Checked ODBC driver with pyodbc (python 3.11 + pyodbc 4.0.35). Checked
> > > on calcite and H2 engines. (Ubuntu 22.04)
> > >
> > > вт, 19 дек. 2023 г. в 13:54, Zhenya Stanilovsky
> >  > >> :
> > >
> > >>
> > >> Finally i build it (some local maven problems).
> > >> Check compilation, run calcite tests.
> > >> +1 (non-binding)
> > >>
> > >>>
> > 
> > > Hello, Zhenya.
> > >
> > > Java profiles should be activated automatically (on reload maven
> > > project). Which JDK are you using? Is the project built from maven?
> > >
> > > I can't reproduce on HotSpot 1.8.0_201-b09, OpenJDK 21+35-2513.
> > >
> > > вт, 19 дек. 2023г. в 11:16, Zhenya Stanilovsky <
> > >> arzamas...@mail.ru.invalid >:
> > >>
> > >>
> > >> Hi, probably it`s a kind of problem from my side, but cloning by tag
> > >> and further steps:
> > >> * change profile to java-8
> > >> * Reload all maven Projects
> > >> * Try to run: ScriptTestSuite will raise guava dependency problem:
> > >>
> > >>
> > /ignite/internal/processors/query/calcite/sql/IgniteSqlRollback.java:20:33
> > >> java: package com.google.common.collect does not exist
> > >> ---
> > >> * change profile to java-9
> > >> * reload
> > >> * the same problem :
> > >>
> > >>
> > modules/core/src/test/java/org/apache/ignite/testframework/GridTestUtils.java:79:33
> > >> java: package com.google.common.collect does not exist
> > >>
> > >> probably i need to clean all and try to rebuild from scratch .. for
> > >> now it`s not clear for me.
> > >>
> > >>> +1
> > >>>
> > >>> - Started the node from binaries
> > >>> - Tested .NET examples
> > >>> - Tested NuGet packages
> > >>>
> > >>> On Sun, Dec 17, 2023 at 2:48PM Nikita Amelchev <
> > >> namelc...@apache.org >
> > >>> wrote:
> > >>>
> >  Dear Community,
> > 
> >  The release candidate is ready.
> > 
> >  I have uploaded release candidate to
> >  https://dist.apache.org/repos/dist/dev/ignite/2.16.0-rc0
> >  https://dist.apache.org/repos/dist/dev/ignite/packages_2.16.0-rc0
> > 
> >  The following staging can be used for testing:
> > 
> > >> https://repository.apache.org/content/repositories/orgapacheignite-1559
> > 
> >  Tag name is 2.16.0-rc0:
> >  https://github.com/apache/ignite/releases/tag/2.16.0-rc0
> > 
> >  2.16.0 most important changes:
> >  * Cache dumps;
> >  * Calcite engine: added hints, became more stable, covered with
> >  diagnostic tools;
> >  * Fixes to support JDK 14-21;
> >  * Cluster Management API (IEP-81);
> >  * Java thin client: Service Awareness feature;
> >  etc.
> > 
> >  RELEASE NOTES:
> > 
> > 
> > >>
> > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.16
> > 
> >  Complete list of resolved issues:
> > 
> > 
> > >>
> > https://issues.apache.org/jira/browse/IGNITE-19650?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.16%27))%20AND%20(component%20is%20EMPTY%20OR%20component%20not%20in%20(documentation))%20and%20status%20in%20(%27CLOSED%27%2C%20%27RESOLVED%27)%20AND%20resolution%20in(Fixed%2C%20Done%2C%20Implemented%2C%20Delivered)%20ORDER%20BY%20priority
> > 
> >  DEVNOTES
> > 
> > 
> > >>
> > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=ignite-2.16
> > 
> >  The vote is formal, see voting guidelines
> >  https://www.apache.org/foundation/voting.html
> > 
> >  +1 - to accept Apache Ignite 2.16.0-rc0
> >  0 - don't care either way
> >  -1 - DO NOT accept Apache Ignite 2.16.0-rc0 (explain why)
> > 
> >  See notes on how to verify release here
> >  https://www.apache.org/info/verification.html
> >  and
> > 
> > 
> > >>
> > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
> > 
> >  This vote will be open till Sun December 24, 2023, 15:00 UTC.
> > 
> > 
> > >>
> > https://www.timeanddate.com/countdown/vote?iso=20231224T15=0=VOTE+on+the+Apache+Ignite+Release+2.16.0+RC0=sanserif
> > 
> >  --
> >  

Re: New Apache Ignite PMC member: Nikita Amelchev

[Maxim Muzafarov]

My congratulations, Nikita!

On Tue, 21 Nov 2023 at 15:20, Dmitriy Pavlov  wrote:
>
> Hello Igniters,
>
> The Project Management Committee (PMC) for Apache Ignite
> has invited Nikita Amelchev to become a member of PMC and we are pleased
> to announce that he has accepted.
>
> We appreciate his constant efforts in improving Apache Ignite code, as well
> as efforts in preparing 2 major releases.
>
> A PMC member helps manage and guide the direction of the project.
>
> Congratulations on your new role! Keep the pace!
>
> Best Regards
> Dmitriy Pavlov
> on behalf of Apache Ignite PMC

Re: [VOTE] Release Apache Ignite 2.15.0 RC0

[Maxim Muzafarov]

+1

On Fri, 28 Apr 2023 at 09:54, Vladimir Steshin  wrote:
>
> + 1
>
> 26.04.2023 22:51, Alex Plehanov пишет:
> > Dear Community,
> >
> > The release candidate is ready.
> >
> > I have uploaded release candidate to
> > https://dist.apache.org/repos/dist/dev/ignite/2.15.0-rc0/
> > https://dist.apache.org/repos/dist/dev/ignite/packages_2.15.0-rc0/
> >
> > The following staging can be used for testing:
> > https://repository.apache.org/content/repositories/orgapacheignite-1558/
> >
> > Tag name is 2.15.0-rc0:
> > https://gitbox.apache.org/repos/asf?p=ignite.git;a=tag;h=refs/tags/2.15.0-rc0
> >
> > 2.15.0 most important changes:
> > * Implemented incremental snapshots.
> > * Java thin client improvements (logging, connections balancing, events
> > listening, endpoints discovery)
> > * Calcite based SQL engine improvements (memory quotas, index scans
> > optimisations).
> > * Reworked permission management for system tasks.
> > * Removed deprecated functionality (daemon nodes, visorcmd, legacy JMX
> > beans).
> >
> > RELEASE NOTES:
> > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.15
> >
> > Complete list of resolved issues:
> > https://issues.apache.org/jira/issues/?jql=(project%20%3D%20'Ignite'%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20('2.15'))%20AND%20(component%20is%20EMPTY%20OR%20component%20not%20in%20(documentation))%20and%20status%20in%20('CLOSED'%2C%20'RESOLVED')%20AND%20resolution%20in(Fixed%2C%20Done%2C%20Implemented%2C%20Delivered)%20ORDER%20BY%20priority
> > 
> >
> >
> > DEVNOTES
> > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=ignite-2.15
> >
> > The vote is formal, see voting guidelines https://www.apache.org/foundation/
> > voting.html
> >
> > +1 - to accept Apache Ignite 2.15.0-rc0
> > 0 - don't care either way
> > -1 - DO NOT accept Apache Ignite Ignite 2.15.0-rc0 (explain why)
> >
> > See notes on how to verify release here
> > https://www.apache.org/info/verification.html
> > and
> > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
> >
> > This vote will be open till Tue May 2, 2023, 07:00 UTC.
> > https://www.timeanddate.com/countdown/vote?iso=20230502T07=0=VOTE+on+the+Apache+Ignite+Release+2.15.0+RC0=sanserif
> >

Re: Apache Ignite 2.15 RELEASE [Time, Scope, Manager]

[Maxim Muzafarov]

+1

On Wed, 29 Mar 2023 at 20:57, Alex Plehanov  wrote:
>
> Dear Ignite Community!
>
> I suggest starting Apache Ignite 2.15 release activities.
>
> We've accumulated more than two hundred resolved issues [1] with new
> features and bug fixes which are waiting for release.
> The major changes related to the proposed release:
> - Incremental snapshots.
> - Java thin client improvements (logging, connections balancing,
> events listening, endpoints discovery)
> - Calcite based SQL engine improvements (memory quotas, index scans
> optimisations).
> - Reworked permission management for system tasks.
> - Removed some deprecated functionality (daemon nodes, visorcmd, legacy JMX
> beans)
> etc.
>
> I want to propose myself to be the release manager of the planning release.
>
> I propose the following timeline:
>
> Scope Freeze: April 08, 2023
> Code Freeze: April 15, 2023
> Voting Date: April 22, 2023
> Release Date: April 29, 2023
>
> [1].
> https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20in%20(2.15))%20AND%20(component%20is%20EMPTY%20OR%20component%20not%20in%20(documentation))%20and%20status%20in%20(%27CLOSED%27%2C%20%27RESOLVED%27)
>
> WDYT?

Re: [VOTE] Release bug fix release pyignite-0.6.1-rc0

[Maxim Muzafarov]

+1

On Wed, 15 Feb 2023 at 11:17, Вячеслав Коптилин
 wrote:
>
> +1
>
>
> ср, 15 февр. 2023 г. в 10:21, Ivan Daschinsky :
>
> > Dear Igniters!
> >
> > This is a patch release that contains an important fix for users of
> > pyignite
> >
> > https://issues.apache.org/jira/browse/IGNITE-18788
> >
> >
> > Release candidate binaries for subj are uploaded and ready for vote
> > You can find them here:
> > https://dist.apache.org/repos/dist/dev/ignite/pyignite/0.6.1-rc0
> >
> > If you follow the link above, you will find source packages (*.tar.gz and
> > *.zip)
> > and binary packages (wheels) for windows (amd64), linux (x86_64) amd mac os
> > (x86_64)
> > for pythons 37, 38, 39, 310 and 311. Also, there are sha512 and gpg
> > signatures.
> > Code signing keys can be found here -- https://downloads.apache.org/ignite
> > /KEYS
> > Here you can find instructions how to verify packages
> > https://www.apache.org/info/verification.html
> >
> > You can install binary package for specific version of python using pip
> > For example do this on linux for python 3.8
> > >> pip install
> >
> > pyignite-0.6.1-cp38-cp38-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl
> >
> > You can build and install package from source using this command:
> > >> pip install pyignite-0.6.1.zip
> > You can build wheel on your platform using this command:
> > >> pip wheel --no-deps pyignite-0.6.1.zip
> >
> > For building C module, you should have python headers and C compiler
> > installed.
> > (i.e. for ubuntu sudo apt install build-essential python3-dev)
> > In Mac OS X xcode-tools and python from homebrew are the best option.
> >
> > In order to check whether C module works, use following:
> > >> from pyignite import _cutils
> > >> print(_cutils.hashcode('test'))
> > >> 3556498
> >
> > You can find documentation here:
> > https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.1.rc0/
> >
> > You can find examples here (to check them, you should start ignite
> > locally):
> >
> > https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.1.rc0/examples.html
> > Also, examples can be found in source archive in examples subfolder.
> > docker-compose.yml is supplied in order to start ignite quickly. (Use
> > `docker-compose up -d` to start 3 nodes cluster and `docker-compose
> > down` to shut down it)
> >
> > Release notes:
> >
> > https://gitbox.apache.org/repos/asf?p=ignite-python-thin-client.git;a=blob;f=RELEASE_NOTES.txt;h=86448e9ce51d7223ac49cf4f95da70d3d365e8c1;hb=0d86f44e86270f4d578afbce41aa2d6c424d2615
> >
> > Git release tag was created:
> >
> > https://gitbox.apache.org/repos/asf?p=ignite-python-thin-client.git;a=tag;h=b0ce094d7a2db3fb07471be7b37ff9edab4180a8
> >
> > The vote is formal, see voting guidelines
> > https://www.apache.org/foundation/voting.html
> >
> > +1 - to accept pyignite-0.6.1-rc0
> > 0 - don't care either way
> > -1 - DO NOT accept pyignite-0.6.1-rc0
> >
> > The vote finishes at 02/17/2021 15:00 UTC
> >
> > --
> > Sincerely yours, Ivan Daschinskiy
> >

[ANNOUNCE] Ignite Spark Extension 2.0.0 and 3.0.0 Released

[Maxim Muzafarov]

The Apache Ignite Community is pleased to announce the release of the
Apache Ignite Extension that adds support for the Apache Spark 3.2
version:

- Ignite Spark Extension 3.0.0 (integration with Spark 3.2)
- Ignite Spark Extension 2.0.0 (integration with Spark 2.4)

Apache Ignite® is a Distributed Database For High-Performance
Computing With In-Memory Speed that is used by Apache Spark users to:

- achieve true in-memory performance at scale and avoid data movement
from a data source to Spark workers and applications;
- boost DataFrame and SQL performance;
- more easily share state and data among Spark jobs.

You can find all the details here:
https://ignite.apache.org/docs/latest/extensions-and-integrations/ignite-for-spark/overview

https://mvnrepository.com/artifact/org.apache.ignite/ignite-spark-ext

Please let us know if you encounter any problems:
https://ignite.apache.org/community/resources.html#ask


--
Best Regards,
Maxim Muzafarov
on behalf of Apache Ignite PMC

Re: [VOTE] Release Extensions Ignite Spark 2.0.0 RC1, Ignite Spark 3.0.0 RC1

[Maxim Muzafarov]

+1

On Mon, 12 Dec 2022 at 09:59, Andrey Gura  wrote:
>
> +1
>
> On Fri, Dec 9, 2022 at 10:36 AM Nikita Amelchev  wrote:
> >
> > +1
> >
> > Checked compilation, ran some examples.
> >
> > пт, 9 дек. 2022 г. в 03:53, Alexandr Shapkin :
> > >
> > > Dear Community,
> > >
> > >
> > > The release candidates are ready.
> > >
> > > These are new Ignite Spark integrations based on Spark 2.4 and 3.2 
> > > dependencies respectively.
> > >
> > >
> > > See the links below.
> > >
> > >
> > > == Ignite Spark Extension Module 2.0.0 ==
> > >
> > > The release candidate is uploaded to:
> > > https://dist.apache.org/repos/dist/dev/ignite/ignite-extensions/ignite-spark-ext-2.0.0-rc1/
> > >
> > > The following Maven staging can be used:
> > > https://repository.apache.org/content/repositories/orgapacheignite-1557/org/apache/ignite/ignite-spark-ext/
> > >
> > > Tag:
> > > https://github.com/apache/ignite-extensions/releases/tag/ignite-spark-ext-2.0.0-rc1
> > >
> > > RELEASE_NOTES:
> > > https://github.com/apache/ignite-extensions/blob/release/ignite-spark-ext-2.0.0/modules/spark-ext/spark/RELEASE_NOTES.txt
> > >
> > > DEVNOTES:
> > > https://github.com/apache/ignite-extensions/blob/release/ignite-spark-ext-2.0.0/DEVNOTES.md
> > >
> > > Release Checker Results:
> > > https://github.com/apache/ignite-extensions/actions/runs/3652976657
> > >
> > >
> > >
> > > == Ignite Spark Extension Module 3.0.0 ==
> > >
> > > The release candidate is uploaded to:
> > > https://dist.apache.org/repos/dist/dev/ignite/ignite-extensions/ignite-spark-ext-3.0.0-rc1/
> > >
> > > The following Maven staging can be used:
> > > https://repository.apache.org/content/repositories/orgapacheignite-1557/org/apache/ignite/ignite-spark-ext/
> > >
> > > Tag:
> > > https://github.com/apache/ignite-extensions/releases/tag/ignite-spark-ext-3.0.0-rc1
> > >
> > > RELEASE_NOTES:
> > > https://github.com/apache/ignite-extensions/blob/release/ignite-spark-ext-3.0.0/modules/spark-ext/spark/RELEASE_NOTES.txt
> > >
> > > DEVNOTES:
> > > https://github.com/apache/ignite-extensions/blob/release/ignite-spark-ext-3.0.0/DEVNOTES.md
> > >
> > > Release Checker Results:
> > > https://github.com/apache/ignite-extensions/actions/runs/3634524603
> > >
> > >
> > >
> > > The vote is formal, see voting guidelines
> > > https://www.apache.org/foundation/voting.html
> > >
> > > +1 - to accept (Ignite Spark 3.0.0 RC1, Ignite Spark 2.0.0 RC1)
> > > 0 - don't care either way
> > > -1 - DO NOT accept (explain why)
> > >
> > > See notes on how to verify release here
> > > https://www.apache.org/info/verification.html
> > > and
> > > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
> > >
> > >
> > > This vote will be open for at least 72 hours till Mon Dec, 12 2022, 02:00 
> > > CET TZ.
> > > Please, write down the thread if you need additional time to check the 
> > > release.
> > >
> >
> >
> > --
> > Best wishes,
> > Amelchev Nikita

Re: Re[2]: [DISCUSSION] Removal of ignitevisorcmd

[Maxim Muzafarov]

+1


> GridClient and related classes are not used by visorcmd, but used by 
> control.sh and can't be removed.

I think it should not be too difficult to migrate GridClient ->
IgniteClient and once it will happen the removal becomes be possible.

On Thu, 1 Dec 2022 at 07:30, Alex Plehanov  wrote:
>
> +1 for remove visorcmd and daemon nodes (there was already discussion about
> this on dev list as far as I remember).
> GridClient and related classes are not used by visorcmd, but used by
> control.sh and can't be removed.
>
> чт, 1 дек. 2022 г. в 09:00, Zhenya Stanilovsky :
>
> >
> > +1 for remove.
> >
> >
> >
> >
> > >+1 This module seems to be completely abandoned
> > >
> > >чт, 1 дек. 2022 г., 00:46 Ilya Kasnacheev < ilya.kasnach...@gmail.com >:
> > >
> > >> Hello!
> > >>
> > >> Let's go ahead and remove what we don't use. Most of that stuff is deep
> > >> legacy, even if it contains some rare gems of functionality that nobody
> > >> knows how to use anymore.
> > >>
> > >> Regards,
> > >> --
> > >> Ilya Kasnacheev
> > >>
> > >>
> > >> ср, 30 нояб. 2022 г. в 20:12, Nikolay Izhikov < nizhi...@apache.org >:
> > >>
> > >> > Hello, Igniters.
> > >> >
> > >> > There are legacy modules - visor-console, visor-plugins,
> > >> visor-console-2.10
> > >> > Looks like that modules are not evolving by community and barely used
> > by
> > >> > the Ignite users.
> > >> >
> > >> > I propose to remove it completely.
> > >> > There are IEP [1] for this
> > >> >
> > >> > It seems that removal of visor modules allow to us to remove another
> > >> legacy
> > >> > code from Ignite codebase:
> > >> >
> > >> > * support of daemon nodes.
> > >> > * GridClient and related classes.
> > >> >
> > >> > What do you think?
> > >> >
> > >> > [1]
> > >> >
> > >>
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=217392419
> > >> >
> > >>
> >
> >
> >
> >

Re: [VOTE] Release pyignite 0.6.0.rc1

[Maxim Muzafarov]

+1

On Tue, 15 Nov 2022 at 11:07, Anton Vinogradov  wrote:
>
> +1
>
> On Tue, Nov 15, 2022 at 11:25 AM Ilya Shishkov 
> wrote:
>
> > Hi,
> >
> > +1 from me.
> >
> > Checked out pyignite-0.6.0.zip with
> > pyignite-0.6.0-cp310-cp310-win_amd64.whl:
> > 1. Whl package installed via pip.
> > 2. All examples tested (with supplied docker-compose.yml).
> > 3. SHA512 hashes checked for both files (zip & whl).
> >
> > вт, 15 нояб. 2022 г. в 09:58, Ivan Daschinsky :
> >
> > > +1 (binding) Checked signature, hashsums, checked client on all 5 pythons
> > > on all available platforms (mac x86_64, ubuntu x86_84 and windows 10
> > > x86_64).
> > > Checked docs (readthedocs).
> > >
> > > вт, 15 нояб. 2022 г. в 09:10, Zhenya Stanilovsky
> > >  > > >:
> > >
> > > >
> > > > +1, thanks Ivan !
> > > >
> > > >
> > > > >Dear Igniters!
> > > > >
> > > > >Release candidate binaries for subj are uploaded and ready for vote
> > > > >You can find them here:
> > > > >https://dist.apache.org/repos/dist/dev/ignite/pyignite/0.6.0.rc1
> > > > >
> > > > >If you follow the link above, you will find source packages (*.zip)
> > > > >and binary packages (wheels) for windows (amd64), mac os x (amd64) and
> > > > >linux (x86_64)
> > > > >for pythons 37, 38, 39, 310 and 311. Also, there are sha512 and gpg
> > > > >signatures.
> > > > >Code signing keys can be found here --
> > > > >https://downloads.apache.org/ignite/KEYS
> > > > >Here you can find instructions how to verify packages
> > > > >https://www.apache.org/info/verification.html
> > > > >
> > > > >You can install binary package for specific version of python using
> > pip
> > > > >For example do this on linux for python 3.8
> > > > >>> pip
> > > > >install
> > > >
> > >
> > pyignite-0.6.0-cp38-cp38-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl
> > > > >
> > > > >You can build and install package from source using this command:
> > > > >>> pip install pyignite-0.6.0.zip
> > > > >You can build wheel on your platform using this command:
> > > > >>> pip wheel --no-deps pyignite-0.6.0.zip
> > > > >
> > > > >For building C module, you should have python headers and C compiler
> > > > >installed.
> > > > >(i.e. for ubuntu sudo apt install build-essential python3-dev)
> > > > >In Mac OS X xcode-tools and python from homebrew are the best option.
> > > > >
> > > > >In order to check whether C module works, use following:
> > > > >>> from pyignite import _cutils
> > > > >>> print(_cutils.hashcode('test'))
> > > > >>> 3556498
> > > > >
> > > > >You can find documentation here:
> > > > >
> > >
> > https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.0.rc1/
> > > > >
> > > > >You can find examples here (to check them, you should start ignite
> > > > locally):
> > > > >
> > > >
> > >
> > https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.0.rc0/examples.html
> > > > >Also, examples can be found in source archive in examples subfolder.
> > > > >docker-compose.yml is supplied in order to start ignite quickly. (Use
> > > > >`docker-compose up -d` to start 3 nodes cluster and `docker-compose
> > > > >down` to shut down it)
> > > > >
> > > > >Release notes:
> > > > >
> > > >
> > >
> > https://gitbox.apache.org/repos/asf?p=ignite-python-thin-client.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=995bda81780402116e89d76523949da88136f260
> > > > >
> > > > >Git release tag was created:
> > > > >
> > > >
> > >
> > https://gitbox.apache.org/repos/asf?p=ignite-python-thin-client.git;a=tag;h=ea3f180a0300abf25c992ed8c241defdc2b4bd4b
> > > > >
> > > > >The vote is formal, see voting guidelines
> > > > >https://www.apache.org/foundation/voting.html
> > > > >
> > > > >+1 - to accept pyignite-0.6.0.rc0
> > > > >0 - don't care either way
> > > > >-1 - DO NOT accept pyignite-0.6.0.rc0
> > > > >
> > > > >The vote finishes at 11/15/2022 15:00 UTC
> > > >
> > > >
> > > >
> > > >
> > >
> >

[ANNOUNCE] Welcome Mikhail Petrov as a new Committer

[Maxim Muzafarov]

The Project Management Committee (PMC) for Apache Ignite has invited
Mikhail Petrov to become a committer and we are pleased to announce
that they have accepted.

Mikhail Petrov is an active contributor and community member, he made
significant additions to Ignite and Ignite Extensions code bases, this
client support for Spring Data, Spring Transactions, tracing of SQL
queries etc.

Being a committer enables easier contribution to the project since
there is no need to go via the patch submission process. This should
enable better productivity.

Please join in welcoming Mikhail Petrov, and congratulating him on the
new role in the Apache Ignite Community!


Best Regards,
Maxim Muzafarov
on behalf of Apache Ignite PMC

Re: ignite-spark3.2-ext release

[Maxim Muzafarov]

Folks,

I can help with releasing this module (and actually it's pretty easy
to do a release using GA), but I have some notes according to
contribution:

1. We should merge spark3.2-ext and spark-ext and separate development
streams of different versions using branches with appropriate spark
versions in them (like we do it before). For instance,
ignite-spark-3.2 branch with 3.2 version etc. You can find an example
with the following branches [1][2].

2. We should update DEVNOTES with the release actions that should be
performed using GA (I can do it).


I would not be able to verify that everything works with spark 3.2
integration, but I can help with the release.

WDYT?


[1] 
https://github.com/apache/ignite-extensions/tree/release/ignite-hibernate-ext-4.2.0
[2] 
https://github.com/apache/ignite-extensions/tree/release/ignite-hibernate-ext-5.1.0

On Mon, 7 Nov 2022 at 08:15, Ivan Gagarkin  wrote:
>
> Hi Alexandr,
> I would be glad if you can.
> Not sure about all information. Vladimir Pligin has more details.
> Right, no progress.
>
> On Fri, 4 Nov 2022 at 02:12, Alexandr Shapkin  wrote:
>
> > Hi Ivan,
> >
> > I’d like to help with that. Is all release-related information described
> > in the DEVNOTES?
> >
> > I suppose there has not been any progress on the release since your
> > initial message, correct?
> >
> > > On 26 Oct 2022, at 09:05, Ivan Gagarkin  wrote:
> > >
> > > Hi, Igniters
> > > ignite-spark3.2-ext is ready for release. We have to make some steps to
> > do
> > > that:
> > >
> > >   - Create a branch
> > >   - Run some jobs on github
> > >
> > > https://github.com/apache/ignite-extensions/blob/master/DEVNOTES.md
> > > Who can help me with that?
> > >
> > >
> > >
> > > --
> > > Best Regards, Ivan
> >
> >
>
> --
> С уважением, Гагаркин И.Ю.

Re: [VOTE] Release Apache Ignite 2.14.0 RC0

[Maxim Muzafarov]

+1 (binding)

On Mon, 3 Oct 2022 at 14:05, Ivan Daschinsky  wrote:
>
> +1 (binding)
>
> Checked C++ module and C++ examples compilation on windows 10 (msvc 2017)
> and ubuntu 22.04 (gcc 11.2.0).
> Checked ODBC on windows 10 and ubuntu 22.04 (unixodbc) by pyodbc and python
> script (both H2 and CALCITE query engines).
> Checked ODBC pre-built binaries on windows 10
>
> Despite the fact that separation of H2 and CALCITE has been announced, H2
> (ignite-indexing) is still required for ODBC and CALCITE queries.
> Created issue for it -- https://issues.apache.org/jira/browse/IGNITE-17800
>
>
> пн, 3 окт. 2022 г. в 13:42, mwiesenberg :
>
> > +1
> > started a node with calcite, inserted data, ran a sql query.
> >
> > On Mon, Oct 3, 2022 at 2:46 AM Pavel Tupitsyn 
> > wrote:
> >
> > > +1
> > >
> > > Started .NET and Java nodes, checked examples, checked NuGet packages.
> > >
> > > On Fri, Sep 30, 2022 at 4:07 PM Alex Plehanov 
> > > wrote:
> > >
> > > > > Added new experimental, Apache Calcite based SQL engine
> > > > It was added in 2.13, in 2.14 it became ignite-indexing (and H2)
> > > > independent.
> > > >
> > > > +1
> > > >
> > > > Build from sources, start a cluster of two nodes, try some queries on
> > > > Calcite SQL engine (with removed ignite-indexing module).
> > > >
> > > > пт, 30 сент. 2022 г. в 15:02, Zhenya Stanilovsky
> > > >  > > > >:
> > > >
> > > > >
> > > > >
> > > > > I think it`s important to mention that local caches are not supported
> > > > > since this version [1].
> > > > >
> > > > > [1]  https://issues.apache.org/jira/browse/IGNITE-15759
> > > > >
> > > > >
> > > > > >Dear Community,
> > > > > >
> > > > > >The release candidate is ready.
> > > > > >
> > > > > >I have uploaded release candidate to
> > > > > >https://dist.apache.org/repos/dist/dev/ignite/2.14.0-rc0/
> > > > > >https://dist.apache.org/repos/dist/dev/ignite/packages_2.14.0-rc0/
> > > > > >
> > > > > >The following staging can be used for testing:
> > > > > >
> > > >
> > https://repository.apache.org/content/repositories/orgapacheignite-1552/
> > > > > >
> > > > > >Tag name is 2.14.0-rc0:
> > > > > >
> > > > >
> > > >
> > >
> > https://gitbox.apache.org/repos/asf?p=ignite.git;a=tag;h=refs/tags/2.14.0-rc0
> > > > > >
> > > > > >2.14.0 most important changes:
> > > > > >* Added new experimental, Apache Calcite based SQL engine
> > > > > >* Added support of IGNITE_TO_STRING_INCLUDE_SENSITIVE option by
> > > > > Сonsistency check command
> > > > > >* CPP Thin: Implemented asynchronous network events handling
> > > > > >* CPP thin: Implemented continuous queries
> > > > > >* Deprecated IgniteServices#service(String) and
> > > > > IgniteServices#services(String).
> > > > > >* Implemented CDC for in-memory caches
> > > > > >* Implemented NUMA aware allocator for Ignite durable memory
> > > > > >* Implemented Read Repair strategies
> > > > > >* Implemented array component type in binary object
> > > > > >* Removed the legacy service grid implementation
> > > > > >
> > > > > >RELEASE NOTES:
> > > > > >
> > > > >
> > > >
> > >
> > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.14
> > > > > >
> > > > > >Complete list of resolved issues:
> > > > > >https://issues.apache.org/jira/issues/?jql=(project%20%3D%20
> > > > >
> > > >
> > >
> > 'Ignite'%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20('2.14'))%20AND%20(component%20is%20EMPTY%20OR%20component%20not%20in%20(documentation))%20and%20status%20in%20('CLOSED'%2C%20'RESOLVED')%20AND%20resolution%20in(Fixed%2C%20Done%2C%20Implemented%2C%20Delivered)%20ORDER%20BY%20priority
> > > > > >
> > > > > >DEVNOTES
> > > > > >
> > > > >
> > > >
> > >
> > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=ignite-2.14
> > > > > >
> > > > > >The vote is formal, see voting guidelines
> > > > > https://www.apache.org/foundation/voting.html
> > > > > >
> > > > > >+1 - to accept Apache Ignite 2.14.0-rc0
> > > > > >0 - don't care either way
> > > > > >-1 - DO NOT accept Apache Ignite Ignite 2.14.0-rc0 (explain why)
> > > > > >
> > > > > >See notes on how to verify release here
> > > > > https://www.apache.org/info/verification.html
> > > > > >and
> > > > >
> > > >
> > >
> > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
> > > > > >
> > > > > >This vote will be open for at least 3 days till Mon Oct 3, 2022,
> > 20:00
> > > > > UTC.
> > > > > >
> > > > >
> > > >
> > >
> > https://www.timeanddate.com/countdown/vote?iso=20221003T20=0=VOTE+on+the+Apache+Ignite+Release+2.14.0+RC0=sanserif
> > > > > >
> > > > > >--
> > > > > >With best regards,
> > > > > >Taras Ledkov
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >

Re: Travis. Error accessing to the file

[Maxim Muzafarov]

 Hello,

Probably you're using a wrong dependency version.

Use the repository below for the ignite-spark integration.
https://github.com/apache/ignite-extensions

On Fri, 12 Aug 2022 at 14:35, Ivan Gagarkin  wrote:
>
> Hi, Igniters
> I created a pull request, but the build failed with the next error
>
> > [ERROR] error: scala.reflect.internal.FatalError: Error accessing 
> > /home/travis/.m2/repository/org/apache/hadoop/thirdparty/hadoop-shaded-guava/1.1.1/hadoop-shaded-guava-1.1.1.jar
> > [INFO]at 
> > scala.tools.nsc.classpath.AggregateClassPath.$anonfun$list$3(AggregateClassPath.scala:113)
> > [INFO]at scala.collection.Iterator.foreach(Iterator.scala:943)
> > [INFO]at scala.collection.Iterator.foreach$(Iterator.scala:943)
> > [INFO]at 
> > scala.collection.AbstractIterator.foreach(Iterator.scala:1431)
> > [INFO]at 
> > scala.collection.IterableLike.foreach(IterableLike.scala:74)
> > [INFO]at 
> > scala.collection.IterableLike.foreach$(IterableLike.scala:73)
> > [INFO]at 
> > scala.collection.AbstractIterable.foreach(Iterable.scala:56)
> > [INFO]at 
> > scala.tools.nsc.classpath.AggregateClassPath.list(AggregateClassPath.scala:101)
> > [INFO]at scala.tools.nsc.util.ClassPath.list(ClassPath.scala:36)
> > [INFO]at scala.tools.nsc.util.ClassPath.list$(ClassPath.scala:36)
> > [INFO]at 
> > scala.tools.nsc.classpath.AggregateClassPath.list(AggregateClassPath.scala:30)
> > [INFO]at 
> > scala.tools.nsc.symtab.SymbolLoaders$PackageLoader.doComplete(SymbolLoaders.scala:298)
> > [INFO]at 
> > scala.tools.nsc.symtab.SymbolLoaders$SymbolLoader.complete(SymbolLoaders.scala:250)
> > [INFO]at 
> > scala.reflect.internal.Symbols$Symbol.completeInfo(Symbols.scala:1542)
> > [INFO]at 
> > scala.reflect.internal.Symbols$Symbol.info(Symbols.scala:1514)
> > [INFO]at 
> > scala.reflect.internal.Mirrors$RootsBase.init(Mirrors.scala:258)
> > [INFO]at 
> > scala.tools.nsc.Global.rootMirror$lzycompute(Global.scala:75)
> > [INFO]at scala.tools.nsc.Global.rootMirror(Global.scala:73)
> > [INFO]at scala.tools.nsc.Global.rootMirror(Global.scala:45)
> > [INFO]at 
> > scala.reflect.internal.Definitions$DefinitionsClass.ObjectClass$lzycompute(Definitions.scala:294)
> > [INFO]at 
> > scala.reflect.internal.Definitions$DefinitionsClass.ObjectClass(Definitions.scala:294)
> > [INFO]at 
> > scala.reflect.internal.Definitions$DefinitionsClass.init(Definitions.scala:1504)
> > [INFO]at scala.tools.nsc.Global$Run.(Global.scala:1214)
> > [INFO]at scala.tools.nsc.Driver.doCompile(Driver.scala:46)
> > [INFO]at scala.tools.nsc.MainClass.doCompile(Main.scala:32)
> > [INFO]at scala.tools.nsc.Driver.process(Driver.scala:67)
> > [INFO]at scala.tools.nsc.Driver.main(Driver.scala:80)
> > [INFO]at scala.tools.nsc.Main.main(Main.scala)
> > [INFO]at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > [INFO]at 
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > [INFO]at 
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > [INFO]at java.lang.reflect.Method.invoke(Method.java:498)
> > [INFO]at 
> > scala_maven_executions.MainHelper.runMain(MainHelper.java:164)
> > [INFO]at 
> > scala_maven_executions.MainWithArgsInFile.main(MainWithArgsInFile.java:26)
> > [ERROR] Caused by: java.io.IOException: Error accessing 
> > /home/travis/.m2/repository/org/apache/hadoop/thirdparty/hadoop-shaded-guava/1.1.1/hadoop-shaded-guava-1.1.1.jar
> > [INFO]at 
> > scala.reflect.io.FileZipArchive.scala$reflect$io$FileZipArchive$$openZipFile(ZipArchive.scala:190)
> > [INFO]at 
> > scala.reflect.io.FileZipArchive.root$lzycompute(ZipArchive.scala:238)
> > [INFO]at scala.reflect.io.FileZipArchive.root(ZipArchive.scala:235)
> > [INFO]at 
> > scala.reflect.io.FileZipArchive.allDirs$lzycompute(ZipArchive.scala:272)
> > [INFO]at 
> > scala.reflect.io.FileZipArchive.allDirs(ZipArchive.scala:272)
> > [INFO]at 
> > scala.tools.nsc.classpath.ZipArchiveFileLookup.findDirEntry(ZipArchiveFileLookup.scala:76)
> > [INFO]at 
> > scala.tools.nsc.classpath.ZipArchiveFileLookup.list(ZipArchiveFileLookup.scala:63)
> > [INFO]at 
> > scala.tools.nsc.classpath.ZipArchiveFileLookup.list$(ZipArchiveFileLookup.scala:62)
> > [INFO]at 
> > scala.tools.nsc.classpath.ZipAndJarClassPathFactory$ZipArchiveClassPath.list(ZipAndJarFileLookupFactory.scala:58)
> > [INFO]at 
> > scala.tools.nsc.classpath.AggregateClassPath.$anonfun$list$3(AggregateClassPath.scala:105)
> > [INFO]... 33 more
> > [ERROR] Caused by: java.util.zip.ZipException: error in opening zip file
> > [INFO]at java.util.zip.ZipFile.open(Native Method)
> > [INFO]at 

[DISCUSSION] Thin client: Colocated Data Transactional Get

[Maxim Muzafarov]

Igniters,


I'd like to discuss with you some thoughts about getting colocated
data [1] from nodes via thin client (mostly the java thin client).

- We do have partition awareness enabled for non-transactional data [2].
- We do have from now on partition awareness for caches with custom
affinity functions [3].
- We do NOT have an option to execute a transactional operation on
affinity node [4], however, I think it is possilbe to send a
transactional get request over the affinity channels instead of the
default one.


The process execution on the thin client side may looks like:

open transaction (colocated get request) -> set the right client
context -> pick up the affinity node channel (instead of the default
one) -> send the request over this channel right to the destination
primaries.

The interface improvement may looks like:

IgniteClient {
public void withAffinityNode(String cacheName, Object affKey);
}

IgniteClient affClient = Ignition.startClient(new ClientConfiguration()
.setAddresses("node1_address:10800", "node2_address:10800",
"node3_address:10800"))
.withAffinityNode("person", "affKey");

try (ClientTransaction tx = affClient.transactions().txStart()
) {
ClientCache personCache = affClient.cache("person");
ClientCache paymentsCache = affClient.cache("payments");

 // personCache.get("affKey");
 // paymentsCache.get(..);
}
catch (ClientException e) {
// Ignore.
}


Additional benefits:

- ScanQuery, SqlQuery with #setLocal(true) flag right on the required
affinity channel;
- ClientCompute task right on the required affinity channel;


WDYT?


[1] 
https://ignite.apache.org/docs/latest/data-modeling/affinity-collocation#affinity-colocation
[2] 
https://ignite.apache.org/docs/latest/thin-clients/getting-started-with-thin-clients#partition-awareness
[3] https://issues.apache.org/jira/browse/IGNITE-17316
[4] 
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/client/thin/TcpClientCache.java#L994

Re: Re[2]: Deprecating LOCAL cache

[Maxim Muzafarov]

Folks,


Let's back to discussion.
We've already deprecated local caches [1], so it's time to remove them.


I've prepared the PR, please check:

- https://issues.apache.org/jira/browse/IGNITE-15759
- https://github.com/apache/ignite/pull/10157


[1] https://issues.apache.org/jira/browse/IGNITE-15756

On Wed, 15 Sept 2021 at 09:33, Zhenya Stanilovsky
 wrote:
>
>
>
> Ok, we can use node filters in such a case, i understand )
>
>
>
> >I just dream up ) If some one have cached web session layer over
> >ignite with sticky cookie [1] and cross cache transaction logic through
> >local and global caches how this schema will transform without local ?
> >
> >[1]
> >https://www.imperva.com/learn/availability/sticky-session-persistence-and-cookies/
> >
> >
> >> I am not about creation per se, but creation from a thin client side.
> >>
> >> This feature simply doesn't work as expected, broken and impossible to
> >> fix.
> >> It cannot broke any code, because it was already broken and it is
> >> impossible to use in production.
> >> But it still can embarrass newcomers and brings a lot of frustration.
> >>
> >> It is much more safe to ban a creation of LOCAL caches from thin clients.
> >>
> >> But it can survive for a while for ignite cluster nodes, client and
> >> server.
> >>
> >> вт, 14 сент. 2021 г. в 14:06, Maxim Muzafarov <  mmu...@apache.org >:
> >>
> >>> Ivan,
> >>>
> >>> I don't think we should rush with this. Banning the creation of LOCAL
> >>> caches without a warning through the code sounds not good. Will it be
> >>> better to do everything in three steps (releases)? 2.12 deprecate,
> >>> 2.13 forbid new cache creation, 2.14 remove.
> >>>
> >>> On Tue, 14 Sept 2021 at 12:09, Ivan Daschinsky <  ivanda...@gmail.com >
> >>> wrote:
> >>> >
> >>> > Few thoughts about LOCAL caches on thin client:
> >>> >
> >>> > 1. If partition awareness is disabled:
> >>> > a. Inconsistent behaviour if node to which client is connected goes
> >>> down.
> >>> > 2. If partition awareness is enabled:
> >>> > a. For Java and .NET -- same as 1a
> >>> > b. For C++ and python -- use random routing for caches that are not
> >>> > PARTITIONED, so inconsistent behaviour from the beginning.
> >>> >
> >>> > So I suppose we should ban creation of LOCAL caches from thin client
> >>> in
> >>> > 2.12 (fail attempt to create such caches in ClientRequestHandler
> >>> >
> >>> > вт, 14 сент. 2021 г. в 11:31, Ivan Daschinsky <  ivanda...@gmail.com >:
> >>> >
> >>> > > >> Unsupported operation exception.
> >>> > > Binary protocol doesn't have a concept of exception, only error
> >>> status
> >>> and
> >>> > > message, but it is just a remark
> >>> > > I suppose that response with error status and message is ok, but
> >>> may be
> >>> > > others have different opinion?
> >>> > >
> >>> > > >> Removal should happen at 2.13.
> >>> > > A few thin clients are released separately. I suppose that it is
> >>> better to
> >>> > > remove this feature from pyignite a little bit earlier.
> >>> > >
> >>> > > вт, 14 сент. 2021 г. в 11:21, Anton Vinogradov <  a...@apache.org >:
> >>> > >
> >>> > >> > 1. What is expected behaviour if an old thin client requests
> >>> creation of
> >>> > >> > LOCAL cache on the newest ignite cluster?
> >>> > >> Unsupported operation exception.
> >>> > >>
> >>> > >> > 2. Should we completely remove LOCAL caches support in thin
> >>> clients
> >>> > >> (i.e.
> >>> > >> pyignite) before 2.13 release?
> >>> > >> Removal should happen at 2.13.
> >>> > >>
> >>> > >> On Tue, Sep 14, 2021 at 10:30 AM Ivan Daschinsky <
> >>>  ivanda...@gmail.com
> >>> >
> >>> > >> wrote:
> >>> > >>
> >>> > >> > >> 2. 2.13 - complete removal LOCAL caches from codebase.
> >>> > >> > Let's discuss this step with more details.
> >>> >

Re: OSGi metadata fixes for Ignite 2.x

[Maxim Muzafarov]

Lukasz,

I've do some investigation of related activities of the
`split-package` issue mentioned above. All the issues related to
moving issued packages I've marked with the 'ignite-osgi' label [1].
Hopefully, all such packages will be moved soon.

Another question that concerns me - are there any best practices exist
to prevent such an issue in future? Should we configure the checkstyle
rules or something else?

[1] https://issues.apache.org/jira/issues/?jql=labels%20%3D%20ignite-osgi

On Mon, 11 Jul 2022 at 21:03, Łukasz Dywicki  wrote:
>
> Hello Maxim,
> My replies inline
>
> On 11.07.2022 15:57, Maxim Muzafarov wrote:
> > Hello Łukasz,
> >
> >
> >> One of major problems which are hard to solve without cooperation is 
> >> mentioned "split package" which is currently found in the sources.
> >
> > Can you clarify details of what is the issue of having such a case? I
> > my understanding it will be better to consider ignite-core +
> > ignite-indexing + ignite-calcite as a single feature. Thus having a
> > "split package" issue should not be a problem. It will be a quite
> > challenging to keep these modules thruly without package duplication
> > in future.
>
> Split package happens when same package is defined by more than one
> module. In such situation OSGi framework will stick with first provider
> of a given package (ie. ignite-core), simply ignoring subsequent code
> chunks provided by other modules (think of ignite-indexing).
> Because OSGi validate wiring at a package level, it has some impact on
> how code should be structured. Simply speaking module can not import a
> foreign package and export it with additional contents. I attempted to
> duplicate some of split package contents within ignite-indexing but it
> should be seen as a temporary workaround.
>
> > I've also briefly looked at the integration with the Apache Karaf.
> > Will it be possible to remove a module dependencies from the
> > feature-file [4]? It seems it's a bit complicated to maintain these
> > dependencies and corresponding versions each time some module changed.
> These dependencies are recommended as it will force proper build order
> of modules. Without it you may end up with a situation that feature
> validation involving ignite-core will be made before before ignite-core
> is being built locally. Relying on sequence order of  elements
> in reactor pom is often insufficient to assure that.
>
> > The issue IGNITE-17046 [1] you mentioned above was merged. I've also
> > moved the OSGi sub-modules to the Apache Ignite Extensions project
> > [2], so I hope we can proceed here. Please, note that I've removed the
> > ignite-paxloggin module due to it is completely out of date. The
> > ignite-log4j will be removed very soon [3], so we have to migrate
> > everything to the ignite-log4j2.
> Fair enough, I can take it forward from that place and try to come with
> a clear Karaf feature set also for some of ignite extensions. I noticed
> some of them were refereed.
>
> > I've also take a look at the packages you mentioned above. Here is the
> > list of packages with my comments:
> >
> > org.apache.ignite.internal.managers.systemview.walker
> > (will be moved soon from ignite-indexing to the ignite-core)
> >
> > org.apache.ignite.internal.mxbean
> > (ignite-indexing - classes deprecated and will be removed here [5])
> >
> > org.apache.ignite.internal.processors.cache.query
> > (ignite-indexing - I doubt it can be simply removed currently,
> > refactoring is required)
> >
> > org.apache.ignite.internal.processors.query.stat
> > (ignite-indexing - I doubt we can do anything here)
> >
> > org.apache.ignite.internal.visor.cache.index
> > (ignite-indexing - we can simply move everything to the ignite-core)
> >
> > org.apache.ignite.internal.visor.verify
> > (ignite-indexing - we can simply move everything to the ignite-core)
> >
> > org.apache.ignite.internal.managers.systemview
> > (will be moved soon from ignite-indexing to the ignite-core)
>
> I understand that moving code is difficult and causes a friction to
> dependent projects, so easiest path is moving dependencies up (to
> ignite-core), making it even bigger.
> We do not need a full functinality re-factoring to satisfy "singularity"
> of a package. It is sufficient to have unique name for package
> structure. For example:
> org.apache.ignite.internal.processors.cache.query in indexing could be:
> - org.apache.ignite.internal.processors.cache.indexing.query
> - org.apache.ignite.indexing.internal.processors.cache.query
> or similar.
>
> Best,
> Łukas

Re: spring-boot-*-autoconfigure extensions release

[Maxim Muzafarov]

Stephen,

I've checked the issue you mentioned. I think it's possible to prepare
a new release.

On Thu, 14 Jul 2022 at 16:08, Stephen Darlington
 wrote:
>
> Sorry, I wasn’t clear. The Spring Data change 
> (https://issues.apache.org/jira/browse/IGNITE-13029) was made after the 1.0.0 
> release. Is there a plan to make a 1.1.0 release?
>
> > On 14 Jul 2022, at 14:01, Maxim Muzafarov  wrote:
> >
> > Hello Stephen,
> >
> > Why do you think they haven't been released yet?
> >
> > https://mvnrepository.com/artifact/org.apache.ignite/ignite-spring-boot-thin-client-autoconfigure-ext/1.0.0
> > https://mvnrepository.com/artifact/org.apache.ignite/ignite-spring-boot-autoconfigure-ext/1.0.0
> >
> > On Thu, 14 Jul 2022 at 15:57, Stephen Darlington
> >  wrote:
> >>
> >> Hi,
> >>
> >> Are there any plans to release the spring-boot-*-autoconfigure extensions? 
> >> I note there’s a change that auto-configures Spring Data repos in master 
> >> but not in the current release.
> >>
> >> The reason I ask: I’m trying to get Ignite added to the Spring Initializr 
> >> (960 
> >> <https://github.com/spring-io/start.spring.io/issues/960#issuecomment-1181412216>)
> >>  and they asked about exactly that.
> >>
> >> Regards,
> >> Stephen
>

Re: spring-boot-*-autoconfigure extensions release

[Maxim Muzafarov]

Hello Stephen,

Why do you think they haven't been released yet?

https://mvnrepository.com/artifact/org.apache.ignite/ignite-spring-boot-thin-client-autoconfigure-ext/1.0.0
https://mvnrepository.com/artifact/org.apache.ignite/ignite-spring-boot-autoconfigure-ext/1.0.0

On Thu, 14 Jul 2022 at 15:57, Stephen Darlington
 wrote:
>
> Hi,
>
> Are there any plans to release the spring-boot-*-autoconfigure extensions? I 
> note there’s a change that auto-configures Spring Data repos in master but 
> not in the current release.
>
> The reason I ask: I’m trying to get Ignite added to the Spring Initializr 
> (960 
> )
>  and they asked about exactly that.
>
> Regards,
> Stephen

Re: OSGi metadata fixes for Ignite 2.x

[Maxim Muzafarov]

Hello Łukasz,


> One of major problems which are hard to solve without cooperation is 
> mentioned "split package" which is currently found in the sources.

Can you clarify details of what is the issue of having such a case? I
my understanding it will be better to consider ignite-core +
ignite-indexing + ignite-calcite as a single feature. Thus having a
"split package" issue should not be a problem. It will be a quite
challenging to keep these modules thruly without package duplication
in future.

I've also briefly looked at the integration with the Apache Karaf.
Will it be possible to remove a module dependencies from the
feature-file [4]? It seems it's a bit complicated to maintain these
dependencies and corresponding versions each time some module changed.


The issue IGNITE-17046 [1] you mentioned above was merged. I've also
moved the OSGi sub-modules to the Apache Ignite Extensions project
[2], so I hope we can proceed here. Please, note that I've removed the
ignite-paxloggin module due to it is completely out of date. The
ignite-log4j will be removed very soon [3], so we have to migrate
everything to the ignite-log4j2.

I've also take a look at the packages you mentioned above. Here is the
list of packages with my comments:

org.apache.ignite.internal.managers.systemview.walker
(will be moved soon from ignite-indexing to the ignite-core)

org.apache.ignite.internal.mxbean
(ignite-indexing - classes deprecated and will be removed here [5])

org.apache.ignite.internal.processors.cache.query
(ignite-indexing - I doubt it can be simply removed currently,
refactoring is required)

org.apache.ignite.internal.processors.query.stat
(ignite-indexing - I doubt we can do anything here)

org.apache.ignite.internal.visor.cache.index
(ignite-indexing - we can simply move everything to the ignite-core)

org.apache.ignite.internal.visor.verify
(ignite-indexing - we can simply move everything to the ignite-core)

org.apache.ignite.internal.managers.systemview
(will be moved soon from ignite-indexing to the ignite-core)



[1] https://issues.apache.org/jira/browse/IGNITE-17046
[2] https://issues.apache.org/jira/browse/IGNITE-13570
[3] https://issues.apache.org/jira/browse/IGNITE-16650
[4] 
https://github.com/apache/ignite-extensions/blob/master/modules/osgi-ext/osgi-karaf/src/main/resources/features.xml#L131
[5] https://issues.apache.org/jira/browse/IGNITE-15761

On Mon, 4 Jul 2022 at 21:42, Łukasz Dywicki  wrote:
>
> Hello Maxim,
> Thank you for your answer. I haven't expected such quick feedback. I am
> here to help you with OSGi, I believe that together we will be able to
> get Ignite free of troubles it gives.
>
> I abstained from creating new issues as there are two which already
> outline end user problem: IGNITE-17216, IGNITE-17216.
>
> I do not see a problem with moving ignite-osgi module to other
> repository as long as we avoid dependency cycles.
> Since igite-osgi functionality seem to be limited to bootstrapping
> ignite and its classloading it does not depend per say on where code
> itself is located. I suppose that osgi-karaf and osgi-paxlogging should
> follow that move to keep all osgi related things in one place.
>
> Major concern I can raise is how to keep it up so it does not sink over
> time. Integration tests I mentioned will form a safety net, but they
> need to be part of build pipeline to follow changes in main repository.
> Some of recent changes I found about cleaning out some inner-dependency
> paths (ie. indexing-h2 relation: IGNITE-17046), are very helpful  to
> solidify OSGi metadata.
> One of major problems which are hard to solve without cooperation is
> mentioned "split package" which is currently found in the sources. This
> happens when same package is defined (and exported) from two places.
> Currently both ignite-core and indexing bring contents of
> org.apache.ignite.internal and spi packages:
> - org.apache.ignite.internal.managers.systemview.walker
> - org.apache.ignite.internal.mxbean
> - org.apache.ignite.internal.processors.cache.query
> - org.apache.ignite.internal.processors.query.stat
> - org.apache.ignite.internal.visor.cache.index
> - org.apache.ignite.internal.visor.verify
> - org.apache.ignite.spi.systemview.view
> To be fair, I don't know yet what is scope of these and that's where I
> need most of your guidance. I don't think we will be able to stabilize
> osgi integration to guarantee it will work reliably if these stay.
>
> Kind regards,
> Łukasz
>
> On 4.07.2022 19:43, Maxim Muzafarov wrote:
> > Hello Łukasz,
> >
> > Nice to meet you!
> >
> > Currently there are some known issues with the Apache Ignite OSGi
> > integration. We have a lack of time and knowledg to support it, so any
> > help are very appreciated. I also have a a plan to move this
> > integra

Re: [DISCUSSION] Customers Migraton from Thick to Thin Clients

[Maxim Muzafarov]

ll work for .NET client, not sure about Python and C++.
> > >
> > > On Sun, Jul 10, 2022 at 9:33 PM Ivan Daschinsky 
> > wrote:
> > >
> > >> Guys, I simply cant understand why providing simple function Object ->
> > >> int32 in cache configuration is wrong decision, but implementing cryptic
> > >> logic with class names, feature flags and still being unable to solve
> > the
> > >> probem is ok. I don't understand how an ability to obtain a classname of
> > >> java class can help my python or C++ client map key to partition.
> > >>
> > >> Max's proposal seems to be a good variant, just change naming a little
> > bit,
> > >> maybe
> > >>
> > >> пт, 8 июл. 2022 г., 15:35 Pavel Tupitsyn :
> > >>
> > >>> Nikolay,
> > >>>
> > >>>> Add ability to sent custom affinity class name.
> > >>> Can you please elaborate? What is sent where?
> > >>>
> > >>>> If `partitionAwarenessEnabled=true` but custom affinity can’t be
> > >>> instantiated on the client - throw an exception
> > >>> Unfortunately, this is a breaking change. Currently this scenario works
> > >>> without errors - uses default socket for custom affinity caches.
> > >>>
> > >>>
> > >>> On Fri, Jul 8, 2022 at 3:23 PM Николай Ижиков 
> > >> wrote:
> > >>>
> > >>>> Hello, Pavel.
> > >>>>
> > >>>> I support your proposal to transparently create custom AffinityMapper
> > >>>> based on server node classname, in general.
> > >>>> Partition Awareness crucial point for a thin client performance so It
> > >>>> should be absolutely clear for a user - PA works correctly or not.
> > >>>>
> > >>>> So, I think, we should implement the following:
> > >>>>
> > >>>> 0. Add ability to sent custom affinity class name.
> > >>>> 1. If `partitionAwarenessEnabled=true` but custom affinity can’t be
> > >>>> instantiated on the client - throw an exception.
> > >>>>
> > >>>> WDYT?
> > >>>>
> > >>>>> 8 июля 2022 г., в 08:37, Pavel Tupitsyn 
> > >>>> написал(а):
> > >>>>>
> > >>>>> To clarify: you can use a different AffinityFunction implementation
> > >> on
> > >>>> the
> > >>>>> client side. It just has to map to the same binary typeId.
> > >>>>> Even if there is a legacy setup with AffinityKeyMapper on servers,
> > >> you
> > >>>> can
> > >>>>> craft an AffinityFunction for the client that achieves correct
> > >>> behavior.
> > >>>>> So I believe this should cover any use case.
> > >>>>>
> > >>>>> On Thu, Jul 7, 2022 at 10:36 PM Pavel Tupitsyn  > >>>
> > >>>> wrote:
> > >>>>>
> > >>>>>> AffinityKeyMapper is just a subset of AffinityFunction, isn't it?
> > >>>>>> So by supporting AffinityFunction we cover all AffinityKeyMapper use
> > >>>> cases.
> > >>>>>>
> > >>>>>>
> > >>>>>>> managing the classpath, a user should always keep in mind it
> > >>>>>> I don't consider this a problem. This is how Java works, what can we
> > >>> do?
> > >>>>>> You can also stick the class into BinaryConfiguration on the client
> > >> to
> > >>>>>> make it explicit and make sure it is loaded.
> > >>>>>>
> > >>>>>>> it still possible having user bad implementations of
> > >> AffinityFunction
> > >>>>>> that can't be easily instantiated;
> > >>>>>> It is also possible to provide a bad implementation of
> > >> ToIntFunction,
> > >>> no
> > >>>>>> difference.
> > >>>>>>
> > >>>>>>> a question - what we should do in case of class instantiating
> > >> loading
> > >>>>>> fails?
> > >>>>>> Currently we don't fail on custom affinity, right? So we should keep
> > >>>> this
> > >>>>>> behavior. 

Re: [DISCUSSION] Customers Migraton from Thick to Thin Clients

[Maxim Muzafarov]

Pavel,


Yes, you're right that AffinityKeyMapper is deprecated, this is sad to
say but it still used.

Let me describe the cases in more detail. In general, we have
customers which are using:

1. an own custom AffinityFunction;
2. the default RendezvousAffinityFunction + an own deprecated AffinityKeyMapper;
3. an own custom AffinityFunction + an own deprecated
AffinityKeyMapper (I doubt about this case);

I'd like to provide a general solution that solves all the cases
mentioned above, thus we can't discuss only AffinityFunction. It
doesn't fit the initial goals.


> Can you please clarify the "tricky" part?

Yes, from my point of view the tricky part here is:

- managing the classpath, a user should always keep in mind it;
- it still possible having user bad implementations of
AffinityFunction that can't be easily instantiated;
- a question - what we should do in case of class instantiating
loading fails? drop the client, print the warn or do nothing. These
solutions have a different impact on a production environment and user
may have different expectations on that;


I'm not saying that solution you suggested is bad, it just has some
drawbacks (like other solutions) and doesn't solves all the cases if
we're not instantiating a deprecated AffinityKeyMapper (which looks a
bit ugly for me too).


Actually, we are not limited with setting/instantiating
AffinityFunction. We can provide for a user a control on which channel
(node) a particular cache request will be executed (this thing also
have a drawback - a transactional operation cannot be executed on an
arbitrary node, it should be executed on node it's started).

On Thu, 7 Jul 2022 at 21:41, Pavel Tupitsyn  wrote:
>
> > AffinityKeyMapper (it will be required too)
> It is deprecated. We should not add any functionality on top of deprecated
> stuff.
> Let's discuss only AffinityFunction.
>
> > this approach requires of these classes to be present on a thin client
> side and it can be tricky
> Any of the approaches discussed above requires some additional logic to be
> present on the client.
> Can you please clarify the "tricky" part?
>
> All you need is to provide AffinityFunction implementation with a proper
> class name
> (or even use nameMapper/idMapper to map to a different name), it is no
> different from the ToIntFunction approach.
>
>
> On Thu, Jul 7, 2022 at 9:23 PM Maxim Muzafarov  wrote:
>
> > Folks,
> >
> > I'd like also to mention since we are talking about a customer's
> > custom affinity function and affinity mapper implementations we could
> > face with some issues during these classes instantiation. It could
> > work for the customer which I've faced on, but I cannoun be sure that
> > this approach will work for all of the cases.
> >
> > I think it is better to avoid such an issues and leave it up to a
> > user. Nevertheless, the worst scenario for the user would be having 2
> > hops on each put/get as it was before this thread.
> >
> > On Thu, 7 Jul 2022 at 21:12, Maxim Muzafarov  wrote:
> > >
> > > Folks,
> > >
> > > I'm not familiar with a thin client protocol, so, please, correct me
> > > if I'm wrong - is it possible sending classes over the network for
> > > different type of thin clients? It seems to me it will not work. I
> > > think it is possible to use class name/or type id and we are capable
> > > to instantiate both of the AffinityFunction and AffinityKeyMapper (it
> > > will be required too) classes. However, this approach requires of
> > > these classes to be present on a thin client side and it can be tricky
> > > to configure if this client is used inside a container (e.g. with
> > > spring data or something).
> > >
> > > Setting directly some kind of a known mapper looks more
> > > straightforward and error prone approach.
> > >
> > > Please, correct me if I am wrong.
> > >
> > > On Thu, 7 Jul 2022 at 21:02, Семён Данилов  wrote:
> > > >
> > > > +1 to Pavel’s approach. Giving user the ability to set affinity
> > function that is potentially different from the one that is on server
> > doesn’t look good.
> > > >
> > > > I’d even go further and try sending the affinity function class itself
> > over the network, so users won’t have to alter the classpath by adding the
> > class that is not directly used in the codebase.
> > > > On 7 Jul 2022, 21:41 +0400, Pavel Tupitsyn ,
> > wrote:
> > > > > Can we actually avoid any public API changes and do the following:
> > > > >
> > > > > When a feature flag is present and there is a custom affinity
> > function

Re: [DISCUSSION] Customers Migraton from Thick to Thin Clients

[Maxim Muzafarov]

Folks,

I'd like also to mention since we are talking about a customer's
custom affinity function and affinity mapper implementations we could
face with some issues during these classes instantiation. It could
work for the customer which I've faced on, but I cannoun be sure that
this approach will work for all of the cases.

I think it is better to avoid such an issues and leave it up to a
user. Nevertheless, the worst scenario for the user would be having 2
hops on each put/get as it was before this thread.

On Thu, 7 Jul 2022 at 21:12, Maxim Muzafarov  wrote:
>
> Folks,
>
> I'm not familiar with a thin client protocol, so, please, correct me
> if I'm wrong - is it possible sending classes over the network for
> different type of thin clients? It seems to me it will not work. I
> think it is possible to use class name/or type id and we are capable
> to instantiate both of the AffinityFunction and AffinityKeyMapper (it
> will be required too) classes. However, this approach requires of
> these classes to be present on a thin client side and it can be tricky
> to configure if this client is used inside a container (e.g. with
> spring data or something).
>
> Setting directly some kind of a known mapper looks more
> straightforward and error prone approach.
>
> Please, correct me if I am wrong.
>
> On Thu, 7 Jul 2022 at 21:02, Семён Данилов  wrote:
> >
> > +1 to Pavel’s approach. Giving user the ability to set affinity function 
> > that is potentially different from the one that is on server doesn’t look 
> > good.
> >
> > I’d even go further and try sending the affinity function class itself over 
> > the network, so users won’t have to alter the classpath by adding the class 
> > that is not directly used in the codebase.
> > On 7 Jul 2022, 21:41 +0400, Pavel Tupitsyn , wrote:
> > > Can we actually avoid any public API changes and do the following:
> > >
> > > When a feature flag is present and there is a custom affinity function on
> > > the server, send back the class name (or binary type id, if possible) of
> > > the affinity function?
> > > Then simply instantiate it on the client and call `partition(Object key)`
> > > on it?
> > >
> > > On Thu, Jul 7, 2022 at 8:32 PM Maxim Muzafarov  wrote:
> > >
> > > > Pavel,
> > > >
> > > > Here is my thoughts.
> > > >
> > > > As I mentioned before, we will need only the
> > > > AffinityFunction#partition(Object key) method for calculation on the
> > > > client side due to all the partition-to-node mappings will be
> > > > requested asynchronously from a server node how it is happening now
> > > > for cache groups with the default affinity function. Thus setting the
> > > > AffinityFunction looks on the client side redundant and it can be
> > > > transformed to a simple ToInFunction interface.
> > > >
> > > > public interface ToIntFunction {
> > > > int applyAsInt(Object key);
> > > > }
> > > >
> > > > Another point that I'd like also to mention is that the cache already
> > > > created in a cluster, so it will be better to eliminate the duplicate
> > > > affinity function configuration (setting the number of partitions). It
> > > > is fully possible to receive the number of partitions from a server
> > > > node (the same way as it currently happening). Thus instead of the
> > > > ToInFunction interface it will be better to use
> > > > ToInBiFunction.
> > > >
> > > > public interface ToIntBiFunction {
> > > > int applyAsInt(Object key, Integer parts);
> > > > }
> > > >
> > > >
> > > > I agree with you that "setPartitionAwarenessKeyMapper" may be is not
> > > > good naming here, we can rename it and move it to the public API, of
> > > > course.
> > > >
> > > > On Thu, 7 Jul 2022 at 20:06, Pavel Tupitsyn  
> > > > wrote:
> > > > >
> > > > > Maxim,
> > > > >
> > > > > I am confused. We were talking about a custom Affinity Function.
> > > > > As you noted, AffinityKeyMapper is deprecated, why do we add something
> > > > > named "setPartitionAwarenessKeyMapper"?
> > > > >
> > > > > Internal API approach is hacky.
> > > > > IMO we should either develop a proper feature with a good public API, 
> > > > > or
> > > > > not add anything at all.
> > > > >
> 

Re: [DISCUSSION] Customers Migraton from Thick to Thin Clients

[Maxim Muzafarov]

Folks,

I'm not familiar with a thin client protocol, so, please, correct me
if I'm wrong - is it possible sending classes over the network for
different type of thin clients? It seems to me it will not work. I
think it is possible to use class name/or type id and we are capable
to instantiate both of the AffinityFunction and AffinityKeyMapper (it
will be required too) classes. However, this approach requires of
these classes to be present on a thin client side and it can be tricky
to configure if this client is used inside a container (e.g. with
spring data or something).

Setting directly some kind of a known mapper looks more
straightforward and error prone approach.

Please, correct me if I am wrong.

On Thu, 7 Jul 2022 at 21:02, Семён Данилов  wrote:
>
> +1 to Pavel’s approach. Giving user the ability to set affinity function that 
> is potentially different from the one that is on server doesn’t look good.
>
> I’d even go further and try sending the affinity function class itself over 
> the network, so users won’t have to alter the classpath by adding the class 
> that is not directly used in the codebase.
> On 7 Jul 2022, 21:41 +0400, Pavel Tupitsyn , wrote:
> > Can we actually avoid any public API changes and do the following:
> >
> > When a feature flag is present and there is a custom affinity function on
> > the server, send back the class name (or binary type id, if possible) of
> > the affinity function?
> > Then simply instantiate it on the client and call `partition(Object key)`
> > on it?
> >
> > On Thu, Jul 7, 2022 at 8:32 PM Maxim Muzafarov  wrote:
> >
> > > Pavel,
> > >
> > > Here is my thoughts.
> > >
> > > As I mentioned before, we will need only the
> > > AffinityFunction#partition(Object key) method for calculation on the
> > > client side due to all the partition-to-node mappings will be
> > > requested asynchronously from a server node how it is happening now
> > > for cache groups with the default affinity function. Thus setting the
> > > AffinityFunction looks on the client side redundant and it can be
> > > transformed to a simple ToInFunction interface.
> > >
> > > public interface ToIntFunction {
> > > int applyAsInt(Object key);
> > > }
> > >
> > > Another point that I'd like also to mention is that the cache already
> > > created in a cluster, so it will be better to eliminate the duplicate
> > > affinity function configuration (setting the number of partitions). It
> > > is fully possible to receive the number of partitions from a server
> > > node (the same way as it currently happening). Thus instead of the
> > > ToInFunction interface it will be better to use
> > > ToInBiFunction.
> > >
> > > public interface ToIntBiFunction {
> > > int applyAsInt(Object key, Integer parts);
> > > }
> > >
> > >
> > > I agree with you that "setPartitionAwarenessKeyMapper" may be is not
> > > good naming here, we can rename it and move it to the public API, of
> > > course.
> > >
> > > On Thu, 7 Jul 2022 at 20:06, Pavel Tupitsyn  wrote:
> > > >
> > > > Maxim,
> > > >
> > > > I am confused. We were talking about a custom Affinity Function.
> > > > As you noted, AffinityKeyMapper is deprecated, why do we add something
> > > > named "setPartitionAwarenessKeyMapper"?
> > > >
> > > > Internal API approach is hacky.
> > > > IMO we should either develop a proper feature with a good public API, or
> > > > not add anything at all.
> > > >
> > > > On Thu, Jul 7, 2022 at 6:34 PM Maxim Muzafarov 
> > > wrote:
> > > >
> > > > > Folks,
> > > > >
> > > > >
> > > > > Thank you for your comments.
> > > > >
> > > > > First of all, I'd like to point out that if the cache is created with
> > > > > a custom affinity function or the legacy AffinityKeyMapper interface,
> > > > > the thin client should be able to provide only a `key-to-partition`
> > > > > mapping function to handle the case described above. The
> > > > > `partition-to-node` mappings the client will receive from a server
> > > > > node it connected to. This will simplify a bit the final solution.
> > > > >
> > > > > ==
> > > > >
> > > > > I've checked your suggestions and it looks like both of them have some
> &

Re: [DISCUSSION] Customers Migraton from Thick to Thin Clients

[Maxim Muzafarov]

Pavel,

Here is my thoughts.

As I mentioned before, we will need only the
AffinityFunction#partition(Object key) method for calculation on the
client side due to all the partition-to-node mappings will be
requested asynchronously from a server node how it is happening now
for cache groups with the default affinity function. Thus setting the
AffinityFunction looks on the client side redundant and it can be
transformed to a simple ToInFunction interface.

public interface ToIntFunction {
int applyAsInt(Object key);
}

Another point that I'd like also to mention is that the cache already
created in a cluster, so it will be better to eliminate the duplicate
affinity function configuration (setting the number of partitions). It
is fully possible to receive the number of partitions from a server
node (the same way as it currently happening). Thus instead of the
ToInFunction interface it will be better to use
ToInBiFunction.

public interface ToIntBiFunction {
int applyAsInt(Object key, Integer parts);
}


I agree with you that "setPartitionAwarenessKeyMapper" may be is not
good naming here, we can rename it and move it to the public API, of
course.

On Thu, 7 Jul 2022 at 20:06, Pavel Tupitsyn  wrote:
>
> Maxim,
>
> I am confused. We were talking about a custom Affinity Function.
> As you noted, AffinityKeyMapper is deprecated, why do we add something
> named "setPartitionAwarenessKeyMapper"?
>
> Internal API approach is hacky.
> IMO we should either develop a proper feature with a good public API, or
> not add anything at all.
>
> On Thu, Jul 7, 2022 at 6:34 PM Maxim Muzafarov  wrote:
>
> > Folks,
> >
> >
> > Thank you for your comments.
> >
> > First of all, I'd like to point out that if the cache is created with
> > a custom affinity function or the legacy AffinityKeyMapper interface,
> > the thin client should be able to provide only a `key-to-partition`
> > mapping function to handle the case described above. The
> > `partition-to-node` mappings the client will receive from a server
> > node it connected to. This will simplify a bit the final solution.
> >
> > ==
> >
> > I've checked your suggestions and it looks like both of them have some
> > sufficient drawbacks:
> >
> > 1. Using SystemProperty looks really hacky and we are explicitly
> > complicate a thin client configuration for an end user.
> >
> > 2. Extending the ClientCacheConfiguration is a very good and
> > straightforward idea, however it doesn't fit the case described above.
> > Caches previously created with custom affinity functions/key mappers
> > already present in the cluster, so in this case we are forcing a user
> > to store an additional ClientCacheConfiguration. This is not good. The
> > cache.getOrCreate(cfg) method will also be used and fire in turn
> > CACHE_GET_OR_CREATE_WITH_CONFIGURATION request which is not necessary
> > here. For this case using cache.name(str) is only enough.
> >
> > ==
> >
> > I propose the following two solutions that looks very promising:
> >
> > 3. Extending cache create methdos with a ClientCacheContext in the
> > IgniteClient interface. This context will contain all additional cache
> > attributes like custom cache affinity mappers that map cache keys to
> > partitions if a custom affinity was used on the server side (note that
> > all partition-to-node mappings will be received by thin client from a
> > server node).
> >
> > interface IgniteClientEx extends IgniteClient {
> > ClientCache name(String name, ClientCacheContext cctx);
> > ClientCache getOrCreateCache(String name, ClientCacheContext
> > cctx);
> > ClientCache getOrCreateCache(ClientCacheConfiguration cfg,
> > ClientCacheContext cctx);
> > }
> >
> > class ClientCacheContext {
> > setPartitionAwarenessKeyMapper(ToIntBiFunction
> > mapper);
> > }
> >
> > 4. Use the same approach as the IgniteCache interface does for the
> > same things - adding withPartitionAwarenessKeyMapper() to the
> > interface. This method will allow to configure the thin client
> > execution behaviour for the partition awareness feature by setting a
> > custom cache key mapper.
> >
> > ==
> >
> > I've used the 4-th solution due to it brings much less source code to
> > the Apache Ignite codebase and looks a bit simpler to configure for a
> > user. I've also move the withPartitionAwarenessKeyMapper() method to
> > an internal API interface which still solves a user issue with the
> > partition awareness, but also specifies that the custom mapping
>

Re: [DISCUSSION] Customers Migraton from Thick to Thin Clients

[Maxim Muzafarov]

Folks,


Thank you for your comments.

First of all, I'd like to point out that if the cache is created with
a custom affinity function or the legacy AffinityKeyMapper interface,
the thin client should be able to provide only a `key-to-partition`
mapping function to handle the case described above. The
`partition-to-node` mappings the client will receive from a server
node it connected to. This will simplify a bit the final solution.

==

I've checked your suggestions and it looks like both of them have some
sufficient drawbacks:

1. Using SystemProperty looks really hacky and we are explicitly
complicate a thin client configuration for an end user.

2. Extending the ClientCacheConfiguration is a very good and
straightforward idea, however it doesn't fit the case described above.
Caches previously created with custom affinity functions/key mappers
already present in the cluster, so in this case we are forcing a user
to store an additional ClientCacheConfiguration. This is not good. The
cache.getOrCreate(cfg) method will also be used and fire in turn
CACHE_GET_OR_CREATE_WITH_CONFIGURATION request which is not necessary
here. For this case using cache.name(str) is only enough.

==

I propose the following two solutions that looks very promising:

3. Extending cache create methdos with a ClientCacheContext in the
IgniteClient interface. This context will contain all additional cache
attributes like custom cache affinity mappers that map cache keys to
partitions if a custom affinity was used on the server side (note that
all partition-to-node mappings will be received by thin client from a
server node).

interface IgniteClientEx extends IgniteClient {
ClientCache name(String name, ClientCacheContext cctx);
ClientCache getOrCreateCache(String name, ClientCacheContext cctx);
ClientCache getOrCreateCache(ClientCacheConfiguration cfg,
ClientCacheContext cctx);
}

class ClientCacheContext {
setPartitionAwarenessKeyMapper(ToIntBiFunction mapper);
}

4. Use the same approach as the IgniteCache interface does for the
same things - adding withPartitionAwarenessKeyMapper() to the
interface. This method will allow to configure the thin client
execution behaviour for the partition awareness feature by setting a
custom cache key mapper.

==

I've used the 4-th solution due to it brings much less source code to
the Apache Ignite codebase and looks a bit simpler to configure for a
user. I've also move the withPartitionAwarenessKeyMapper() method to
an internal API interface which still solves a user issue with the
partition awareness, but also specifies that the custom mapping
function and deprecated AffinityKeyMapper should not be used, in
general.

Please, take a look at my patch:

https://issues.apache.org/jira/browse/IGNITE-17316
https://github.com/apache/ignite/pull/10140/files


On Fri, 1 Jul 2022 at 14:41, Pavel Tupitsyn  wrote:
>
> I have no objections to extending the Thin Client configuration with a
> pluggable Affinity Function.
> Let's make it a normal Java setter though, system properties are hacky.
> Especially when only some of the caches use custom affinity, as Maxim
> mentioned.
>
> On Wed, Jun 29, 2022 at 7:20 PM Николай Ижиков  wrote:
>
> > +1 to have ability to specify custom affinity for PA on thin client.
> >
> > It seems to me custom affinity is a rare use-case of Ignite API.
> > Propose to have SystemProperty that can specify affinity implementation
> > for a thin client.
> >
> >
> > > 29 июня 2022 г., в 18:53, Maxim Muzafarov 
> > написал(а):
> > >
> > > Igniters,
> > >
> > >
> > > I've faced with a customer's cluster which has more than 150 nodes and
> > > most for them are the thick-client nodes. Due to each thick-client is
> > > a full-fledged cluster topology participant it affects the cluster
> > > discovery machinery during the system operation and adding an
> > > additional overhead for using/deploying a new nodes in Kubernetes
> > > environment. However, the main thing from my point of view it prevents
> > > updating the client side and server side components independently
> > > (Apache Ignite doesn't support rolling upgrade).
> > >
> > > Accordingly to the assumptions above using thin clients become a
> > > necessary. This looks even more attractive, since the thin client has
> > > a fairly rich API over the past few releases.
> > >
> > >
> > > The MAIN ISSUE here that blocks thin client usage is that for some of
> > > cache groups a custom affinity function (and an AffinityKeyMapper) was
> > > used which prevents enabling the Partition Awareness thin client
> > > feature. Thus each cache request will have two hops.
> > >
> > &g

Re: OSGi metadata fixes for Ignite 2.x

[Maxim Muzafarov]

Hello Łukasz,

Nice to meet you!

Currently there are some known issues with the Apache Ignite OSGi
integration. We have a lack of time and knowledg to support it, so any
help are very appreciated. I also have a a plan to move this
integration to the Apache Ignite Extensions project [1] and release it
when all the issues are resolved. Here is an umbrella ticket for it
[2].

What do you think if I move the OSGi to the Apache Ignite Extensions
first and after it we will resolve the issue you mentioned above? I
can help with a review and try to do the best I can here.
Anyway if this plan wouldn't work for you, please, feel free to create
an issue here [3] with your PR.


[1] https://github.com/apache/ignite-extensions
[2] https://issues.apache.org/jira/browse/IGNITE-17019
[3] https://issues.apache.org/jira/projects/IGNITE/

On Mon, 4 Jul 2022 at 20:26, Łukasz Dywicki  wrote:
>
>
> Hello everyone,
> First of all thank you for awesome project and its maintenance. My name
> is Łukasz and I am committer of Apache Karaf and Apache PLC4X projects
> hence you most likely don't know me as I am coming from other part of
> ASF ecosystem.
>
> I was asked about looking at Apache Ignite OSGi metadata as project we
> are trying to use Ignite with is bound to the OSGi runtime. After a bit
> of look I found that metadata generation is partial and overall
> infrastructure in this area haven't received any polishing since a while.
> Since there are "split packages" and few additional troubles I wanted to
> check with you if there is a will to move that part ahead. Is there a
> will or plan to retain the metadata or rather throw it away?
>
> Last week I made a draft PR with changes which allowed me to run ignite
> inside Apache Karaf (4.3.x): https://github.com/apache/ignite/pull/10133
> There are several maven pom updates and, so far, one code relocation in
> kubernetes module. I based all changes on exiting properties:
> osgi.import.package, osgi.export.package, osgi.private.package
> I think there are few more places where "split package" is found,
> however I did not look very carefully at these yet.
>
> Looking forward to hear out your guidance in how you would like to get
> these changes, if at all. If you would be up to move that part forward I
> can sacrifice more time in making metadata generation and validation
> more rebust through ie. basic OSGi integration tests. PR I linked above
> automatically validates import and export constraints for Karaf feautes.
>
> Kind regards,
> Łukasz

[DISCUSSION] Customers Migraton from Thick to Thin Clients

[Maxim Muzafarov]

Igniters,


I've faced with a customer's cluster which has more than 150 nodes and
most for them are the thick-client nodes. Due to each thick-client is
a full-fledged cluster topology participant it affects the cluster
discovery machinery during the system operation and adding an
additional overhead for using/deploying a new nodes in Kubernetes
environment. However, the main thing from my point of view it prevents
updating the client side and server side components independently
(Apache Ignite doesn't support rolling upgrade).

Accordingly to the assumptions above using thin clients become a
necessary. This looks even more attractive, since the thin client has
a fairly rich API over the past few releases.


The MAIN ISSUE here that blocks thin client usage is that for some of
cache groups a custom affinity function (and an AffinityKeyMapper) was
used which prevents enabling the Partition Awareness thin client
feature. Thus each cache request will have two hops.

Of course, we can force users to migrate to a new API, but this
becomes more difficult when Apache Ignite is part of a much larger
architectural solution and thus it is doent' looks so friendly.

The MAIN QUESTION here - does anyone know our users who have
encountered with the same issue? I want to solve such a problem once
and make all such users happy by implementing the general approach.


= Possible solutions =


1. Making an affinity function pluggable (mapping calculations) on the
thin clients side. Currently the RendezvousAffinityFunction [1] is
only supported
for the partition awareness. A user's affinity function seems to be
the stateless function due to there is no machinery to transfer states
to the thin client.

Pros - a general solution for all such cases;
Cons - unnecessary complexity, extending public API;


2. Creating an Ignite extension which will extend the thin client API
thus a user will have a full control over a destination node to which
requests being sent.

Pros - isolated solution, simple implementation;
Cons - hard to support spring-boot-thin-client etc. and other
extensions based on the thin client API;


Folks, please share your thoughts.


[1] 
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/platform/client/cache/ClientCachePartitionsRequest.java#L206

Re: The 'dev-tools' project directory usages

[Maxim Muzafarov]

Folks,

I've merged the issue
https://issues.apache.org/jira/browse/IGNITE-17180

On Thu, 16 Jun 2022 at 18:12, Nikita Amelchev  wrote:
>
> +1 to remove.
>
> чт, 16 июн. 2022 г. в 07:46, Maxim Muzafarov :
> >
> > Folks,
> >
> > I've prepared the patch. Please, take a look.
> >
> > https://issues.apache.org/jira/browse/IGNITE-17180
> > https://github.com/apache/ignite/pull/10096/files
> >
> > On Fri, 10 Jun 2022 at 19:21, Maxim Muzafarov  wrote:
> > >
> > > Folks,
> > >
> > > I've found the 'dev-tools' [1] directory in the projects root,
> > > however, I'm not sure the reals usages of these scripts.
> > >
> > > Can anyone clarify the purpose of existing these scripts or can we
> > > remove them instead?
> > >
> > > The facts about this directory:
> > > - it hasn't been changed since 2015;
> > > - the issue [2] which added these files doesn't seems to be actual;
> > >
> > > [1] https://github.com/apache/ignite/tree/master/dev-tools
> > > [2] https://issues.apache.org/jira/browse/IGNITE-620
>
>
>
> --
> Best wishes,
> Amelchev Nikita

Re: .NET Build and Versioning Improvements

[Maxim Muzafarov]

Folks,

Thans everyone for the review.
I've merged the issue.

https://issues.apache.org/jira/browse/IGNITE-17141

On Tue, 14 Jun 2022 at 11:07, Pavel Tupitsyn  wrote:
>
> Maxim,
>
> Agree with the suffix digit logic change.
> Please see my comments on GitHub and in JIRA.
>
> On Mon, Jun 13, 2022 at 4:16 PM Maxim Muzafarov  wrote:
>
> > Pavel,
> >
> >
> > I've found some minor issue with the last digits in thin client
> > version - 2.14.0.62943. The last digits is the number of hours passed
> > since 01-01-2015 [1]. Due to the last number can't be greater than
> > 65534 (UInt16.MaxValue - 1 = 65534) there are only about 100 days left
> > to overceed the limit. It seems we need to change it soon.
> >
> > I've prepared the PR [2] with the following major chagnes:
> > - the maven command builds the .NET sources (.NET Core 3.1 and
> > Powershell required to be installed);
> > - the date format for the 'revision' is - yywwu [3] ('yy' - year, 'ww'
> > - week in a year, 'u' - the day number in a week);
> >
> > From my point of view, the changes [2] looks a bit friendly for the
> > version identification and more closely to the maven-style rather than
> > having javascript scripts execution. Please, take a look.
> >
> >
> > [1] https://github.com/apache/ignite/blob/master/pom.xml#L568
> > [2] https://github.com/apache/ignite/pull/10087/files
> > [3]
> > https://github.com/apache/ignite/pull/10087/files#diff-b5a06276719e759fe07dfe6f75d781be5f83d2215179d82bdb195ad035348214R660
> >
> >
> >
> > On Wed, 8 Jun 2022 at 20:06, Maxim Muzafarov  wrote:
> > >
> > > Folks,
> > >
> > > Make sense.
> > > Another tricky question is - can we have the following version
> > > committed in the source files 2.14.0.0, but when the 'release' profile
> > > get activated (or probably the build happened) revision number will
> > > changed to 2.14.0.62943? This will be the final release version ready
> > > for deploy (with the last digits changed each time build happened).
> > >
> > > On Wed, 8 Jun 2022 at 16:54, Pavel Tupitsyn 
> > wrote:
> > > >
> > > > > As for the last number in .NET version, AFAIK it is used as the
> > unique
> > > > > build id and is required for nightly builds as nuget doesn't have
> > > > > functionality a-la maven's 'snapshots'
> > > >
> > > > NuGet supports string suffixes like 2.15.0-nightly1. However,
> > > > AssemblyVersionAttribute does not.
> > > > In some cases it is important to avoid having different NuGet packages
> > with
> > > > assemblies that have the AssemblyVersion inside (dll hell type
> > problems,
> > > > especially with peer assembly loading).
> > > >
> > > > So I suggest keeping the last number for AssemblyVersion
> > > > and AssemblyFileVersion in SharedAssemblyInfo.
> > > > This does not affect the NuGet package version.
> > > >
> > > > Otherwise, I don't have any objections to adding a new Maven step that
> > > > builds dotnet, as long as we keep using build.ps1 script.
> > > >
> > > > Thanks,
> > > > Pavel
> > > >
> > > > On Wed, Jun 8, 2022 at 4:31 PM Ivan Daschinsky 
> > wrote:
> > > >
> > > > > As for the last number in .NET version, AFAIK it is used as the
> > unique
> > > > > build id and is required for nightly builds as nuget doesn't have
> > > > > functionality a-la maven's 'snapshots'
> > > > >
> > > > > ср, 8 июн. 2022 г. в 16:07, Ivan Daschinsky :
> > > > >
> > > > > > Since nuget packages have been built on the same linux agent as
> > the main
> > > > > > release, it sounds logical to me that this step can be done within
> > the
> > > > > > maven lifecycle.
> > > > > > I am for it, +1
> > > > > >
> > > > > > ср, 8 июн. 2022 г. в 15:13, Maxim Muzafarov :
> > > > > >
> > > > > >> Hello Igniters,
> > > > > >>
> > > > > >>
> > > > > >> I'd like to simplify the release build for the Apache Ignite.
> > > > > >>
> > > > > >> My suggestion here are:
> > > > > >> 1. Mavenize the building procedure of the 'platform/donet' thin
> > client
> > > > > >> (use maven with Ant task)
&

Re: The 'dev-tools' project directory usages

[Maxim Muzafarov]

Folks,

I've prepared the patch. Please, take a look.

https://issues.apache.org/jira/browse/IGNITE-17180
https://github.com/apache/ignite/pull/10096/files

On Fri, 10 Jun 2022 at 19:21, Maxim Muzafarov  wrote:
>
> Folks,
>
> I've found the 'dev-tools' [1] directory in the projects root,
> however, I'm not sure the reals usages of these scripts.
>
> Can anyone clarify the purpose of existing these scripts or can we
> remove them instead?
>
> The facts about this directory:
> - it hasn't been changed since 2015;
> - the issue [2] which added these files doesn't seems to be actual;
>
> [1] https://github.com/apache/ignite/tree/master/dev-tools
> [2] https://issues.apache.org/jira/browse/IGNITE-620

Re: .NET Build and Versioning Improvements

[Maxim Muzafarov]

Pavel,


I've found some minor issue with the last digits in thin client
version - 2.14.0.62943. The last digits is the number of hours passed
since 01-01-2015 [1]. Due to the last number can't be greater than
65534 (UInt16.MaxValue - 1 = 65534) there are only about 100 days left
to overceed the limit. It seems we need to change it soon.

I've prepared the PR [2] with the following major chagnes:
- the maven command builds the .NET sources (.NET Core 3.1 and
Powershell required to be installed);
- the date format for the 'revision' is - yywwu [3] ('yy' - year, 'ww'
- week in a year, 'u' - the day number in a week);

>From my point of view, the changes [2] looks a bit friendly for the
version identification and more closely to the maven-style rather than
having javascript scripts execution. Please, take a look.


[1] https://github.com/apache/ignite/blob/master/pom.xml#L568
[2] https://github.com/apache/ignite/pull/10087/files
[3] 
https://github.com/apache/ignite/pull/10087/files#diff-b5a06276719e759fe07dfe6f75d781be5f83d2215179d82bdb195ad035348214R660



On Wed, 8 Jun 2022 at 20:06, Maxim Muzafarov  wrote:
>
> Folks,
>
> Make sense.
> Another tricky question is - can we have the following version
> committed in the source files 2.14.0.0, but when the 'release' profile
> get activated (or probably the build happened) revision number will
> changed to 2.14.0.62943? This will be the final release version ready
> for deploy (with the last digits changed each time build happened).
>
> On Wed, 8 Jun 2022 at 16:54, Pavel Tupitsyn  wrote:
> >
> > > As for the last number in .NET version, AFAIK it is used as the unique
> > > build id and is required for nightly builds as nuget doesn't have
> > > functionality a-la maven's 'snapshots'
> >
> > NuGet supports string suffixes like 2.15.0-nightly1. However,
> > AssemblyVersionAttribute does not.
> > In some cases it is important to avoid having different NuGet packages with
> > assemblies that have the AssemblyVersion inside (dll hell type problems,
> > especially with peer assembly loading).
> >
> > So I suggest keeping the last number for AssemblyVersion
> > and AssemblyFileVersion in SharedAssemblyInfo.
> > This does not affect the NuGet package version.
> >
> > Otherwise, I don't have any objections to adding a new Maven step that
> > builds dotnet, as long as we keep using build.ps1 script.
> >
> > Thanks,
> > Pavel
> >
> > On Wed, Jun 8, 2022 at 4:31 PM Ivan Daschinsky  wrote:
> >
> > > As for the last number in .NET version, AFAIK it is used as the unique
> > > build id and is required for nightly builds as nuget doesn't have
> > > functionality a-la maven's 'snapshots'
> > >
> > > ср, 8 июн. 2022 г. в 16:07, Ivan Daschinsky :
> > >
> > > > Since nuget packages have been built on the same linux agent as the main
> > > > release, it sounds logical to me that this step can be done within the
> > > > maven lifecycle.
> > > > I am for it, +1
> > > >
> > > > ср, 8 июн. 2022 г. в 15:13, Maxim Muzafarov :
> > > >
> > > >> Hello Igniters,
> > > >>
> > > >>
> > > >> I'd like to simplify the release build for the Apache Ignite.
> > > >>
> > > >> My suggestion here are:
> > > >> 1. Mavenize the building procedure of the 'platform/donet' thin client
> > > >> (use maven with Ant task)
> > > >> 2. Change it's versions to fit the Ignite style.
> > > >>
> > > >>
> > > >> = 1. Build =
> > > >>
> > > >> Add a pom.xml sub-project with a corresponding maven-ant-plugin with a
> > > >> Ant task to build the .NET project when the Apache Ignite project
> > > >> build. We can use here a profile like the numa-allocator does if
> > > >> building the .NET is note required.
> > > >>
> > > >> Such a technique will also allow a variables substitution like the
> > > >> maven-resource-plugin works (e.g. version substitution).
> > > >>
> > > >> Here is an example of how it can be achieved:
> > > >>
> > > >>
> > > https://github.com/apache/ignite/pull/9497/files#diff-77baf2378aa83911a8c3091814db3ff60b7bf328c4ab4850f707717ed96f3d92R107
> > > >>
> > > >>
> > > >> = 2. Versioning =
> > > >>
> > > >> Currently, the version of .NET thin client (SharedAssemblyInfo.cs [1])
> > > >> have the following format:
> > > >>

The 'dev-tools' project directory usages

[Maxim Muzafarov]

Folks,

I've found the 'dev-tools' [1] directory in the projects root,
however, I'm not sure the reals usages of these scripts.

Can anyone clarify the purpose of existing these scripts or can we
remove them instead?

The facts about this directory:
- it hasn't been changed since 2015;
- the issue [2] which added these files doesn't seems to be actual;

[1] https://github.com/apache/ignite/tree/master/dev-tools
[2] https://issues.apache.org/jira/browse/IGNITE-620

Re: .NET Build and Versioning Improvements

[Maxim Muzafarov]

Folks,

Make sense.
Another tricky question is - can we have the following version
committed in the source files 2.14.0.0, but when the 'release' profile
get activated (or probably the build happened) revision number will
changed to 2.14.0.62943? This will be the final release version ready
for deploy (with the last digits changed each time build happened).

On Wed, 8 Jun 2022 at 16:54, Pavel Tupitsyn  wrote:
>
> > As for the last number in .NET version, AFAIK it is used as the unique
> > build id and is required for nightly builds as nuget doesn't have
> > functionality a-la maven's 'snapshots'
>
> NuGet supports string suffixes like 2.15.0-nightly1. However,
> AssemblyVersionAttribute does not.
> In some cases it is important to avoid having different NuGet packages with
> assemblies that have the AssemblyVersion inside (dll hell type problems,
> especially with peer assembly loading).
>
> So I suggest keeping the last number for AssemblyVersion
> and AssemblyFileVersion in SharedAssemblyInfo.
> This does not affect the NuGet package version.
>
> Otherwise, I don't have any objections to adding a new Maven step that
> builds dotnet, as long as we keep using build.ps1 script.
>
> Thanks,
> Pavel
>
> On Wed, Jun 8, 2022 at 4:31 PM Ivan Daschinsky  wrote:
>
> > As for the last number in .NET version, AFAIK it is used as the unique
> > build id and is required for nightly builds as nuget doesn't have
> > functionality a-la maven's 'snapshots'
> >
> > ср, 8 июн. 2022 г. в 16:07, Ivan Daschinsky :
> >
> > > Since nuget packages have been built on the same linux agent as the main
> > > release, it sounds logical to me that this step can be done within the
> > > maven lifecycle.
> > > I am for it, +1
> > >
> > > ср, 8 июн. 2022 г. в 15:13, Maxim Muzafarov :
> > >
> > >> Hello Igniters,
> > >>
> > >>
> > >> I'd like to simplify the release build for the Apache Ignite.
> > >>
> > >> My suggestion here are:
> > >> 1. Mavenize the building procedure of the 'platform/donet' thin client
> > >> (use maven with Ant task)
> > >> 2. Change it's versions to fit the Ignite style.
> > >>
> > >>
> > >> = 1. Build =
> > >>
> > >> Add a pom.xml sub-project with a corresponding maven-ant-plugin with a
> > >> Ant task to build the .NET project when the Apache Ignite project
> > >> build. We can use here a profile like the numa-allocator does if
> > >> building the .NET is note required.
> > >>
> > >> Such a technique will also allow a variables substitution like the
> > >> maven-resource-plugin works (e.g. version substitution).
> > >>
> > >> Here is an example of how it can be achieved:
> > >>
> > >>
> > https://github.com/apache/ignite/pull/9497/files#diff-77baf2378aa83911a8c3091814db3ff60b7bf328c4ab4850f707717ed96f3d92R107
> > >>
> > >>
> > >> = 2. Versioning =
> > >>
> > >> Currently, the version of .NET thin client (SharedAssemblyInfo.cs [1])
> > >> have the following format:
> > >> 2.14.0.62943 . The format of .NET versions Major.Minor.Patch.Revision
> > >> (described here [2]).
> > >>
> > >> Since the Apache Ignite doesn't have a dedicated releases for the .NET
> > >> thin client I think the last 'Revision' digits can be always set to
> > >> zero. So the result version can be:
> > >> 2.14.0.0
> > >>
> > >> This will allow having the variable substitution also for the version
> > >> number and omitt the update-version profile usage for the .NET client.
> > >>
> > >>
> > >> = Advantages =
> > >>
> > >> - Reduce the code complexity for changing a project version (we don't
> > >> need the update-versions maven profile);
> > >> - Build the whole project on the local environment and prepare nuget
> > >> for the release with a single command;
> > >>
> > >>
> > >> [1]
> > >>
> > https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/SharedAssemblyInfo.cs
> > >> [2]
> > >>
> > https://docs.microsoft.com/en-us/nuget/concepts/package-versioning#where-nugetversion-diverges-from-semantic-versioning
> > >>
> > >
> > >
> > > --
> > > Sincerely yours, Ivan Daschinskiy
> > >
> >
> >
> > --
> > Sincerely yours, Ivan Daschinskiy
> >

.NET Build and Versioning Improvements

[Maxim Muzafarov]

Hello Igniters,


I'd like to simplify the release build for the Apache Ignite.

My suggestion here are:
1. Mavenize the building procedure of the 'platform/donet' thin client
(use maven with Ant task)
2. Change it's versions to fit the Ignite style.


= 1. Build =

Add a pom.xml sub-project with a corresponding maven-ant-plugin with a
Ant task to build the .NET project when the Apache Ignite project
build. We can use here a profile like the numa-allocator does if
building the .NET is note required.

Such a technique will also allow a variables substitution like the
maven-resource-plugin works (e.g. version substitution).

Here is an example of how it can be achieved:
https://github.com/apache/ignite/pull/9497/files#diff-77baf2378aa83911a8c3091814db3ff60b7bf328c4ab4850f707717ed96f3d92R107


= 2. Versioning =

Currently, the version of .NET thin client (SharedAssemblyInfo.cs [1])
have the following format:
2.14.0.62943 . The format of .NET versions Major.Minor.Patch.Revision
(described here [2]).

Since the Apache Ignite doesn't have a dedicated releases for the .NET
thin client I think the last 'Revision' digits can be always set to
zero. So the result version can be:
2.14.0.0

This will allow having the variable substitution also for the version
number and omitt the update-version profile usage for the .NET client.


= Advantages =

- Reduce the code complexity for changing a project version (we don't
need the update-versions maven profile);
- Build the whole project on the local environment and prepare nuget
for the release with a single command;


[1] 
https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/SharedAssemblyInfo.cs
[2] 
https://docs.microsoft.com/en-us/nuget/concepts/package-versioning#where-nugetversion-diverges-from-semantic-versioning

Re: [DISCUSSION] Move the ignite-yarn, ignite-geospatial, ignite-schedule to the Ignite Extensions

[Maxim Muzafarov]

Folks,

Let's extend a bit the list of modules for moving to the Ignite Extensions.

The list:

- ignite-yarn
- ignite-geospatial
- ignite-mesos
- ignite-cloud
- ignite-osgi*
- ignite-schedule (deletion proposed)

On Thu, 19 May 2022 at 09:20, Maxim Muzafarov  wrote:
>
> Ilya,
>
> Should we start a formal vote about the ignite-schedule deletion?
>
> On Mon, 16 May 2022 at 14:28, Ilya Kasnacheev  
> wrote:
> >
> > Hello!
> >
> > In my opinion, the ignite-schedule module needs to be dropped - it has bad
> > API, outdated GPL dependency and in general is out of focus of Ignite.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пт, 13 мая 2022 г. в 17:51, Maxim Muzafarov :
> >
> > > Folks,
> > >
> > > I've found that the following modules are rarely used and haven't been
> > > change for a few years, but  they are released each time Ignite being
> > > released. It seems we can safely move all of them to the Extensions
> > > project.
> > >
> > > The list:
> > > - ignite-yarn
> > > - ignite-geospatial
> > > - ignite-schedule
> > >
> > > WDYT?
> > >

Re: [DISCUSSION] Move the ignite-yarn, ignite-geospatial, ignite-schedule to the Ignite Extensions

[Maxim Muzafarov]

Ilya,

Should we start a formal vote about the ignite-schedule deletion?

On Mon, 16 May 2022 at 14:28, Ilya Kasnacheev  wrote:
>
> Hello!
>
> In my opinion, the ignite-schedule module needs to be dropped - it has bad
> API, outdated GPL dependency and in general is out of focus of Ignite.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пт, 13 мая 2022 г. в 17:51, Maxim Muzafarov :
>
> > Folks,
> >
> > I've found that the following modules are rarely used and haven't been
> > change for a few years, but  they are released each time Ignite being
> > released. It seems we can safely move all of them to the Extensions
> > project.
> >
> > The list:
> > - ignite-yarn
> > - ignite-geospatial
> > - ignite-schedule
> >
> > WDYT?
> >

[ANNOUNCE] Apache Ignite Extensions Released

[Maxim Muzafarov]

The Apache Ignite Community is pleased to announce the release of
the following Apache Ignite Extensions:
- Ignite AWS Extension 1.0.0
- Ignite Azure Extension 1.0.0
- Ignite GCE Extension 1.0.0
- Ignite Spring Data Extension 2.0.0
- Ignite Spring Session Extension 1.0.0
- Ignite Zookeeper Ip Finder Extension 1.0.0

Apache Ignite® is a Distributed Database For High-Performance
Computing With In-Memory Speed.
https://ignite.apache.org

Download the latest Ignite Extensions version from here:
https://ignite.apache.org/download.cgi

Please let us know if you encounter any problems:
https://ignite.apache.org/community/resources.html#ask


Regards,
Maxim Muzafarov on behalf of the Apache Ignite community.

Re: [RESULT] [VOTE] Release Extensions Ignite Spring Data 2.2.0 RC1, Ignite Spring Session 1.0.0 RC1, Ignite Zookeeper IP Finder 1.0.0 RC1

[Maxim Muzafarov]

Folks,

I'm sorry for the mistake with the Spring Data Extension version in
the thread title (copy-pasted from the wrong thread).

Of course, the correct version which is being released - Ignite Spring
Data Extension 2.0.0. See:
https://dist.apache.org/repos/dist/release/ignite/ignite-extensions/ignite-spring-data-ext/2.0.0/


On Tue, 17 May 2022 at 15:44, Maxim Muzafarov  wrote:
>
> Hello, Igniters!
>
> Th Ignite Spring Data 2.2.0 RC1, Ignite Spring Session 1.0.0 RC1,
> Ignite Zookeeper IP Finder 1.0.0 RC1 extensions have been accepted.
>
> 3 - "+1" votes received.
>
> Here are the +1 votes received:
>
>  - Anton Vinogradov (binding)
>  - Alexey Plehanov (binding)
>  - Nikolay Izhikov (binding)
>
> Here is the link to the voting thread -
> https://lists.apache.org/thread/njqls47r3jn920546q63xknyr2y5yd5l
>
> Thank you!

[RESULT] [VOTE] Release Extensions Ignite Spring Data 2.2.0 RC1, Ignite Spring Session 1.0.0 RC1, Ignite Zookeeper IP Finder 1.0.0 RC1

[Maxim Muzafarov]

Hello, Igniters!

Th Ignite Spring Data 2.2.0 RC1, Ignite Spring Session 1.0.0 RC1,
Ignite Zookeeper IP Finder 1.0.0 RC1 extensions have been accepted.

3 - "+1" votes received.

Here are the +1 votes received:

 - Anton Vinogradov (binding)
 - Alexey Plehanov (binding)
 - Nikolay Izhikov (binding)

Here is the link to the voting thread -
https://lists.apache.org/thread/njqls47r3jn920546q63xknyr2y5yd5l

Thank you!

[DISCUSSION] Move the ignite-yarn, ignite-geospatial, ignite-schedule to the Ignite Extensions

[Maxim Muzafarov]

Folks,

I've found that the following modules are rarely used and haven't been
change for a few years, but  they are released each time Ignite being
released. It seems we can safely move all of them to the Extensions
project.

The list:
- ignite-yarn
- ignite-geospatial
- ignite-schedule

WDYT?

Re: [DISCUSSION] IEP-88: CLI Tool

[Maxim Muzafarov]

Hello Aleksanrd,


The description looks good. A few questions below:

- Can the CLI also be run in non-interactive mode to support scripts
execution (like the WildFly it does [1])? Will it be possible though
the REST it used?
- What is the benefits and drawbacks of using REST for this tool? Are
there any alternative for that?
- Would we have command autocomplition out of the box? It doesn't
mentioned, but seems to be a very user friendly ability.

Can you provide a briefly comparison for such a CLI tools for other
databases and/or systems, application servers? It seems the developing
CLI tool is a common task, so I think at least we should mention about
the common development approach in modern systems for such tools. For
instance, I'm very excited with the wildfly-cli tool usage, however,
may be it has some drawbacks too.

[1] https://kb.novaordis.com/index.php/WildFly_CLI_Scripting

On Thu, 12 May 2022 at 23:43, Aleksandr Pakhomov  wrote:
>
> Hello, Igniters.
>
> I’d like to start a discussion about Ignite 3 Command Line Tool [1]. The main 
> value is to develop a user-friendly command-line tool with advanced 
> completions and SQL REPL mode.
>
> The set of commands and parameters can be discussed. Questions and comments 
> are welcomed.
>
> [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-88%3A+CLI+Tool 
> 

Re: [DISCUSSION] Move ignite-hibernate modules to the Ignite Extensions

[Maxim Muzafarov]

Folks,

I've moved the hibernate modules to the Ignite Extension project,
however, we can't deploy them to the Maven Central since they have the
LGPL dependencies. This is also mentioned in the documentation [1].
Users must build them manually from the sources to use.

Another problem I've faced with - there is a lot of manual work to
include required extension to the Ignite binary distribution (e.g.
build an extension, copy libs etc.). We should provide an ability to
build and prepare the Ignite binary distribution with the extension we
need. The same way as the dependencies-apache-ignite-lgpl.xml does.
I've created an issue for that [2].


[1] https://ignite.apache.org/docs/latest/setup#enabling-modules
[2] https://issues.apache.org/jira/browse/IGNITE-16981

On Thu, 28 Apr 2022 at 15:43, Maxim Muzafarov  wrote:
>
> Folks,
>
> I've created a task:
> https://issues.apache.org/jira/browse/IGNITE-16908
>
> On Tue, 26 Apr 2022 at 23:16, Nikita Amelchev  wrote:
> >
> > +1
> >
> > вт, 26 апр. 2022 г. в 17:22, Anton Vinogradov :
> > >
> > > +1
> > >
> > > On Tue, Apr 26, 2022 at 4:45 PM Николай Ижиков  
> > > wrote:
> > >
> > > > +1
> > > >
> > > > > 26 апр. 2022 г., в 16:24, Maxim Muzafarov 
> > > > написал(а):
> > > > >
> > > > > Hello Igniters,
> > > > >
> > > > >
> > > > > Currently we have a batch of ignite-hibernate modules which provide
> > > > > Hibernate second-level cache (L2 cache) implementation based on the
> > > > > Apache Ignite for different version of hibernate.
> > > > >
> > > > > The following list of modules we have:
> > > > > - ignite-hibernate_4.2
> > > > > - ignite-hibernate_5.1
> > > > > - ignite-hibernate_5.3
> > > > > - ignite-hibernate-core (a common part for all hibernate modules)
> > > > >
> > > > > I propose to use the same approach as was used for the
> > > > > ignite-spring-data module [1] and move all these modules to the Ignite
> > > > > Extesions project.
> > > > >
> > > > > In details:
> > > > >
> > > > > - remove all these modules from the Ignite project.
> > > > > - create ignite-hibernate extension.
> > > > > - move ignite-hibernate-core + ignite-hibernate_4.2 to
> > > > > release/ignite-hibernate-4.2.0 branch (the version of ignite-hibernate
> > > > > extension will be 4.2.0) and release it on demand;
> > > > > - move ignite-hibernate-core + ignite-hibernate_5.1 to
> > > > > release/ignite-hibernate-5.1.0 branch (the version of ignite-hibernate
> > > > > extension will be 5.1.0) and release it on demand;
> > > > > - move ignite-hibernate-core + ignite-hibernate_5.3 to the master
> > > > > branch and to the release/ignite-hibernate-5.3.0 branch (the version
> > > > > of ignite-hibernate extension will be 5.3.0) and release it
> > > > > immediately;
> > > > >
> > > > >
> > > > > Is it OK or am I missing something?
> > > > > WDYT?
> > > > >
> > > > >
> > > > > [1] https://lists.apache.org/thread/b03bny7xj9x5ty371srtdn9ysd72qht7
> > > >
> > > >
> >
> >
> >
> > --
> > Best wishes,
> > Amelchev Nikita

[VOTE] Release Extensions Ignite Spring Data 2.0.0 RC1, Ignite Spring Session 1.0.0 RC1, Ignite Zookeeper IP Finder 1.0.0 RC1

[Maxim Muzafarov]

Dear Community,


The release candidates are ready.

The ignite-zookeeper-ip-finder and ignite-spring-session haven't been
changed since the last vote. All the issues mentioned in the previous
vote related to the ignite-spring-data-ext have also fixed.

See the links below.


== Ignite Spring Data Extension Module 2.0.0 ==

The release candidate is uploaded to:
https://dist.apache.org/repos/dist/dev/ignite/ignite-extensions/ignite-spring-data-ext-2.0.0-rc1/

The following Maven staging can be used:
https://repository.apache.org/content/repositories/orgapacheignite-1550/org/apache/ignite/ignite-spring-data-ext/

Tag:
https://github.com/apache/ignite-extensions/releases/tag/ignite-spring-data-ext-2.0.0-rc1

RELEASE_NOTES:
https://github.com/apache/ignite-extensions/blob/release/ignite-spring-data-ext-2.0.0/modules/spring-data-ext/spring-data/RELEASE_NOTES.txt

DEVNOTES:
https://github.com/apache/ignite-extensions/blob/release/ignite-spring-data-ext-2.0.0/DEVNOTES.md

Release Checker Results:
https://github.com/apache/ignite-extensions/runs/6420862446?check_suite_focus=true



== Ignite Spring Session Extension Module 1.0.0 ==

The release candidate is uploaded to:
https://dist.apache.org/repos/dist/dev/ignite/ignite-extensions/ignite-spring-session-ext-1.0.0-rc1/

The following Maven staging can be used:
https://repository.apache.org/content/repositories/orgapacheignite-1548/org/apache/ignite/ignite-spring-session-ext/

Tag:
https://github.com/apache/ignite-extensions/releases/tag/ignite-spring-session-ext-1.0.0-rc1

RELEASE_NOTES:
https://github.com/apache/ignite-extensions/blob/release/ignite-spring-session-ext-1.0.0/modules/spring-session-ext/RELEASE_NOTES.txt

DEVNOTES:
https://github.com/apache/ignite-extensions/blob/master/DEVNOTES.md

Release Checker Results:
https://github.com/apache/ignite-extensions/runs/6229613223?check_suite_focus=true


== Ignite Zookeeper Ip Finder Extension Module 1.0.0 ==

The release candidate is uploaded to:
https://dist.apache.org/repos/dist/dev/ignite/ignite-extensions/ignite-zookeeper-ip-finder-ext-1.0.0-rc1/

The following Maven staging can be used:
https://repository.apache.org/content/repositories/orgapacheignite-1549/org/apache/ignite/ignite-zookeeper-ip-finder-ext/

Tag:
https://github.com/apache/ignite-extensions/releases/tag/ignite-zookeeper-ip-finder-ext-1.0.0-rc1

RELEASE_NOTES:
https://github.com/apache/ignite-extensions/blob/release/ignite-zookeeper-ip-finder-ext-1.0.0/modules/zookeeper-ip-finder-ext/zookeeper-ip-finder/RELEASE_NOTES.txt

DEVNOTES:
https://github.com/apache/ignite-extensions/blob/master/DEVNOTES.md

Release Checker Results:
https://github.com/apache/ignite-extensions/runs/6210193576?check_suite_focus=true



The vote is formal, see voting guidelines
https://www.apache.org/foundation/voting.html

+1 - to accept (Ignite Spring Data 2.0.0 RC1, Ignite Spring Session
1.0.0 RC1, Ignite Zookeeper IP Finder 1.0.0 RC1)
0 - don't care either way
-1 - DO NOT accept (explain why)

See notes on how to verify release here
https://www.apache.org/info/verification.html
and
https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification


This vote will be open for at least 4 days till Tue May 17, 2022,
14:00 Moscow TZ. Please, write me down the thread if you need
additional time to check the release.

https://www.timeanddate.com/countdown/vote?iso=20220517T14=166=%5BVOTE%5D+Release+Extensions+Ignite+Spring+Data+2.0.0+RC1%2C+Ignite+Spring+Session+1.0.0+RC1%2C+Ignite+Zookeeper+IP+Finder+1.0.0+RC1=serif

[RESULT] [VOTE] Release Ignite AWS 1.0.0 RC1, Ignite Azure 1.0.0 RC1, Ignite GCE 1.0.0 RC1

[Maxim Muzafarov]

Hello, Igniters!

The Ignite AWS 1.0.0 RC1, Ignite Azure 1.0.0 RC1, Ignite GCE 1.0.0 RC1
extensions have been accepted.

4 - "+1" votes received.
1 - "0" vote received.

Here are the +1 votes received:

 - Anton Vinogradov (binding)
 - Nikita Amelchev
 - Nikolay Izhikov (binding)
 - Andrey Gura (binding)

Here are the "0" votes received:
 - Alexey Plehanov

Here is the link to the voting thread -
https://lists.apache.org/thread/7fkh6vc2rz45vyo6hfndxdldj99035w6

Thank you!

[CANCEL] [VOTE] Release Extensions Ignite Spring Data 2.2.0 RC1, Ignite Spring Session 1.0.0 RC1, Ignite Zookeeper IP Finder 1.0.0 RC1

[Maxim Muzafarov]

The vote is cancelled.

The following issues must be fixed:

https://issues.apache.org/jira/browse/IGNITE-16927
https://issues.apache.org/jira/browse/IGNITE-16968

Re: [VOTE] Release Extensions Ignite Spring Data 2.2.0 RC1, Ignite Spring Session 1.0.0 RC1, Ignite Zookeeper IP Finder 1.0.0 RC1

[Maxim Muzafarov]

Alex,

Thank you for the reply.

> 1. I don't quite understand why the version of ignite-spring-data-ext is
2.2.0?

This is an intent to correspond the spring-data version dependency was
used. However, I don't see any problems to release with 2.0 version.
The scope `provided` for the spring-data dependency must be fixed for
sure prior to release.

I'll prepare a new RC for that.


> 2. Release files doesn't include pom.xml file in the root directory,

This is correct. The root pom.xml file is the aggregation pom which
used for building all the extension and should be used to build a
single extension from sources.
The extension sources contains only single extension which should be
build from the extension directory.

> 3. With JDK 11 there is a problem when building using command line from
DEVNOTES.md

I'll add additional comments for that in DEVNOTES.

> 4. Strange directory names in "modules" directory.

I'll fix with a separate issue.

On Thu, 12 May 2022 at 12:46, Alex Plehanov  wrote:
>
> "0" from me.
>
> 1. I don't quite understand why the version of ignite-spring-data-ext is
> 2.2.0?
> There were already versions released earlier:
> ignite-spring-data-ext 1.0.0
> ignite-spring-data-2.0-ext 1.0.0
> ignite-spring-data-2.2-ext 1.0.0
> Artifacts ignite-spring-data-ext and ignite-spring-data-2.0-ext were
> deleted, artifact ignite-spring-data-2.2-ext was moved to
> ignite-spring-data-ext, but why did the version become 2.2.0? Looks
> illogical to me. Current version of this artifact in master branch is
> 2.0.0-SNAPSHOT, we should just remove the "-SNAPSHOT" word while releasing.
> Binding ignite-spring-data-ext version to some outdated spring-data
> version, in my opinion, is not correct. BTW, the last released version of
> spring-data is 2.6.4, we include as dependency 2.2 version, but perhaps it
> should be with "provided" scope.
>
> 2. Release files doesn't include pom.xml file in the root directory, but
> according to included file DEVNOTES.md to build extensions we should run:
> mvn clean install -DskipTests -Pcheckstyle
> This command can't be executed without a root pom.xml file (the previous
> releases of ignite-spring-data-ext contains this file).
>
> 3. With JDK 11 there is a problem when building using command line from
> DEVNOTES.md ("mvn clean install -f modules/...-ext -Pcheckstyle"), tests
> use reflection and should be run with additional "--add-opens" options. Or
> there should be instructions in DEVNOTES.md how to build without running
> tests (-DskipTests option).
> Also, there are problems with javadoc processing during build, if the
> ignite-tools artifact was built using JDK 8.
> I was able to build with JDK 11 only using this command line:
> mvn clean install -f modules/ignite-spring-data-parent-ext -Pcheckstyle
> -DskipTests -Dmaven.javadoc.skip=true
> So, we should explicitly note in DEVNOTES that build is possible only with
> JDK 8 or fix command lines to build with higher JDK versions.
>
> 4. Strange directory names in "modules" directory. For example,
> "ignite-spring-data-parent-ext" in the released zip file, but
> "spring-data-ext" (with the same content) in the master branch.
>
>
> ср, 4 мая 2022 г. в 17:43, Andrey Gura :
>
> > +1
> >
> > On Fri, Apr 29, 2022 at 7:22 PM Nikita Amelchev 
> > wrote:
> > >
> > > +1
> > >
> > > пт, 29 апр. 2022 г. в 17:54, Anton Vinogradov :
> > > >
> > > > +1
> > > >
> > > > On Fri, Apr 29, 2022 at 5:28 PM Maxim Muzafarov 
> > wrote:
> > > >
> > > > > Dear Community,
> > > > >
> > > > >
> > > > > The release candidates are ready. See the links below.
> > > > >
> > > > >
> > > > > == Ignite Spring Data Extension Module 2.2.0 ==
> > > > >
> > > > > The release candidate is uploaded to:
> > > > >
> > > > >
> > https://dist.apache.org/repos/dist/dev/ignite/ignite-extensions/ignite-spring-data-ext-2.2.0-rc1/
> > > > >
> > > > > The following Maven staging can be used:
> > > > >
> > > > >
> > https://repository.apache.org/content/repositories/orgapacheignite-1547/org/apache/ignite/ignite-spring-data-ext/
> > > > >
> > > > > Tag:
> > > > >
> > > > >
> > https://github.com/apache/ignite-extensions/releases/tag/ignite-spring-data-ext-2.2.0-rc1
> > > > >
> > > > > RELEASE_NOTES:
> > > > >
> > > > >
> > https://github.com/apache/ignite

[VOTE] Release Extensions Ignite Spring Data 2.2.0 RC1, Ignite Spring Session 1.0.0 RC1, Ignite Zookeeper IP Finder 1.0.0 RC1

[Maxim Muzafarov]

Dear Community,


The release candidates are ready. See the links below.


== Ignite Spring Data Extension Module 2.2.0 ==

The release candidate is uploaded to:
https://dist.apache.org/repos/dist/dev/ignite/ignite-extensions/ignite-spring-data-ext-2.2.0-rc1/

The following Maven staging can be used:
https://repository.apache.org/content/repositories/orgapacheignite-1547/org/apache/ignite/ignite-spring-data-ext/

Tag:
https://github.com/apache/ignite-extensions/releases/tag/ignite-spring-data-ext-2.2.0-rc1

RELEASE_NOTES:
https://github.com/apache/ignite-extensions/blob/release/ignite-spring-data-ext-2.2.0/modules/spring-data-ext/spring-data/RELEASE_NOTES.txt

DEVNOTES:
https://github.com/apache/ignite-extensions/blob/master/DEVNOTES.md

Release Checker Results:
https://github.com/apache/ignite-extensions/runs/6229346844?check_suite_focus=true



== Ignite Spring Session Extension Module 1.0.0 ==

The release candidate is uploaded to:
https://dist.apache.org/repos/dist/dev/ignite/ignite-extensions/ignite-spring-session-ext-1.0.0-rc1/

The following Maven staging can be used:
https://repository.apache.org/content/repositories/orgapacheignite-1548/org/apache/ignite/ignite-spring-session-ext/

Tag:
https://github.com/apache/ignite-extensions/releases/tag/ignite-spring-session-ext-1.0.0-rc1

RELEASE_NOTES:
https://github.com/apache/ignite-extensions/blob/release/ignite-spring-session-ext-1.0.0/modules/spring-session-ext/RELEASE_NOTES.txt

DEVNOTES:
https://github.com/apache/ignite-extensions/blob/master/DEVNOTES.md

Release Checker Results:
https://github.com/apache/ignite-extensions/runs/6229613223?check_suite_focus=true


== Ignite Zookeeper Ip Finder Extension Module 1.0.0 ==

The release candidate is uploaded to:
https://dist.apache.org/repos/dist/dev/ignite/ignite-extensions/ignite-zookeeper-ip-finder-ext-1.0.0-rc1/

The following Maven staging can be used:
https://repository.apache.org/content/repositories/orgapacheignite-1549/org/apache/ignite/ignite-zookeeper-ip-finder-ext/

Tag:
https://github.com/apache/ignite-extensions/releases/tag/ignite-zookeeper-ip-finder-ext-1.0.0-rc1

RELEASE_NOTES:
https://github.com/apache/ignite-extensions/blob/release/ignite-zookeeper-ip-finder-ext-1.0.0/modules/zookeeper-ip-finder-ext/zookeeper-ip-finder/RELEASE_NOTES.txt

DEVNOTES:
https://github.com/apache/ignite-extensions/blob/master/DEVNOTES.md

Release Checker Results:
https://github.com/apache/ignite-extensions/runs/6210193576?check_suite_focus=true



The vote is formal, see voting guidelines
https://www.apache.org/foundation/voting.html

+1 - to accept (Ignite Spring Data 2.2.0 RC1, Ignite Spring Session
1.0.0 RC1, Ignite Zookeeper IP Finder 1.0.0 RC1)
0 - don't care either way
-1 - DO NOT accept (explain why)

See notes on how to verify release here
https://www.apache.org/info/verification.html
and
https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification


This vote will be open for at least 7 days till Sat May 7, 2022,
14:00 Moscow TZ. Please, write me down the thread if you need
additional time to check the release.

https://www.timeanddate.com/countdown/vote?iso=20220507T14=166=%5BVOTE%5D+Release+Extensions+Ignite+Spring+Data+2.2.0+RC1%2C+Ignite+Spring+Session+1.0.0+RC1%2C+Ignite+Zookeeper+IP+Finder+1.0.0+RC1=sanserif

[VOTE] Release Ignite AWS 1.0.0 RC1, Ignite Azure 1.0.0 RC1, Ignite GCE 1.0.0 RC1

[Maxim Muzafarov]

Dear Community,


The release candidates are ready. See the links below.


== Ignite AWS Extension Module 1.0.0 ==

The release candidate is uploaded to:
https://dist.apache.org/repos/dist/dev/ignite/ignite-extensions/ignite-aws-ext-1.0.0-rc1

The following Maven staging can be used:
https://repository.apache.org/content/repositories/orgapacheignite-1543/org/apache/ignite/ignite-aws-ext/

Tag:
https://github.com/apache/ignite-extensions/releases/tag/ignite-aws-ext-1.0.0-rc1

RELEASE_NOTES:
https://github.com/apache/ignite-extensions/blob/release/ignite-aws-ext-1.0.0/modules/aws-ext/RELEASE_NOTES.txt

DEVNOTES:
https://github.com/apache/ignite-extensions/blob/master/DEVNOTES.md

Release Checker Results:
https://github.com/apache/ignite-extensions/runs/6227581198?check_suite_focus=true


== Ignite Azure Extension Module 1.0.0 ==

The release candidate is uploaded to:
https://dist.apache.org/repos/dist/dev/ignite/ignite-extensions/ignite-azure-ext-1.0.0-rc1/

The following Maven staging can be used:
https://repository.apache.org/content/repositories/orgapacheignite-1545/org/apache/ignite/ignite-azure-ext/

Tag:
https://github.com/apache/ignite-extensions/releases/tag/ignite-azure-ext-1.0.0-rc1

RELEASE_NOTES:
https://github.com/apache/ignite-extensions/blob/release/ignite-azure-ext-1.0.0/modules/azure-ext/RELEASE_NOTES.txt

DEVNOTES:
https://github.com/apache/ignite-extensions/blob/master/DEVNOTES.md

Release Checker Results:
https://github.com/apache/ignite-extensions/runs/6228019576?check_suite_focus=true


== Ignite GCE Extension Module 1.0.0 ==

The release candidate is uploaded to:
https://dist.apache.org/repos/dist/dev/ignite/ignite-extensions/ignite-gce-ext-1.0.0-rc1/

The following Maven staging can be used:
https://repository.apache.org/content/repositories/orgapacheignite-1546/org/apache/ignite/ignite-gce-ext/

Tag:
https://github.com/apache/ignite-extensions/releases/tag/ignite-gce-ext-1.0.0-rc1

RELEASE_NOTES:
https://github.com/apache/ignite-extensions/blob/release/ignite-gce-ext-1.0.0/modules/gce-ext/RELEASE_NOTES.txt

DEVNOTES:
https://github.com/apache/ignite-extensions/blob/master/DEVNOTES.md

Release Checker Results:
https://github.com/apache/ignite-extensions/runs/6228169980?check_suite_focus=true


The vote is formal, see voting guidelines
https://www.apache.org/foundation/voting.html

+1 - to accept (Ignite AWS 1.0.0 RC1, Ignite Azure 1.0.0 RC1, Ignite
GCE 1.0.0 RC1)
0 - don't care either way
-1 - DO NOT accept (explain why)

See notes on how to verify release here
https://www.apache.org/info/verification.html
and
https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification


This vote will be open for at least 7 days till Fri May 7, 2022,
14:00 Moscow TZ. Please, write me down the thread if you need
additional time to check the release.

https://www.timeanddate.com/countdown/vote?iso=20220507T14=166=%5BVOTE%5D+Release+Ignite+AWS+1.0.0+RC1%2C+Ignite+Azure+1.0.0+RC1%2C+Ignite+GCE+1.0.0+RC1=sanserif

Re: [DISCUSSION] Move ignite-hibernate modules to the Ignite Extensions

[Maxim Muzafarov]

Folks,

I've created a task:
https://issues.apache.org/jira/browse/IGNITE-16908

On Tue, 26 Apr 2022 at 23:16, Nikita Amelchev  wrote:
>
> +1
>
> вт, 26 апр. 2022 г. в 17:22, Anton Vinogradov :
> >
> > +1
> >
> > On Tue, Apr 26, 2022 at 4:45 PM Николай Ижиков  wrote:
> >
> > > +1
> > >
> > > > 26 апр. 2022 г., в 16:24, Maxim Muzafarov 
> > > написал(а):
> > > >
> > > > Hello Igniters,
> > > >
> > > >
> > > > Currently we have a batch of ignite-hibernate modules which provide
> > > > Hibernate second-level cache (L2 cache) implementation based on the
> > > > Apache Ignite for different version of hibernate.
> > > >
> > > > The following list of modules we have:
> > > > - ignite-hibernate_4.2
> > > > - ignite-hibernate_5.1
> > > > - ignite-hibernate_5.3
> > > > - ignite-hibernate-core (a common part for all hibernate modules)
> > > >
> > > > I propose to use the same approach as was used for the
> > > > ignite-spring-data module [1] and move all these modules to the Ignite
> > > > Extesions project.
> > > >
> > > > In details:
> > > >
> > > > - remove all these modules from the Ignite project.
> > > > - create ignite-hibernate extension.
> > > > - move ignite-hibernate-core + ignite-hibernate_4.2 to
> > > > release/ignite-hibernate-4.2.0 branch (the version of ignite-hibernate
> > > > extension will be 4.2.0) and release it on demand;
> > > > - move ignite-hibernate-core + ignite-hibernate_5.1 to
> > > > release/ignite-hibernate-5.1.0 branch (the version of ignite-hibernate
> > > > extension will be 5.1.0) and release it on demand;
> > > > - move ignite-hibernate-core + ignite-hibernate_5.3 to the master
> > > > branch and to the release/ignite-hibernate-5.3.0 branch (the version
> > > > of ignite-hibernate extension will be 5.3.0) and release it
> > > > immediately;
> > > >
> > > >
> > > > Is it OK or am I missing something?
> > > > WDYT?
> > > >
> > > >
> > > > [1] https://lists.apache.org/thread/b03bny7xj9x5ty371srtdn9ysd72qht7
> > >
> > >
>
>
>
> --
> Best wishes,
> Amelchev Nikita

Re: [DISCUSSION] Apache Ignite Extension Release Process Improvements

[Maxim Muzafarov]

Folks,


1. The changes mentioned above have been implemented in the following
umbrella ticket [1]. Please, take a look.
2. Removing dependency from the `log4j-test.xml` or `tests.properties`
in extensions should be a part of [2] issue implementation (removing
dependency from log4j 1.2.17).


== CHANGES ==


1. The ignite-parent pom artifact is now added to the Ignite release
lifecycle. It will allow sharing the checkstyle, properties, profiles
and build configurations to the Ignite Extension which in turn leads
to the single building + releasing lifecycle for the Ignite + Ignite
Extensions.

2. The BOM module created with all the valuable Ignite modules. It
simplifies the internal dependency management. You don't need use
${project.verstion} for adding a new module as a
dependency.

3. All changes are automatically deployed to the Maven Central
Snapshot repository on each commit in the master branch (GitHub Action
is configured for this). This will simplify the extensions development
lifecycle on the top of the Apache Ignite changes.
https://github.com/apache/ignite/blob/master/.github/workflows/publish-snapshot.yml
https://repository.apache.org/content/repositories/snapshots/org/apache/ignite/ignite-core/2.14.0-SNAPSHOT/


== RELEASE EXAMPLE ==


1.
The release branch created for the Zooleeper Ip Finder Extension
https://github.com/apache/ignite-extensions/blob/release/ignite-zookeeper-ip-finder-ext-1.0.0/modules/zookeeper-ip-finder-ext/pom.xml#L34

2.
See the GitHub Action with prepared RC. The Action must be stared from
the release branch (release/ignite-zookeeper-ip-finder-ext-1.0.0). You
can download the prepared `artifact` and sign the release with your
own signature.
https://github.com/apache/ignite-extensions/actions/runs/2239023047

During the release candidate preparation:

- validate the release branch
(release/ignite-zookeeper-ip-findere-ext-1.0.0 must have 1.0.0 version
in the pom);
- checking that there are no SNAPSHOT versions in the release branch;
- build the sources and binaries (if applicable) archives for the
releasing extension;
- preparing shell scripts for signing and deploying artifact to the
Maven Central staging and svn;
- creating a new rc-tag which points to the last commit in the release branch;

3.
See the prepared binaries and sources which were created and uploaded
using shell scripts from the Action artifact.
https://dist.apache.org/repos/dist/dev/ignite/ignite-extensions/ignite-zookeeper-ip-finder-ext-1.0.0-rc1/

4.
You can check and validate the release candidate using the following
GitHub Action fro the master branch:
https://github.com/apache/ignite-extensions/runs/6210193576?check_suite_focus=true

This action will do:

- compare version of the release branch and pom;
- build the extension sources;
- validate archives (binary and sources) hashes;
- validate  archives (binary and sources)  signatures;
- check that there is a rc-tag which points to the last commit;

5.
You can find the valuable release preparation instruction in the DEVNOTES
https://github.com/apache/ignite-extensions/blob/master/DEVNOTES.md

6.
I deliberately didn't add the post-release shell scripts since they
are really straightforward.
(close Maven staging from the UI, move binaries & sources to new
directory, add release tag)



[1] https://issues.apache.org/jira/browse/IGNITE-16855
[2] https://issues.apache.org/jira/browse/IGNITE-16650

On Fri, 18 Feb 2022 at 10:05, Nikolay Izhikov  wrote:
>
> Hello, Maxim.
>
> Thanks for investigation!
>
> > 4. log4j-test.xml, tests.properties these files from the ignite-core module 
> > required to run tests and it seems they should be shared between projects 
> > also as tests resources.
>
> As you may see most copies of these files are empty.
> I think we should modify `GridAbstractTest` and other classes to use defaults 
> if `log4j-test.xml` or `tests.properties` unavailable.
>
> > 4. Configure Travis [10] to deploy a new snapshot version to the apache 
> > maven snapshots repository [5] each time the Ignite master branch is 
> > updated.
>
> Can we attach Ignite sources as maven modules to Ignite extensions?
> And use Ignite sources as dependencies?
>
> > 18 февр. 2022 г., в 00:30, Maxim Muzafarov  написал(а):
> >
> > Hello Igniters,
> >
> >
> > We have a lot of Ignite extensions waiting to be released (e.g. aws,
> > gce, topology-validator, ignite-spring-tx-ext etc.). I think it is a
> > good point in time to make some kind of automation and simplify our
> > release process for Ignite extension modules removing manual steps
> > from it.
> >
> >
> > During the investigation I've found some issues that we have:
> >
> > 1. Ignite extensions have their own parent pom file [2]. The code and
> > dependency versions are fully duplicated with the Ignite parent pom
> > [1], ho

[DISCUSSION] Move ignite-hibernate modules to the Ignite Extensions

[Maxim Muzafarov]

Hello Igniters,


Currently we have a batch of ignite-hibernate modules which provide
Hibernate second-level cache (L2 cache) implementation based on the
Apache Ignite for different version of hibernate.

The following list of modules we have:
- ignite-hibernate_4.2
- ignite-hibernate_5.1
- ignite-hibernate_5.3
- ignite-hibernate-core (a common part for all hibernate modules)

I propose to use the same approach as was used for the
ignite-spring-data module [1] and move all these modules to the Ignite
Extesions project.

In details:

- remove all these modules from the Ignite project.
- create ignite-hibernate extension.
- move ignite-hibernate-core + ignite-hibernate_4.2 to
release/ignite-hibernate-4.2.0 branch (the version of ignite-hibernate
extension will be 4.2.0) and release it on demand;
- move ignite-hibernate-core + ignite-hibernate_5.1 to
release/ignite-hibernate-5.1.0 branch (the version of ignite-hibernate
extension will be 5.1.0) and release it on demand;
- move ignite-hibernate-core + ignite-hibernate_5.3 to the master
branch and to the release/ignite-hibernate-5.3.0 branch (the version
of ignite-hibernate extension will be 5.3.0) and release it
immediately;


Is it OK or am I missing something?
WDYT?


[1] https://lists.apache.org/thread/b03bny7xj9x5ty371srtdn9ysd72qht7

Re: [VOTE] Release Apache Ignite 2.13.0 RC2

[Maxim Muzafarov]

+1 (binding)

Checked parent project, versions, dependencies.

On Mon, 25 Apr 2022 at 12:06, Ilya Kasnacheev  wrote:
>
> +1 (binding)
>
> Ran a slim node, built from sources, built and ran c++ node.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пн, 25 апр. 2022 г. в 08:55, Николай Ижиков :
>
> > +1 (binding)
> >
> > > 23 апр. 2022 г., в 17:32, Nikita Amelchev 
> > написал(а):
> > >
> > > Hi Igniters, PMCs,
> > >
> > > Please, verify a new release candidate.
> > >
> > > The vote will continue until there are enough votes for a resolution. [1]
> > >
> > > [1] https://www.apache.org/foundation/voting.html#ReleaseVotes
> > >
> > > пт, 22 апр. 2022 г. в 08:24, Zhenya Stanilovsky
> > :
> > >>
> > >>
> > >> Nikita thanks for your effort !
> > >> Download sources, run examples.
> > >> +1 from me.
> > >>
> > >>> Dear Community,
> > >>>
> > >>> The release candidate is ready.
> > >>>
> > >>> I have uploaded a release candidate to:
> > >>> https://dist.apache.org/repos/dist/dev/ignite/2.13.0-rc2/
> > >>> https://dist.apache.org/repos/dist/dev/ignite/packages_2.13.0-rc2/
> > >>>
> > >>> The following staging can be used for testing:
> > >>>
> > https://repository.apache.org/content/repositories/orgapacheignite-1542
> > >>>
> > >>> Tag name is 2.13.0-rc1:
> > >>>
> > https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=refs/tags/2.13.0-rc2
> > >>>
> > >>> RELEASE_NOTES:
> > >>>
> > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.13
> > >>>
> > >>> Complete list of resolved issues:
> > >>>
> > https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.13%27))%20and%20status%20in%20(%27CLOSED%27%2C%20%27RESOLVED%27)%20ORDER%20BY%20priority
> > >>>
> > >>> DEVNOTES:
> > >>>
> > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=ignite-2.13
> > >>>
> > >>> Additional checks have been performed (available for users included
> > >>> into the release group on TeamCity).
> > >>>
> > >>> TC [Check RC: Licenses, compile, chksum]
> > >>>
> > https://ci2.ignite.apache.org/buildConfiguration/ignite2_Release_ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum/6399934
> > >>>
> > >>> TC [2] Compare w/ Previous Release
> > >>>
> > https://ci2.ignite.apache.org/buildConfiguration/ignite2_Release_ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency/6399932
> > >>>
> > >>> The vote is formal, see voting guidelines
> > >>> https://www.apache.org/foundation/voting.html
> > >>>
> > >>> +1 - to accept Apache Ignite 2.13.0-rc2
> > >>> 0 - don't care either way
> > >>> -1 - DO NOT accept Apache Ignite Ignite 2.13.0-rc2 (explain why)
> > >>>
> > >>> See notes on how to verify release here
> > >>> https://www.apache.org/info/verification.html
> > >>> and
> > >>>
> > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
> > >>>
> > >>> This vote will be open for at least 3 days till Fri Apr 23, 2022,
> > >>> 20:00 UTC. Please, write me down the thread if you need additional
> > >>> time to check the
> > >>> release.
> > >>>
> > https://www.timeanddate.com/countdown/vote?iso=20220423T20=0=VOTE+on+the+Apache+Ignite+Release+2.13.0+RC2=sanserif
> > >>>
> > >>> --
> > >>> Best wishes,
> > >>> Amelchev Nikita
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > > --
> > > Best wishes,
> > > Amelchev Nikita
> >
> >

Re: [DISCUSSION] Update documentation with GitHub Actions

[Maxim Muzafarov]

Hello,

+1, great improvement.

On Sat, 23 Apr 2022 at 17:26, Nikita Amelchev  wrote:
>
> Hello, Igniters.
>
> I propose to add a GitHub action to update documentation for released
> Ignite versions by a click. [1]
>
> For now, this is a complex manual work that requires understanding all
> the intermediate steps. [2]
>
> New process to update documentation:
> 1. Commit documentation changes to a released branch.
> 2. Run the action with a click.
> 3. Check the result.
>
> Moreover, this will also simplify the process of publishing a new release.
>
> ASF's GitHub Actions Policy allows automated services to push changes
> related to documentation. [3]
> Write access is required to run the workflow. So, only committers can
> run the action. [4]
>
> WDYT? Any objections?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-16895
> [2] 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=85461527#HowtoDocument-UpdatingPublishedDocs
> [3] https://infra.apache.org/github-actions-policy.html
> [4] 
> https://docs.github.com/en/actions/managing-workflow-runs/manually-running-a-workflow
>
> --
> Best wishes,
> Amelchev Nikita

Re: [DISCUSSION] Removing extensions for obsolete Ignite Spring Data integrations.

[Maxim Muzafarov]

Hello Roman,

+1 to your suggestion.
If you need any help with a review, please let me know.

On Mon, 18 Apr 2022 at 13:17, Roman Puchkovskiy
 wrote:
>
> Hi guys.
>
> This thread has been hanging for quite some time (no pun intended).
> While it was hanging, CVE-2022-22965 [1] was discovered which makes it
> extremely dangerous to have vulnerable versions of Spring as
> dependencies.
>
> As discussed, ignite-extensions has 3 versions of spring-data
> integrations (against versions 1.0, 2.0, 2.2 of spring-data), namely
> ignite-spring-data, ignite-spring-data_2.0, ignite-spring-data_2.2.
> They use Spring versions 4.3.x, 5.0.x, 5.2.x, respectively. Of them,
> only 5.2 branch is still supported and got a fix for CVE-2022-22965.
>
> My suggestion is to implement what was suggested earlier in this thread:
>
> 1. Remove ignite-spring-data and ignite-spring-data_2.0
> 2. Update ignite-spring-data_2.2 module to depend on the latest Spring
> version in branch 5.2 (it's currently 5.2.21)
> 3. Probably also rename ignite-spring-data_2.2 extension to
> ignite-spring-data (dropping the version postfix).
>
> I created a Jira ticket [2].
>
> Later, in a separate ticket (with no rush due to the urgency of the
> matter), we could update the integration to work with the most recent
> spring-data version.
>
> What are your thoughts?
>
> [1] - https://nvd.nist.gov/vuln/detail/CVE-2022-22965
> [2] - https://issues.apache.org/jira/browse/IGNITE-16869
>
> пт, 18 февр. 2022 г. в 20:58, Maksim Timonin :
> >
> > > My proposal is not about creating a separate repository for the 
> > > spring-data
> > extension - just left a single module
> >
> > Yeah, you're correct. I mean that we need a single point of truth for
> > spring-data - single repository or single module. I'm +1 here.
> >
> > > So creating some branches to store obsolete code for a module seems a bit
> > confusing
> >
> > IMHO, we should have an opportunity to release a hot fix asap for those
> > modules in case of critical CVE, particularly if it is impossible to just
> > make an upgrade from 2.0 to 2.2 or to the latest version due to backward
> > compatibility.
> >
> > WDYT?
> >
> > On Fri, Feb 18, 2022 at 2:12 PM Mikhail Petrov 
> > wrote:
> >
> > > Maksim,
> > >
> > > Currently, we have a single repository where all extensions are stored
> > > as separate modules - [1]
> > > My proposal is not about creating a separate repository for the
> > > spring-data extension - just left a single module for the spring-data
> > > extension and proceed with its developments the same way as for other
> > > extensions - [2].
> > > So creating some branches to store obsolete code for a module seems a
> > > bit confusing.
> > >
> > >
> > > One of the goals of this refactoring is to create the Spring Data
> > > integration extension that will be independent of the version of Spring
> > > Data.
> > > (as it is already done for Spring Cache or Spring Transactions
> > > integrations). It must be updated and re-released only in case of broken
> > > backward compatibility between Spring Data versions or if the extension
> > > itself is updated. This process is described in the thread - [2].
> > >
> > >
> > > [1] - https://github.com/apache/ignite-extensions/tree/master/modules
> > > [2] - https://lists.apache.org/thread/wox65gp3fyjkx048205t9omm418o3f20
> > >
> > > On 18.02.2022 13:13, Maksim Timonin wrote:
> > > > Hi Mikhail,
> > > >
> > > >> remove extension modules that are tied to the specific Spring Data
> > > versions
> > > > - keep only a single spring-data-ext module. For now, it will contain
> > > code
> > > > for the latest Ignite Spring Data integration -
> > > ignite-spring-data-2.2-ext.
> > > >
> > > > I'm +1 for having a single repository for the spring-data extensions.
> > > But I
> > > > think we must not completely remove code for 2.0, 2.1 versions. I'd
> > > propose
> > > > to create separated branches in the repository for those versions, and
> > > put
> > > > tags for already released versions.
> > > >
> > > >> According to [5] 1.0 and 2.0 versions are no longer supported
> > > > According to this 2.2 isn't supported too, the last release was a year
> > > ago,
> > > > is it? Do we have plans to support spring-data with the latest version?
> > > >
> > > > On Fri, Feb 18, 2022 at 10:57 AM Mikhail Petrov 
> > > > wrote:
> > > >
> > > >> Igniters,
> > > >>Currently, we have three separate modules for Ignite Spring Data
> > > >> integrations - [1 - 3]. Each of them depends on the specific version of
> > > >> the Spring Data - 1.0, 2.0, and 2.2, respectively.
> > > >>
> > > >>I propose to:
> > > >>1. remove extension modules that are tied to the specific Spring 
> > > >> Data
> > > >> versions - keep only a single spring-data-ext module. For now, it will
> > > >> contain code for the latest Ignite Spring Data integration -
> > > >> ignite-spring-data-2.2-ext.
> > > >>2. Proceed with spring-data integration future releases as were
> > > >> discussed here - 

Re: [ANNOUNCE] New wiki section for Apache Ignite 3 contributors

[Maxim Muzafarov]

Agree with Anton.

Since the Ignite-3 is a completely different database and have nothing
in common with the Ignite-2 projects it seems it will be better to
have all the related stuff on its own Jira and Wiki pages.

On Mon, 21 Feb 2022 at 13:29, Anton Vinogradov  wrote:
>
> Andrey,
>
> Could we create a separate and explicit IGNITE-3 project at confluence for
> Ignite 3 wikis?
>
> On Mon, Feb 14, 2022 at 9:21 AM Andrey Gura  wrote:
>
> > Igniters,
> >
> > The new wiki section for Apache Ignite 3 contributors is created. This
> > page [1] is the main entry point for new and existing contributors and
> > the page provides information about differences in the development
> > process (e.g. code style, practices, etc), the product architecture,
> > technical details, etc.
> >
> > At the moment the Java Code Style Guide page [2] contains information
> > about Apache Ignite 3 code style and some additional rules discussed
> > on dev-list.
> >
> > Please, feel free to contribute appropriate content to this wiki
> > section. It would be great to have pages about project setup, best
> > coding practices for developers, etc.
> >
> > 1. https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3
> > 2.
> > https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide
> >

[DISCUSSION] Apache Ignite Extension Release Process Improvements

[Maxim Muzafarov]

Hello Igniters,


We have a lot of Ignite extensions waiting to be released (e.g. aws,
gce, topology-validator, ignite-spring-tx-ext etc.). I think it is a
good point in time to make some kind of automation and simplify our
release process for Ignite extension modules removing manual steps
from it.


During the investigation I've found some issues that we have:

1. Ignite extensions have their own parent pom file [2]. The code and
dependency versions are fully duplicated with the Ignite parent pom
[1], however, these properties must be shared for Ignite Extension
project. Take a look at the :
- master Apache Ignite: 9.4.39.v20210325
- master Apache Ignite Extensions: 9.4.11.v20180605

2. The checkstyle configuration between these two repositories are
different [3] [4]. Each of Apache Ignite and Apache Ignite Extensions
projects have their own checkstyle config file, however, it must be
shared the same as the maven checkstyle profile.

3. The Extensions have a dependency on the latest Apache Ignite
version in the master branch (e.g. 2.13-SNAPSHOT), but without
deploying it in the local repository the Extension projects can be
built. It seems the latest version should be published to the maven
snapshots repository [5].

4. log4j-test.xml, tests.properties these files from the ignite-core
module required to run tests and it seems they should be shared
between projects also as tests resources.

5. The apache-release profile [7] from the apache parent which will
prepare the sources, checksums, gpg sign is not used in the release
process at all.


Here are my suggestions to fix all the issues mentioned above:

1. Create the `ignite-parent` module that will be released each time
with the latest release version. This module will be based on the
parent/pom.xml [1]. This will allow us to share all common
configurations, profiles, dependency versions and properties to the
Ignite Extensions.

2. Create the `ignite-plugin-bom` bill of materials [8] module with
the common Ignite dependencies required for developing a new
extension. This is a common practice for companies that have their own
parent pom file and can't inherit from Ignite's one (e.g.
spring-boot-bom example [9] with all spring dependencies).

3. Create the additional `ignite-resources` jar file to share
checkstyle configuration, resources, tests resources and etc. for the
Extension project.

4. Configure Travis [10] to deploy a new snapshot version to the
apache maven snapshots repository [5] each time the Ignite master
branch is updated.

5. Clean up the pom.xml Extensions file from profiles and dependencies
that are not required to release extensions e.g. the release profile
[11].

6. Reuse the `apache-release` profile for preparing sources of the
extensions during the release.


WDYT?


[1] https://github.com/apache/ignite/blob/master/parent/pom.xml#L35
[2] https://github.com/apache/ignite-extensions/blob/master/parent/pom.xml#L36
[3] 
https://github.com/apache/ignite-extensions/blob/master/checkstyle/checkstyle.xml
[4] https://github.com/apache/ignite/blob/master/checkstyle/checkstyle.xml
[5] https://repository.apache.org/content/repositories/snapshots
[6] 
https://github.com/apache/ignite-extensions/tree/master/modules/aws-ext/modules/core/src/test/config
[7] https://github.com/apache/maven-apache-parent/blob/apache-24/pom.xml#L375
[8] 
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms
[9] https://github.com/snowdrop/spring-boot-bom/blob/sb-2.5.x/pom.xml#L31
[10] https://blog.travis-ci.com/2017-03-30-deploy-maven-travis-ci-packagecloud/
[11] https://github.com/apache/ignite-extensions/blob/master/pom.xml#L242

[ANNOUNCE] Welcome Pavel Pereslegin as a new committer

[Maxim Muzafarov]

The Project Management Committee (PMC) for Apache Ignite has invited
Pavel Pereslegin to become a committer and we are pleased to announce that
he has accepted.

He made a lot of major contributions to the Apache Ignite codebase
like a snapshot restore procedure, batch update operation to the
PageMemory, TDE cache key rotation procedure, Service context
injection and etc.

Being a committer enables easier contribution to the project since there is
no need to go via the patch submission process. This should enable better
productivity.

Please join me in welcoming Pavel, and congratulating him on the new role in
the Apache Ignite Community.


Best Regards,
Maxim Muzafarov

Re: Apache Ignite 2.13 RELEASE [Time, Scope, Manager]

[Maxim Muzafarov]

Nikita,

Thank you for starting this thread.
+1 for these dates, but I think it's better to start the code freeze
date when the Calcite engine will be actually merged to the master
branch.

On Tue, 8 Feb 2022 at 13:10, Nikita Amelchev  wrote:
>
> Dear Ignite Community!
>
> I suggest starting Apache Ignite 2.13 release activities.
>
> There is a plan to merge the new Calcite SQL engine. [1] I think that
> 2.13 is a good candidate for it.
>
> Moreover, we've accumulated a hundred resolved [2] issues with new
> features and bug fixes which are waiting for their release date. For
> example,
>
> BinaryArray introduced,
> Read Repair strategies implemented,
> CPP Thin: asynchronous network events handling,
> NUMA-aware allocator for data regions
> etc.
>
> I want to propose myself to be the release manager of the planning release.
>
> I propose the following timeline:
>
> Scope Freeze: February 21, 2022
> Code Freeze: March 7, 2022
> Voting Date: March 21, 2022
> Release Date: March 28, 2022
>
> WDYT?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-15436
> [2] 
> https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.13%27))%20AND%20(component%20is%20EMPTY%20OR%20component%20not%20in%20(documentation))%20and%20status%20in%20(%27CLOSED%27%2C%20%27RESOLVED%27)%20ORDER%20BY%20priority
>
> --
> Best wishes,
> Amelchev Nikita

Re: [DISCUSSION] Redis and memcached protocol support.

[Maxim Muzafarov]

Hello,

>From my point of view, it's better to reduce the scope of features to
be supported and focus on those ones that a really important for
production e.g. Calcite for Ignite 2.x. However, talking in terms of
open-source development it's better to find a volunteer who will fix
all the issues you describe.

On Tue, 8 Feb 2022 at 14:27, Ivan Daschinsky  wrote:
>
> Igniters, I'd like to discuss the future of this functionality in Apache
> Ignite
>
> Today this functionality seems to be unusable
> 1. It is limited (especially redis)
> 2. It doesn't support HA (redis sentinel or redis cluster)
> 3. Nobody maintains it and even nobody fixes bugs. (i.e. [1] is not merged
> for years).
>
> If we want to support redis protocol, we should rewrite it and add HA
> features.
> Otherwise, I suppose that we should consider complete removal of this code
> from codebase.
>
> WDYT?
>
>
> [1] -- https://issues.apache.org/jira/browse/IGNITE-7153

Re: Move Azure, AWS, GCE to the ignite-extensions

[Maxim Muzafarov]

Hello Stephen,

I'm planning to release the extensions soon. Tests are OK, however,
some TC Suites still need to be configured.

On Wed, 26 Jan 2022 at 21:07, Stephen Darlington
 wrote:
>
> Do we know what happened with this thread? I just saw a question in the user 
> list asking about where the ignite-aws-ext module is now that Ignite 2.12 is 
> out.
>
> Regards,
> Stephen
>
> > On 24 Nov 2021, at 11:11, Maxim Muzafarov  wrote:
> >
> > Petr,
> >
> > There is only the GCE suite left to be configured. I've created an
> > issue [1] to do this. Please, take a look.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-15981
> >
> > On Wed, 24 Nov 2021 at 12:00, Petr Ivanov  wrote:
> >>
> >> Hi, Maksim.
> >>
> >>
> >> Can you file a ticket about recreating test suites for extensions, please?
> >> I will attend to it in nearest time.
> >>
> >>
> >>> On 23 Nov 2021, at 17:14, Maxim Muzafarov  wrote:
> >>>
> >>> Hello Petr,
> >>>
> >>> Can you assist me with configuring the GCE [1] suite on the TC
> >>> Extensions project? Currently, I have an issue with moving environment
> >>> variables from the old GCE suite [2] to the new one.
> >>>
> >>> I need to create the following envs:
> >>> - env.test.gce.account.id
> >>> - env.test.gce.p12.path
> >>> - env.test.gce.project.name
> >>>
> >>> However the `id` seems to be a password, so it's hidden on the admin
> >>> panel. Can you please help me with this?
> >>>
> >>> [1] 
> >>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteExtensions_Tests_Gce_IgniteExtensions_Tests=%3Cdefault%3E=buildTypeStatusDiv
> >>> [2] 
> >>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_GceOld_IgniteTests24Java8=ignite-2.12=buildTypeStatusDiv
> >>>
> >>> On Mon, 25 Oct 2021 at 14:22, Maxim Muzafarov  wrote:
> >>>>
> >>>> Folks,
> >>>>
> >>>> I've moved the azure, gce, aws modules to the ignite-extensions project.
> >>>> https://issues.apache.org/jira/browse/IGNITE-15541
> >>>>
> >>>> Building the modules in the ignite-extension project will prepare an
> >>>> appropriate release zip file containing all the necessary
> >>>> dependencies:
> >>>> - ignite-aws-ext.zip
> >>>> - ignite-gce-ext.zip
> >>>> - ignite-auzre-ext.zip
> >>>>
> >>>>
> >>>> On Wed, 13 Oct 2021 at 17:09, Stephen Darlington
> >>>>  wrote:
> >>>>>
> >>>>> Okay, I phrased that badly. I mean an extra platform-specific ZIP file 
> >>>>> that I used to augment the generic Ignite ZIP file.
> >>>>>
> >>>>> So, to run on Azure I’d download ignite.zip + azure.zip.
> >>>>>
> >>>>> Extending ignite.sh would also be great, kind of like what’s happening 
> >>>>> with Ignite 3 as far as I can tell.
> >>>>>
> >>>>> What I’m advocating is not needing to use Maven just to run Ignite on 
> >>>>> Azure, AWS, etc.
> >>>>>
> >>>>>> On 13 Oct 2021, at 14:35, Petr Ivanov  wrote:
> >>>>>>
> >>>>>> Our self-contained zip file currently is over 400Mb and continues to 
> >>>>>> grow.
> >>>>>> Even considering that internet speeds has grown too, it is nonsense to 
> >>>>>> force user to download such an archive where 90% are useless for most 
> >>>>>> cases.
> >>>>>>
> >>>>>> Also we can:
> >>>>>> — pack all extensions in single binary with latests releases (and 
> >>>>>> update after each extension release) or even one by one
> >>>>>> — extend ignite.sh to download remote libs when extension is activated 
> >>>>>> via command line
> >>>>>>
> >>>>>>
> >>>>>> Antoine de Saint-Exupéry once said that 'perfection is achieved, not 
> >>>>>> when there is nothing more to add, but when there is nothing left to 
> >>>>>> take away'.
> >>>>>> We are not obliged to make Apache Ignite ideal, but we certainly can 
> >>>>>> move that way — I am sure 

Re: [VOTE] Release Apache Ignite 2.12.0 RC2

[Maxim Muzafarov]

+1

On Tue, 11 Jan 2022 at 11:31, Nikolay Izhikov  wrote:
>
> +1
>
> > 11 янв. 2022 г., в 02:38, Vladimir Steshin  написал(а):
> >
> > +1
> >
> > 10.01.2022 15:52, Nikita Amelchev пишет:
> >> Dear Community,
> >>
> >> The release candidate (2.12.0-rc2) is ready.
> >>
> >> I have uploaded a release candidate to:
> >> https://dist.apache.org/repos/dist/dev/ignite/2.12.0-rc2/
> >> https://dist.apache.org/repos/dist/dev/ignite/packages_2.12.0-rc2/
> >>
> >> The following staging can be used for testing:
> >> https://repository.apache.org/content/repositories/orgapacheignite-1539
> >>
> >> Tag name is 2.12.0-rc2:
> >> https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=refs/tags/2.12.0-rc2
> >>
> >> RELEASE_NOTES:
> >> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.12
> >>
> >> Complete list of resolved issues:
> >> https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.12%27))%20and%20status%20in%20(%27CLOSED%27%2C%20%27RESOLVED%27)%20ORDER%20BY%20priority
> >>
> >> DEVNOTES:
> >> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=ignite-2.12
> >>
> >> Additional checks have been performed (available for users included
> >> into the release group on TeamCity).
> >>
> >> TC [Check RC: Licenses, compile, chksum]
> >> https://ci2.ignite.apache.org/buildConfiguration/ignite2_Release_ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum/6266150?showRootCauses=false=true
> >>
> >> TC [2] Compare w/ Previous Release
> >> https://ci2.ignite.apache.org/buildConfiguration/ignite2_Release_ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency/6266148?showRootCauses=false=true
> >>
> >> The vote is formal, see voting guidelines
> >> https://www.apache.org/foundation/voting.html
> >>
> >> +1 - to accept Apache Ignite 2.12.0-rc2
> >> 0 - don't care either way
> >> -1 - DO NOT accept Apache Ignite Ignite 2.12.0-rc2 (explain why)
> >>
> >> See notes on how to verify release here
> >> https://www.apache.org/info/verification.html
> >> and
> >> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
> >>
> >> This vote will be open until Thu Jan 13, 2022, 16:00 UTC. Please,
> >> write me down the thread if you need additional time to check the
> >> release.
> >> https://www.timeanddate.com/countdown/vote?iso=20220113T16=0=VOTE+on+the+Apache+Ignite+Release+2.12.0+RC2=sanserif
> >>
>

[ANNOUNCE] Apache Ignite 2.11.1 Released

[Maxim Muzafarov]

The Apache Ignite Community is pleased to announce the release of
Apache Ignite 2.11.1.

Apache Ignite® is a Distributed Database For High-Performance
Computing With In-Memory Speed.
https://ignite.apache.org


This is an emergency release that fixes the log4j2 dependencies.
Please check the details and the risk mitigation information here:
https://blogs.apache.org/ignite/entry/apache-ignite-2-11-1

The full list of changes you can find in the RELEASE_NOTES:
https://ignite.apache.org/releases/2.11.1/release_notes.html

Download the latest Ignite version from here:
https://ignite.apache.org/download.cgi


Please let us know if you encounter any problems:
https://ignite.apache.org/community/resources.html#ask


Regards,
Maxim Muzafarov on behalf of the Apache Ignite community.

Re: [RESULT] [VOTE] Release Apache Ignite 2.11.1 RC2

[Maxim Muzafarov]

Erlan,

> Lastly, would you please change version 2.11 to 2.11.1 for the button from 
> the header?
> https://github.com/apache/ignite-website/blob/master/_src/_components/header.pug

Can we also use the 'latest' file [1] version to pick up it instead of
manual updating the page 'header.pug' each time? Should we file an
issue for that?

[1] https://github.com/apache/ignite-website/blob/master/latest

On Tue, 21 Dec 2021 at 16:32, Ivan Daschinsky  wrote:
>
> May be just add instruction how to build site using docker? As for ignite
> documentation?
>
> вт, 21 дек. 2021 г. в 16:10, Maxim Muzafarov :
>
> > Folks,
> >
> > Thank you for helping me. Sorry for the 'spam' from my side :-)
> >
> >
> > I've reinstalled Node.js. The following version was installed 'Node.js
> > v17.x' using this guide [1].
> > Now the error is the following:
> >
> > mario@mario:~/IdeaProjects/ignite-website$ gulp
> > SyntaxError: Unexpected token ':'
> > at ESMLoader.moduleStrategy
> > (node:internal/modules/esm/translators:115:18)
> > at ESMLoader.moduleProvider (node:internal/modules/esm/loader:289:14)
> > at async link (node:internal/modules/esm/module_job:70:21)
> >
> >
> > [1]
> > https://github.com/nodesource/distributions/blob/master/README.md#installation-instructions
> >
> > On Tue, 21 Dec 2021 at 16:04, Denis Magda  wrote:
> > >
> > > Erlan, thanks for stepping in. Could you please update the instruction
> > once
> > > Maxim succeeds with all the steps on his end? It's important that
> > community
> > > members such as Maxim know exactly how to work with the new website.
> > >
> > https://cwiki.apache.org/confluence/display/IGNITE/Website+Development#WebsiteDevelopment-SettingUp
> > >
> > > On Tue, Dec 21, 2021 at 8:01 AM Erlan Aytpaev  wrote:
> > >
> > > > Hi Maxim,
> > > >
> > > > What version of node js version did you use?
> > > >
> > > > On Tue, Dec 21, 2021 at 6:47 PM Maxim Muzafarov 
> > wrote:
> > > >
> > > >> Folks,
> > > >>
> > > >>
> > > >> Building the website becomes more and more complicated :-)
> > > >> Can we update the documentation [1] with more details for the folks
> > > >> who are not familiar with node.js?
> > > >>
> > > >> Actually, I'm stuck on the error below with compiling the project.
> > > >> However, it seems to me that node.js require ES modules that are being
> > > >> missed by my installation. Can anyone assist with this?
> > > >>
> > > >>
> > > >> mario@mario:~/IdeaProjects/ignite-website$ gulp
> > > >> /home/mmuzaf/IdeaProjects/ignite-website/gulpfile.js:1
> > > >> import browserSync from 'browser-sync';
> > > >>^^^
> > > >>
> > > >> SyntaxError: Unexpected identifier
> > > >> at Module._compile (internal/modules/cjs/loader.js:723:23)
> > > >> at Object.Module._extensions..js
> > > >> (internal/modules/cjs/loader.js:789:10)
> > > >> at Module.load (internal/modules/cjs/loader.js:653:32)
> > > >> at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
> > > >> at Function.Module._load (internal/modules/cjs/loader.js:585:3)
> > > >> at Module.require (internal/modules/cjs/loader.js:692:17)
> > > >> at require (internal/modules/cjs/helpers.js:25:18)
> > > >> at requireOrImport
> > > >>
> > > >>
> > (/usr/local/lib/node_modules/gulp-cli/lib/shared/require-or-import.js:19:11)
> > > >> at execute
> > > >>
> > (/usr/local/lib/node_modules/gulp-cli/lib/versioned/^4.0.0/index.js:37:3)
> > > >> at Liftoff.handleArguments
> > > >> (/usr/local/lib/node_modules/gulp-cli/index.js:211:24)
> > > >>
> > > >>
> > > >>
> > > >> [1]
> > > >>
> > https://cwiki.apache.org/confluence/display/IGNITE/Website+Development#WebsiteDevelopment-SettingUp
> > > >>
> > > >> On Tue, 21 Dec 2021 at 15:40, Denis Magda  wrote:
> > > >> >
> > > >> > Ops, yes, seems that we messed up with the releases dates. It
> > > >> originates from the PUG files like this one:
> > > >> >
> > > >>
> > https://github.com/apache/ignite-website/blob/master/_src/_comp

Re: [RESULT] [VOTE] Release Apache Ignite 2.11.1 RC2

[Maxim Muzafarov]

Folks,

Thank you for helping me. Sorry for the 'spam' from my side :-)


I've reinstalled Node.js. The following version was installed 'Node.js
v17.x' using this guide [1].
Now the error is the following:

mario@mario:~/IdeaProjects/ignite-website$ gulp
SyntaxError: Unexpected token ':'
at ESMLoader.moduleStrategy (node:internal/modules/esm/translators:115:18)
at ESMLoader.moduleProvider (node:internal/modules/esm/loader:289:14)
at async link (node:internal/modules/esm/module_job:70:21)


[1] 
https://github.com/nodesource/distributions/blob/master/README.md#installation-instructions

On Tue, 21 Dec 2021 at 16:04, Denis Magda  wrote:
>
> Erlan, thanks for stepping in. Could you please update the instruction once
> Maxim succeeds with all the steps on his end? It's important that community
> members such as Maxim know exactly how to work with the new website.
> https://cwiki.apache.org/confluence/display/IGNITE/Website+Development#WebsiteDevelopment-SettingUp
>
> On Tue, Dec 21, 2021 at 8:01 AM Erlan Aytpaev  wrote:
>
> > Hi Maxim,
> >
> > What version of node js version did you use?
> >
> > On Tue, Dec 21, 2021 at 6:47 PM Maxim Muzafarov  wrote:
> >
> >> Folks,
> >>
> >>
> >> Building the website becomes more and more complicated :-)
> >> Can we update the documentation [1] with more details for the folks
> >> who are not familiar with node.js?
> >>
> >> Actually, I'm stuck on the error below with compiling the project.
> >> However, it seems to me that node.js require ES modules that are being
> >> missed by my installation. Can anyone assist with this?
> >>
> >>
> >> mario@mario:~/IdeaProjects/ignite-website$ gulp
> >> /home/mmuzaf/IdeaProjects/ignite-website/gulpfile.js:1
> >> import browserSync from 'browser-sync';
> >>^^^
> >>
> >> SyntaxError: Unexpected identifier
> >> at Module._compile (internal/modules/cjs/loader.js:723:23)
> >> at Object.Module._extensions..js
> >> (internal/modules/cjs/loader.js:789:10)
> >> at Module.load (internal/modules/cjs/loader.js:653:32)
> >> at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
> >> at Function.Module._load (internal/modules/cjs/loader.js:585:3)
> >> at Module.require (internal/modules/cjs/loader.js:692:17)
> >> at require (internal/modules/cjs/helpers.js:25:18)
> >> at requireOrImport
> >>
> >> (/usr/local/lib/node_modules/gulp-cli/lib/shared/require-or-import.js:19:11)
> >> at execute
> >> (/usr/local/lib/node_modules/gulp-cli/lib/versioned/^4.0.0/index.js:37:3)
> >> at Liftoff.handleArguments
> >> (/usr/local/lib/node_modules/gulp-cli/index.js:211:24)
> >>
> >>
> >>
> >> [1]
> >> https://cwiki.apache.org/confluence/display/IGNITE/Website+Development#WebsiteDevelopment-SettingUp
> >>
> >> On Tue, 21 Dec 2021 at 15:40, Denis Magda  wrote:
> >> >
> >> > Ops, yes, seems that we messed up with the releases dates. It
> >> originates from the PUG files like this one:
> >> >
> >> https://github.com/apache/ignite-website/blob/master/_src/_components/download-binary.pug
> >> >
> >> > Would you be able to correct the dates? We can find the dates in a
> >> previous version of download.html:
> >> >
> >> https://github.com/apache/ignite-website/blob/d45ad6211cd34e9a9c94726a6e61babe9c1d5fb8/download.html
> >> >
> >> > Lastly, would you please change version 2.11 to 2.11.1 for the button
> >> from the header?
> >> >
> >> https://github.com/apache/ignite-website/blob/master/_src/_components/header.pug
> >> >
> >> > --
> >> > Denis
> >> >
> >> > On Tue, Dec 21, 2021 at 7:06 AM Maxim Muzafarov 
> >> wrote:
> >> >>
> >> >> Denis,
> >> >>
> >> >> Thanks for the update.
> >> >> I've just recently found that all releases on the download page [1]
> >> >> have the same release date. Is it correct?
> >> >>
> >> >> [1] https://ignite.apache.org/download.cgi
> >> >>
> >> >> On Tue, 21 Dec 2021 at 14:47, Denis Magda  wrote:
> >> >> >
> >> >> > Hi Maxim,
> >> >> >
> >> >> > Just a reminder that since the release of the new website, we need
> >> to update the download.pug [1] file in case of a release and then generate
> >> the HTML

Re: [RESULT] [VOTE] Release Apache Ignite 2.11.1 RC2

[Maxim Muzafarov]

Folks,


Building the website becomes more and more complicated :-)
Can we update the documentation [1] with more details for the folks
who are not familiar with node.js?

Actually, I'm stuck on the error below with compiling the project.
However, it seems to me that node.js require ES modules that are being
missed by my installation. Can anyone assist with this?


mario@mario:~/IdeaProjects/ignite-website$ gulp
/home/mmuzaf/IdeaProjects/ignite-website/gulpfile.js:1
import browserSync from 'browser-sync';
   ^^^

SyntaxError: Unexpected identifier
at Module._compile (internal/modules/cjs/loader.js:723:23)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Module.require (internal/modules/cjs/loader.js:692:17)
at require (internal/modules/cjs/helpers.js:25:18)
at requireOrImport
(/usr/local/lib/node_modules/gulp-cli/lib/shared/require-or-import.js:19:11)
at execute 
(/usr/local/lib/node_modules/gulp-cli/lib/versioned/^4.0.0/index.js:37:3)
at Liftoff.handleArguments
(/usr/local/lib/node_modules/gulp-cli/index.js:211:24)



[1] 
https://cwiki.apache.org/confluence/display/IGNITE/Website+Development#WebsiteDevelopment-SettingUp

On Tue, 21 Dec 2021 at 15:40, Denis Magda  wrote:
>
> Ops, yes, seems that we messed up with the releases dates. It originates from 
> the PUG files like this one:
> https://github.com/apache/ignite-website/blob/master/_src/_components/download-binary.pug
>
> Would you be able to correct the dates? We can find the dates in a previous 
> version of download.html:
> https://github.com/apache/ignite-website/blob/d45ad6211cd34e9a9c94726a6e61babe9c1d5fb8/download.html
>
> Lastly, would you please change version 2.11 to 2.11.1 for the button from 
> the header?
> https://github.com/apache/ignite-website/blob/master/_src/_components/header.pug
>
> --
> Denis
>
> On Tue, Dec 21, 2021 at 7:06 AM Maxim Muzafarov  wrote:
>>
>> Denis,
>>
>> Thanks for the update.
>> I've just recently found that all releases on the download page [1]
>> have the same release date. Is it correct?
>>
>> [1] https://ignite.apache.org/download.cgi
>>
>> On Tue, 21 Dec 2021 at 14:47, Denis Magda  wrote:
>> >
>> > Hi Maxim,
>> >
>> > Just a reminder that since the release of the new website, we need to 
>> > update the download.pug [1] file in case of a release and then generate 
>> > the HTML version following this updated instruction. If you have any 
>> > questions, please reach out to Erlan (CC-ed).
>> >
>> > [1] https://github.com/apache/ignite-website/blob/master/_src/download.pug
>> > [2] https://cwiki.apache.org/confluence/display/IGNITE/Website+Development
>> >
>> > On Tue, Dec 21, 2021 at 4:36 AM Maxim Muzafarov  wrote:
>> >>
>> >> Hello, Igniters!
>> >>
>> >>
>> >> Thanks to everyone. The vote is closed.
>> >> The emergency Apache Ignite 2.11.1 release (RC2) has been accepted.
>> >> I will continue on with the release.
>> >>
>> >> 5 - "+1" votes received and no "0", "-1" votes.
>> >>
>> >>
>> >> Here are the votes received:
>> >>
>> >> - Ilya Kasnacheev (binding)
>> >> - Pavel Tupitsyn (binding)
>> >> - Ivan Daschinsky
>> >> - Nikolay Izhikov (binding)
>> >> - Vyacheslav Koptilin
>> >> - Alex Plehanov (binding)
>> >> - Valentin Kulichenko (binding)
>> >>
>> >>
>> >> Here is the link to the voting thread:
>> >> https://lists.apache.org/thread/2pwc0fv0pczhnxbyfkdhl1m3yvh8vrpb
>> >>
>> >> Thank you!

Re: [RESULT] [VOTE] Release Apache Ignite 2.11.1 RC2

[Maxim Muzafarov]

Denis,

Thanks for the update.
I've just recently found that all releases on the download page [1]
have the same release date. Is it correct?

[1] https://ignite.apache.org/download.cgi

On Tue, 21 Dec 2021 at 14:47, Denis Magda  wrote:
>
> Hi Maxim,
>
> Just a reminder that since the release of the new website, we need to update 
> the download.pug [1] file in case of a release and then generate the HTML 
> version following this updated instruction. If you have any questions, please 
> reach out to Erlan (CC-ed).
>
> [1] https://github.com/apache/ignite-website/blob/master/_src/download.pug
> [2] https://cwiki.apache.org/confluence/display/IGNITE/Website+Development
>
> On Tue, Dec 21, 2021 at 4:36 AM Maxim Muzafarov  wrote:
>>
>> Hello, Igniters!
>>
>>
>> Thanks to everyone. The vote is closed.
>> The emergency Apache Ignite 2.11.1 release (RC2) has been accepted.
>> I will continue on with the release.
>>
>> 5 - "+1" votes received and no "0", "-1" votes.
>>
>>
>> Here are the votes received:
>>
>> - Ilya Kasnacheev (binding)
>> - Pavel Tupitsyn (binding)
>> - Ivan Daschinsky
>> - Nikolay Izhikov (binding)
>> - Vyacheslav Koptilin
>> - Alex Plehanov (binding)
>> - Valentin Kulichenko (binding)
>>
>>
>> Here is the link to the voting thread:
>> https://lists.apache.org/thread/2pwc0fv0pczhnxbyfkdhl1m3yvh8vrpb
>>
>> Thank you!

[RESULT] [VOTE] Release Apache Ignite 2.11.1 RC2

[Maxim Muzafarov]

Hello, Igniters!


Thanks to everyone. The vote is closed.
The emergency Apache Ignite 2.11.1 release (RC2) has been accepted.
I will continue on with the release.

5 - "+1" votes received and no "0", "-1" votes.


Here are the votes received:

- Ilya Kasnacheev (binding)
- Pavel Tupitsyn (binding)
- Ivan Daschinsky
- Nikolay Izhikov (binding)
- Vyacheslav Koptilin
- Alex Plehanov (binding)
- Valentin Kulichenko (binding)


Here is the link to the voting thread:
https://lists.apache.org/thread/2pwc0fv0pczhnxbyfkdhl1m3yvh8vrpb

Thank you!

Re: 0-day CVE in log4j

[Maxim Muzafarov]

Vishwas Bm,


I've found the same for the Zookeeper IP finder module.
It seems to me that it must be fixed also.

[1] https://github.com/apache/ignite/blob/master/modules/zookeeper/pom.xml#L114

On Mon, 20 Dec 2021 at 13:39, Vishwas Bm  wrote:
>
> Correct url to rest-http module
>
> https://github.com/apache/ignite/blob/21f7ca41c4348909e2fd26ccf59b5b2ce1f4474e/modules/rest-http/pom.xml#L131
>
> On Mon, 20 Dec, 2021, 16:06 Vishwas Bm,  wrote:
>
> > Hi,
> >
> > Why is ignite rest module still using old log4j version dependency?
> >
> >
> > https://github.com/apache/ignite/blob/21f7ca41c4348909e2fd26ccf59b5b2ce1f4474e/modules/log4j/pom.xml#L46
> >
> > Can this be removed ? There is a critical CVE against this package.
> >
> > Regards,
> > Vishwas
> >
> >
> > On Wed, 15 Dec, 2021, 12:57 Aleksandr Nikolaev, 
> > wrote:
> >
> >> Hi folks,
> >>
> >> Ok i'm update log4j version 2.15 to 2.16
> >>
> >> https://issues.apache.org/jira/browse/IGNITE-16127
> >>
> >>
> >> On 15.12.2021 09:54, Pavel Tupitsyn wrote:
> >> > Igniters,
> >> >
> >> > Looks like we need to update to 2.16, there is an additional attack
> >> vector
> >> > [1]
> >> >
> >> > [1]
> >> >
> >> https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/
> >> >
> >> > On Mon, Dec 13, 2021 at 4:06 PM Maxim Muzafarov 
> >> wrote:
> >> >
> >> >> Folks,
> >> >>
> >> >> Should we describe all the WA available for the issue [1]? There is
> >> >> already a lot of information about CVE, and nevertheless, it will not
> >> >> be superfluous.
> >> >>
> >> >> [1] https://issues.apache.org/jira/browse/IGNITE-16101
> >> >>
> >> >> On Mon, 13 Dec 2021 at 15:37, Ivan Daschinsky 
> >> wrote:
> >> >>> Unfortunately, we need patch our Log4j2 adapter in order to work with
> >> >>> log4j-2.15
> >> >>> So there is no choice other than to release 2.11.1
> >> >>>
> >> >>> пн, 13 дек. 2021 г. в 15:21, Anton Vinogradov :
> >> >>>
> >> >>>> Folks,
> >> >>>>
> >> >>>> My 200 rubles here,
> >> >>>>> I want to include it to the 2.12 scope.
> >> >>>> Why not 2.11.1 as well?
> >> >>>> We should provide a fixed version for current customers asap.
> >> >>>> 2.12 require migration, while 2.11.1 can be applied as-is.
> >> >>>>
> >> >>>>
> >> >>>> On Mon, Dec 13, 2021 at 12:18 PM Stephen Darlington <
> >> >>>> stephen.darling...@gridgain.com> wrote:
> >> >>>>
> >> >>>>> Another workaround appears to be using the
> >> >>>>> -Dlog4j2.formatMsgNoLookups=true option. Also, “Java versions
> >> greater
> >> >>>> than
> >> >>>>> 6u211, 7u201, 8u191, and 11.0.1 are less affected by this attack
> >> >> vector,
> >> >>>> at
> >> >>>>> least in theory, because the JNDI can't load remote code using
> >> LDAP.”
> >> >>>>>
> >> >>>>> (
> >> >>>>>
> >> >>
> >> https://arstechnica.com/information-technology/2021/12/minecraft-and-other-apps-face-serious-threat-from-new-code-execution-bug/
> >> >>>>> )
> >> >>>>>
> >> >>>>>> On 12 Dec 2021, at 10:56, Dmitriy Pavlov 
> >> >> wrote:
> >> >>>>>> Hi Igniters,
> >> >>>>>>
> >> >>>>>> Preliminary: change of the log4j version does not affect any tests
> >> >>>>>> (Alexander Nikolaev, correct me if I'm wrong).
> >> >>>>>>
> >> >>>>>> If you're using embedded Ignite, it's perfectly possible to enforce
> >> >>>>> jog4j2
> >> >>>>>> dependency to be 2.15.0 in your project final pom.xml or
> >> >> build.gradle
> >> >>>> or
> >> >>>>>> any other build system properties.
> >> >>>>>>
> >> >>>>>> https://issues.apache.org/jira/browse/IGNITE-16101 tick

[VOTE] Release Apache Ignite 2.11.1 RC2

[Maxim Muzafarov]

The second release candidate for the 2.11.1 version is ready.

Since this is an emergency release the vote will remain open for as
short an amount as time as required to vet the release. All votes are
welcome and we encourage everyone to test the release, but only PMC
votes are “officially” counted. As always, at least 3 +1 votes and
more positive than negative votes are required. See voting guidelines:
https://www.apache.org/foundation/voting.html

+1 - to accept Apache Ignite 2.11.1-rc2
0 - don't care either way
-1 - DO NOT accept Apache Ignite Ignite 2.11.1-rc2 (explain why)


* RELEASE CANDADATE *

Check the release difference between 2.11 and 2.11.1:
https://github.com/apache/ignite/compare/ignite-2.11...ignite-2.11.1

I have uploaded a release candidate to:
https://dist.apache.org/repos/dist/dev/ignite/2.11.1-rc2/
https://dist.apache.org/repos/dist/dev/ignite/packages_2.11.1-rc2/

The following staging can be used for testing:
https://repository.apache.org/content/repositories/orgapacheignite-1535/
https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite

The tag name is 2.11.1-rc2:
https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=eae1147dd1cd625cc229098489be8d208f6cabcc

RELEASE_NOTES:
https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.11.1

Complete list of resolved issues:

https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.11.1%27))


* CHECKS *

Additional checks have been performed (available for users included into
the release group on TeamCity).

TC [Check RC: Licenses, compile, chksum]
https://ci.ignite.apache.org/viewLog.html?buildId=6333527=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages

See notes on how to verify release here
https://www.apache.org/info/verification.html
and
https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification

[CANCEL] [VOTE] Release Apache Ignite 2.11.1 RC1

[Maxim Muzafarov]

Cancelling the vote.

I'll cherry-pick the following [1] to the release branch and prepare a
new RC today.

[1] https://issues.apache.org/jira/browse/IGNITE-16153

Re: Apache Ignite 2.11.1 RELEASE [Time, Scope, Manager]

[Maxim Muzafarov]

Ivan,

I suppose the next 2.11.2 version should be released. Currently, from
my point of view, it's a bit strange releasing 2.11.1 with a known
CVE. It doesn't take too much time to prepare a new RC.


Folks,

I've merged to the master branch the issue [1] which upgrades
dependency to 2.17.0 and here are two suggestions:
1. Cherry-pick the issue [1] to the 2.11.1 and 2.12 branches.
2. Prepare a new RC and send it for a vote with a little clarification
- do not keep the vote for 3 days and accept an RC when the +3 binding
votes and no vetos will be received from the community the same way as
the log4j community does [2].

WDYT?

[1] https://issues.apache.org/jira/browse/IGNITE-16153
[2] https://lists.apache.org/thread/w7kob4v6f3wm63g5j48wvcbj7l9y343q

On Sat, 18 Dec 2021 at 19:31, Ivan Daschinsky  wrote:
>
> Haha, it becomes funny :) What if another vulnerability will be discovered
> a few days later?
>
> сб, 18 дек. 2021 г. в 18:04, Maxim Muzafarov :
>
> > Folks,
> >
> >
> > I've found that LOG4J2 2.17.0 version is released [1]. According to
> > the description and risk mitigation [2] it is recommended the version
> > update. Since the release has not happened yet I think it is possible
> > to update the dependency in the 2.11.1 release too.
> >
> >
> > WDYT?
> >
> >
> > [1] https://issues.apache.org/jira/browse/LOG4J2-3230
> > [2] https://logging.apache.org/log4j/2.x/security.html
> >
> > On Fri, 17 Dec 2021 at 14:20, Petr Ivanov  wrote:
> > >
> > > I've dropped GitBox in favour of GitHub — the build [1] has started.
> > >
> > >
> > > [1]
> > https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/6329862
> > >
> > > > On 17 Dec 2021, at 13:24, Maxim Muzafarov  wrote:
> > > >
> > > > Petr,
> > > >
> > > > Thank you.
> > > >
> > > > Yes, I've added changes related to the new release build actions
> > > > (IGNITE-15678, IGNITE-15677). The ignite-2.12 branch seems to be
> > > > working fine, however, at the ignite-2.11.1 the error with "too many
> > > > requests" appears from time to time. Here is an example of such a
> > > > build [1].
> > > >
> > > >
> > > > [1]
> > https://ci.ignite.apache.org/viewLog.html?buildId=6329858=Releases_ApacheIgniteMain_ReleaseBuild
> > > >
> > > > On Fri, 17 Dec 2021 at 13:20, Petr Ivanov  wrote:
> > > >>
> > > >> Concerning Too many requests error, I see the following problem:
> > > >>
> > > >>
> > > >> Your request has been rate limited, as we have detected excessive
> > usage from your IP or net block:
> > > >> 15.575 SECONDS OF TIME SPENT OVER 120 SECONDS, MAX ALLOWED IS 15.
> > > >> Rate-limits are automatic and reset every two minutes.
> > > >> If you feel this is in error, please contact the Apache
> > Infrastructure Team at: us...@infra.apache.org.
> > > >>
> > > >>
> > > >> Can someone check with them about it, please?
> > > >>
> > > >>> On 17 Dec 2021, at 13:14, Petr Ivanov  wrote:
> > > >>>
> > > >>> Permissions updated.
> > > >>>
> > > >>>
> > > >>>> On 17 Dec 2021, at 13:09, Petr Ivanov  wrote:
> > > >>>>
> > > >>>> Could you please add links to builds that are malfunctioning?
> > > >>>> As much as I see here [1] and here [2] — the release build changed
> > to comply with 2.12 changes that are not merged to 2.11.1
> > > >>>>
> > > >>>>
> > > >>>> [1]
> > https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/6329822
> > > >>>> [2]
> > https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/6329824
> > > >>>>
> > > >>>>> On 17 Dec 2021, at 12:11, Maxim Muzafarov 
> > wrote:
> > > >>>>>
> > > >>>>> Hello Petr,
> > > >>>>>
> > > >>>>> Can you please assist with configuring the Release Teamcity suite
> > that
> > > >>>>> has been changed for 2.x a month ago? These changes haven't been
> > > >>>>> discussed on the dev-list, so I'm not familiar with them.
> > > >>>>>
> > >

Re: Apache Ignite 2.11.1 RELEASE [Time, Scope, Manager]

[Maxim Muzafarov]

Folks,


I've found that LOG4J2 2.17.0 version is released [1]. According to
the description and risk mitigation [2] it is recommended the version
update. Since the release has not happened yet I think it is possible
to update the dependency in the 2.11.1 release too.


WDYT?


[1] https://issues.apache.org/jira/browse/LOG4J2-3230
[2] https://logging.apache.org/log4j/2.x/security.html

On Fri, 17 Dec 2021 at 14:20, Petr Ivanov  wrote:
>
> I've dropped GitBox in favour of GitHub — the build [1] has started.
>
>
> [1] 
> https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/6329862
>
> > On 17 Dec 2021, at 13:24, Maxim Muzafarov  wrote:
> >
> > Petr,
> >
> > Thank you.
> >
> > Yes, I've added changes related to the new release build actions
> > (IGNITE-15678, IGNITE-15677). The ignite-2.12 branch seems to be
> > working fine, however, at the ignite-2.11.1 the error with "too many
> > requests" appears from time to time. Here is an example of such a
> > build [1].
> >
> >
> > [1] 
> > https://ci.ignite.apache.org/viewLog.html?buildId=6329858=Releases_ApacheIgniteMain_ReleaseBuild
> >
> > On Fri, 17 Dec 2021 at 13:20, Petr Ivanov  wrote:
> >>
> >> Concerning Too many requests error, I see the following problem:
> >>
> >>
> >> Your request has been rate limited, as we have detected excessive usage 
> >> from your IP or net block:
> >> 15.575 SECONDS OF TIME SPENT OVER 120 SECONDS, MAX ALLOWED IS 15.
> >> Rate-limits are automatic and reset every two minutes.
> >> If you feel this is in error, please contact the Apache Infrastructure 
> >> Team at: us...@infra.apache.org.
> >>
> >>
> >> Can someone check with them about it, please?
> >>
> >>> On 17 Dec 2021, at 13:14, Petr Ivanov  wrote:
> >>>
> >>> Permissions updated.
> >>>
> >>>
> >>>> On 17 Dec 2021, at 13:09, Petr Ivanov  wrote:
> >>>>
> >>>> Could you please add links to builds that are malfunctioning?
> >>>> As much as I see here [1] and here [2] — the release build changed to 
> >>>> comply with 2.12 changes that are not merged to 2.11.1
> >>>>
> >>>>
> >>>> [1] 
> >>>> https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/6329822
> >>>> [2] 
> >>>> https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/6329824
> >>>>
> >>>>> On 17 Dec 2021, at 12:11, Maxim Muzafarov  wrote:
> >>>>>
> >>>>> Hello Petr,
> >>>>>
> >>>>> Can you please assist with configuring the Release Teamcity suite that
> >>>>> has been changed for 2.x a month ago? These changes haven't been
> >>>>> discussed on the dev-list, so I'm not familiar with them.
> >>>>>
> >>>>> I've faced several issues:
> >>>>> - the default role for Apache Ignite 2.x (Release) suite is `Agent
> >>>>> manager`, however, it seems the right value is `Project developer and
> >>>>> queue manager`. I've looked through the documentation pages and
> >>>>> doesn't get an idea of how it can be changed.
> >>>>> - there was an issue with the Releases_ApacheIgniteMain_GitBoxIgnite
> >>>>> that throws `429 too many requests` exception each time a new list of
> >>>>> branches is fetched. I've changed the poll interval to 180 sec
> >>>>> (default value 60 sec), however, this change doesn't look good from my
> >>>>> side. What should I do here?
> >>>>>
> >>>>> On Thu, 16 Dec 2021 at 22:09, Вячеслав Коптилин
> >>>>>  wrote:
> >>>>>>
> >>>>>> Hi Maxim,
> >>>>>>
> >>>>>> Thanks a lot!
> >>>>>>
> >>>>>>> Check the following links below.
> >>>>>> Looks good to me.
> >>>>>>
> >>>>>>
> >>>>>> чт, 16 дек. 2021 г. в 20:19, Maxim Muzafarov :
> >>>>>>
> >>>>>>> Folks,
> >>>>>>>
> >>>>>>>
> >>>>>>> I'm OK with this. Let's go through the fastest way we have.
> >>>>>>>
> >>>>>>>
> >>>>>>&g

Re: [VOTE] Release Apache Ignite 2.11.1 RC1

[Maxim Muzafarov]

Slava,

The release build scripts have been changed [1]. It's not possible to
build 2.11 from scratch. Since we are going the fastest route (and
safest I suppose) it's better to cherry-pick these changes to the
release rather than changing something on TC.

[1] https://issues.apache.org/jira/browse/IGNITE-15693

On Fri, 17 Dec 2021 at 16:28, Вячеслав Коптилин
 wrote:
>
> Hello Maxim,
>
> Honestly, I don't quite understand why ODBC improvement is included in the
> release.
> It seems to me, we have an agreement that the scope of the 2.11.1 release
> will be limited by log4j issues.
>
> Thanks,
> S.
>
>
> пт, 17 дек. 2021 г. в 15:20, Maxim Muzafarov :
>
> > The release candidate for the 2.11.1 version is ready.
> >
> >
> > I have uploaded a release candidate to:
> > https://dist.apache.org/repos/dist/dev/ignite/2.11.1-rc1/
> > https://dist.apache.org/repos/dist/dev/ignite/packages_2.11.1-rc1/
> >
> > The following staging can be used for testing:
> > https://repository.apache.org/content/repositories/orgapacheignite-1534/
> >
> > https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite
> >
> > The tag name is 2.11.1-rc1:
> >
> > https://gitbox.apache.org/repos/asf?p=ignite.git;a=tag;h=refs/tags/2.11.1-rc1
> >
> > RELEASE_NOTES:
> >
> > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.11.1
> >
> >
> > Complete list of resolved issues:
> >
> > Update Ignite dependency log4j
> > https://issues.apache.org/jira/browse/IGNITE-16127
> > https://issues.apache.org/jira/browse/IGNITE-16101
> >
> > CPP: Build ODBC installers using cmake
> > https://issues.apache.org/jira/browse/IGNITE-15678
> >
> > ODBC: DSN can not be created by DataSource manager
> > https://issues.apache.org/jira/browse/IGNITE-15677
> >
> >
> > Additional checks have been performed (available for users included into
> > the release group on TeamCity).
> >
> > TC [Check RC: Licenses, compile, chksum]
> >
> > https://ci2.ignite.apache.org/viewLog.html?buildId=6235446=buildResultsDiv=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum
> >
> >
> > The vote is formal, see voting guidelines
> > https://www.apache.org/foundation/voting.html
> >
> > +1 - to accept Apache Ignite 2.11.1-rc1
> > 0 - don't care either way
> > -1 - DO NOT accept Apache Ignite Ignite 2.11.1-rc1 (explain why)
> >
> > See notes on how to verify release here
> > https://www.apache.org/info/verification.html
> > and
> >
> > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
> >
> >
> > This vote will be open for 3 days until Mon Dec 20, 15:00 2021 (Moscow
> > time).
> > Please, write me down the thread if you need additional time to check
> > the release.
> >
> > https://www.timeanddate.com/countdown/vote?iso=20211220T15=166=%5BVOTE%5D+Apache+Ignite+2.11.1=sanserif
> >

[VOTE] Release Apache Ignite 2.11.1 RC1

[Maxim Muzafarov]

The release candidate for the 2.11.1 version is ready.


I have uploaded a release candidate to:
https://dist.apache.org/repos/dist/dev/ignite/2.11.1-rc1/
https://dist.apache.org/repos/dist/dev/ignite/packages_2.11.1-rc1/

The following staging can be used for testing:
https://repository.apache.org/content/repositories/orgapacheignite-1534/
https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite

The tag name is 2.11.1-rc1:
https://gitbox.apache.org/repos/asf?p=ignite.git;a=tag;h=refs/tags/2.11.1-rc1

RELEASE_NOTES:
https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.11.1


Complete list of resolved issues:

Update Ignite dependency log4j
https://issues.apache.org/jira/browse/IGNITE-16127
https://issues.apache.org/jira/browse/IGNITE-16101

CPP: Build ODBC installers using cmake
https://issues.apache.org/jira/browse/IGNITE-15678

ODBC: DSN can not be created by DataSource manager
https://issues.apache.org/jira/browse/IGNITE-15677


Additional checks have been performed (available for users included into
the release group on TeamCity).

TC [Check RC: Licenses, compile, chksum]
https://ci2.ignite.apache.org/viewLog.html?buildId=6235446=buildResultsDiv=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum


The vote is formal, see voting guidelines
https://www.apache.org/foundation/voting.html

+1 - to accept Apache Ignite 2.11.1-rc1
0 - don't care either way
-1 - DO NOT accept Apache Ignite Ignite 2.11.1-rc1 (explain why)

See notes on how to verify release here
https://www.apache.org/info/verification.html
and
https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification


This vote will be open for 3 days until Mon Dec 20, 15:00 2021 (Moscow time).
Please, write me down the thread if you need additional time to check
the release.
https://www.timeanddate.com/countdown/vote?iso=20211220T15=166=%5BVOTE%5D+Apache+Ignite+2.11.1=sanserif

Re: Apache Ignite 2.11.1 RELEASE [Time, Scope, Manager]

[Maxim Muzafarov]

Petr,

Thank you.

Yes, I've added changes related to the new release build actions
(IGNITE-15678, IGNITE-15677). The ignite-2.12 branch seems to be
working fine, however, at the ignite-2.11.1 the error with "too many
requests" appears from time to time. Here is an example of such a
build [1].


[1] 
https://ci.ignite.apache.org/viewLog.html?buildId=6329858=Releases_ApacheIgniteMain_ReleaseBuild

On Fri, 17 Dec 2021 at 13:20, Petr Ivanov  wrote:
>
> Concerning Too many requests error, I see the following problem:
>
>
> Your request has been rate limited, as we have detected excessive usage from 
> your IP or net block:
> 15.575 SECONDS OF TIME SPENT OVER 120 SECONDS, MAX ALLOWED IS 15.
> Rate-limits are automatic and reset every two minutes.
> If you feel this is in error, please contact the Apache Infrastructure Team 
> at: us...@infra.apache.org.
>
>
> Can someone check with them about it, please?
>
> > On 17 Dec 2021, at 13:14, Petr Ivanov  wrote:
> >
> > Permissions updated.
> >
> >
> >> On 17 Dec 2021, at 13:09, Petr Ivanov  wrote:
> >>
> >> Could you please add links to builds that are malfunctioning?
> >> As much as I see here [1] and here [2] — the release build changed to 
> >> comply with 2.12 changes that are not merged to 2.11.1
> >>
> >>
> >> [1] 
> >> https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/6329822
> >> [2] 
> >> https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/6329824
> >>
> >>> On 17 Dec 2021, at 12:11, Maxim Muzafarov  wrote:
> >>>
> >>> Hello Petr,
> >>>
> >>> Can you please assist with configuring the Release Teamcity suite that
> >>> has been changed for 2.x a month ago? These changes haven't been
> >>> discussed on the dev-list, so I'm not familiar with them.
> >>>
> >>> I've faced several issues:
> >>> - the default role for Apache Ignite 2.x (Release) suite is `Agent
> >>> manager`, however, it seems the right value is `Project developer and
> >>> queue manager`. I've looked through the documentation pages and
> >>> doesn't get an idea of how it can be changed.
> >>> - there was an issue with the Releases_ApacheIgniteMain_GitBoxIgnite
> >>> that throws `429 too many requests` exception each time a new list of
> >>> branches is fetched. I've changed the poll interval to 180 sec
> >>> (default value 60 sec), however, this change doesn't look good from my
> >>> side. What should I do here?
> >>>
> >>> On Thu, 16 Dec 2021 at 22:09, Вячеслав Коптилин
> >>>  wrote:
> >>>>
> >>>> Hi Maxim,
> >>>>
> >>>> Thanks a lot!
> >>>>
> >>>>> Check the following links below.
> >>>> Looks good to me.
> >>>>
> >>>>
> >>>> чт, 16 дек. 2021 г. в 20:19, Maxim Muzafarov :
> >>>>
> >>>>> Folks,
> >>>>>
> >>>>>
> >>>>> I'm OK with this. Let's go through the fastest way we have.
> >>>>>
> >>>>>
> >>>>> Check the following links below. I'll prepare the vote shortly.
> >>>>>
> >>>>> Compare branches 2.11 and 2.11.1:
> >>>>> https://github.com/apache/ignite/compare/ignite-2.11...ignite-2.11.1
> >>>>>
> >>>>> The release branch:
> >>>>> https://github.com/apache/ignite/tree/ignite-2.11.1
> >>>>>
> >>>>> JIRA 2.11.1 version:
> >>>>>
> >>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.11.1
> >>>>>
> >>>>> Release notes:
> >>>>> https://github.com/apache/ignite/blob/ignite-2.11.1/RELEASE_NOTES.txt
> >>>>>
> >>>>> On Thu, 16 Dec 2021 at 19:30, Ilya Kasnacheev 
> >>>>> 
> >>>>> wrote:
> >>>>>>
> >>>>>> Hello!
> >>>>>>
> >>>>>> I also agree with Stephen. If we wanted to do a stabilization release 
> >>>>>> we
> >>>>>> should unbound it from this urgent fix.
> >>>>>>
> >>>>>> I wonder why 2.12 is not with us already, given that it was scheduled 
> >>>>>> to
> >>>

Re: Apache Ignite 2.11.1 RELEASE [Time, Scope, Manager]

[Maxim Muzafarov]

Hello Petr,

Can you please assist with configuring the Release Teamcity suite that
has been changed for 2.x a month ago? These changes haven't been
discussed on the dev-list, so I'm not familiar with them.

I've faced several issues:
- the default role for Apache Ignite 2.x (Release) suite is `Agent
manager`, however, it seems the right value is `Project developer and
queue manager`. I've looked through the documentation pages and
doesn't get an idea of how it can be changed.
- there was an issue with the Releases_ApacheIgniteMain_GitBoxIgnite
that throws `429 too many requests` exception each time a new list of
branches is fetched. I've changed the poll interval to 180 sec
(default value 60 sec), however, this change doesn't look good from my
side. What should I do here?

On Thu, 16 Dec 2021 at 22:09, Вячеслав Коптилин
 wrote:
>
> Hi Maxim,
>
> Thanks a lot!
>
> > Check the following links below.
> Looks good to me.
>
>
> чт, 16 дек. 2021 г. в 20:19, Maxim Muzafarov :
>
> > Folks,
> >
> >
> > I'm OK with this. Let's go through the fastest way we have.
> >
> >
> > Check the following links below. I'll prepare the vote shortly.
> >
> > Compare branches 2.11 and 2.11.1:
> > https://github.com/apache/ignite/compare/ignite-2.11...ignite-2.11.1
> >
> > The release branch:
> > https://github.com/apache/ignite/tree/ignite-2.11.1
> >
> > JIRA 2.11.1 version:
> >
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.11.1
> >
> > Release notes:
> > https://github.com/apache/ignite/blob/ignite-2.11.1/RELEASE_NOTES.txt
> >
> > On Thu, 16 Dec 2021 at 19:30, Ilya Kasnacheev 
> > wrote:
> > >
> > > Hello!
> > >
> > > I also agree with Stephen. If we wanted to do a stabilization release we
> > > should unbound it from this urgent fix.
> > >
> > > I wonder why 2.12 is not with us already, given that it was scheduled to
> > go
> > > out in August.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > чт, 16 дек. 2021 г. в 19:25, Вячеслав Коптилин  > >:
> > >
> > > > Hello,
> > > >
> > > > > Given that 2.12 is so close, my preference would be to limit the
> > scope of
> > > > 2.11.1 to just the log4j update.
> > > > I agree with Stephen. Apache Ignite 2.11.1 is an emergency release.
> > Using
> > > > log4j 2.16 instead of 2.14 is a quite small change that only requires a
> > > > "sanity" check and can be quickly released. A wider release scope
> > requires
> > > > full testing, IMHO.
> > > >
> > > > Thanks,
> > > > S.
> > > >
> > > >
> > > > чт, 16 дек. 2021 г. в 16:03, Maxim Muzafarov :
> > > >
> > > > > I think it is completely possible to move vote/release dates
> > > > > significantly forward with keeping the scope. I will take a look at
> > > > > the list of fixed bugs more narrowly and exclude some of them that
> > > > > require additional verification.
> > > > >
> > > > > On Thu, 16 Dec 2021 at 15:55, Stephen Darlington
> > > > >  wrote:
> > > > > >
> > > > > > Given that 2.12 is so close, my preference would be to limit the
> > scope
> > > > > of 2.11.1 to just the log4j update. Would that help bring the
> > > > vote/release
> > > > > date forward?
> > > > > >
> > > > > > > On 16 Dec 2021, at 12:44, Maxim Muzafarov 
> > wrote:
> > > > > > >
> > > > > > > Dear Ignite Community!
> > > > > > >
> > > > > > > I suggest preparing the Apache Ignite 2.11.1 release and I want
> > to
> > > > > > > propose myself to be the release manager of the minor release.
> > > > > > >
> > > > > > >
> > > > > > > * RELEASE TIMELINE *
> > > > > > >
> > > > > > > Scope Freeze: December 16, 2021
> > > > > > > Code Freeze: December 16, 2021
> > > > > > > Voting Date: December 21, 2021
> > > > > > > Release Date: December 24, 2021
> > > > > > >
> > > > > > >
> > > > > > > * RELEASE SCOPE *
> > > > > > >
> > > > > > > LOG4J dependency update

Re: Apache Ignite 2.11.1 RELEASE [Time, Scope, Manager]

[Maxim Muzafarov]

Folks,


I'm OK with this. Let's go through the fastest way we have.


Check the following links below. I'll prepare the vote shortly.

Compare branches 2.11 and 2.11.1:
https://github.com/apache/ignite/compare/ignite-2.11...ignite-2.11.1

The release branch:
https://github.com/apache/ignite/tree/ignite-2.11.1

JIRA 2.11.1 version:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.11.1

Release notes:
https://github.com/apache/ignite/blob/ignite-2.11.1/RELEASE_NOTES.txt

On Thu, 16 Dec 2021 at 19:30, Ilya Kasnacheev  wrote:
>
> Hello!
>
> I also agree with Stephen. If we wanted to do a stabilization release we
> should unbound it from this urgent fix.
>
> I wonder why 2.12 is not with us already, given that it was scheduled to go
> out in August.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 16 дек. 2021 г. в 19:25, Вячеслав Коптилин :
>
> > Hello,
> >
> > > Given that 2.12 is so close, my preference would be to limit the scope of
> > 2.11.1 to just the log4j update.
> > I agree with Stephen. Apache Ignite 2.11.1 is an emergency release. Using
> > log4j 2.16 instead of 2.14 is a quite small change that only requires a
> > "sanity" check and can be quickly released. A wider release scope requires
> > full testing, IMHO.
> >
> > Thanks,
> > S.
> >
> >
> > чт, 16 дек. 2021 г. в 16:03, Maxim Muzafarov :
> >
> > > I think it is completely possible to move vote/release dates
> > > significantly forward with keeping the scope. I will take a look at
> > > the list of fixed bugs more narrowly and exclude some of them that
> > > require additional verification.
> > >
> > > On Thu, 16 Dec 2021 at 15:55, Stephen Darlington
> > >  wrote:
> > > >
> > > > Given that 2.12 is so close, my preference would be to limit the scope
> > > of 2.11.1 to just the log4j update. Would that help bring the
> > vote/release
> > > date forward?
> > > >
> > > > > On 16 Dec 2021, at 12:44, Maxim Muzafarov  wrote:
> > > > >
> > > > > Dear Ignite Community!
> > > > >
> > > > > I suggest preparing the Apache Ignite 2.11.1 release and I want to
> > > > > propose myself to be the release manager of the minor release.
> > > > >
> > > > >
> > > > > * RELEASE TIMELINE *
> > > > >
> > > > > Scope Freeze: December 16, 2021
> > > > > Code Freeze: December 16, 2021
> > > > > Voting Date: December 21, 2021
> > > > > Release Date: December 24, 2021
> > > > >
> > > > >
> > > > > * RELEASE SCOPE *
> > > > >
> > > > > LOG4J dependency update
> > > > > https://issues.apache.org/jira/browse/IGNITE-16101
> > > > > https://issues.apache.org/jira/browse/IGNITE-16127
> > > > >
> > > > > B+Tree Corrupted exception when using a key extracted from a
> > > BinaryObject
> > > > > https://issues.apache.org/jira/browse/IGNITE-12911
> > > > >
> > > > > Regression: Ignite node crash(CorruptedTreeException: B+Tree is
> > > corrupted)
> > > > > https://issues.apache.org/jira/browse/IGNITE-15943
> > > > >
> > > > > .NET: ClientFailoverSocket sets logger too late, resulting in null
> > > > > loggers downstream
> > > > > https://issues.apache.org/jira/browse/IGNITE-14776
> > > > >
> > > > > The iterator of the ClientCacheQueryCursor can be closed during
> > > serialization.
> > > > > https://issues.apache.org/jira/browse/IGNITE-15346
> > > > >
> > > > > Possible owners desync when a node is restarted while rebalancing
> > with
> > > > > enabled persistence
> > > > > https://issues.apache.org/jira/browse/IGNITE-15315
> > > > >
> > > > > Thin client: Tx can fail if there are concurrent tx rollbacks by
> > > timeout
> > > > > https://issues.apache.org/jira/browse/IGNITE-15732
> > > > >
> > > > > AssertionError: Unexpected rebalance on rebalanced cluster
> > > > > https://issues.apache.org/jira/browse/IGNITE-15033
> > > > >
> > > > > JmxMetricExporterSpi throws assertion error on a filtered metric
> > > unregister
> > > > > https://issues.apache.org/jira/browse/IGNITE-15252
> > > > >
> > > > > ClassNotFoundException on an attempt to invoke service method from
> > > > > Java ThinClient after a cluster failover
> > > > > https://issues.apache.org/jira/browse/IGNITE-15256
> > > > >
> > > > > NullPointerException on an attempt to create a Java ThinClient with
> > > > > BinaryConfiguration
> > > > > https://issues.apache.org/jira/browse/IGNITE-15138
> > > > >
> > > > > Java thin client: Type name is not cached on client-side for
> > > > > OptimizerMarshaller types
> > > > > https://issues.apache.org/jira/browse/IGNITE-15924
> > > > >
> > > > > select count * returns multiple rows
> > > > > https://issues.apache.org/jira/browse/IGNITE-14120
> > > > >
> > > > > Fix StackOverflowError in case if an exception is suppressed with
> > > itself
> > > > > https://issues.apache.org/jira/browse/IGNITE-15716
> > > > >
> > > > >
> > > > > WDYT?
> > > >
> > > >
> > >
> >

Re: Apache Ignite 2.11.1 RELEASE [Time, Scope, Manager]

[Maxim Muzafarov]

I think it is completely possible to move vote/release dates
significantly forward with keeping the scope. I will take a look at
the list of fixed bugs more narrowly and exclude some of them that
require additional verification.

On Thu, 16 Dec 2021 at 15:55, Stephen Darlington
 wrote:
>
> Given that 2.12 is so close, my preference would be to limit the scope of 
> 2.11.1 to just the log4j update. Would that help bring the vote/release date 
> forward?
>
> > On 16 Dec 2021, at 12:44, Maxim Muzafarov  wrote:
> >
> > Dear Ignite Community!
> >
> > I suggest preparing the Apache Ignite 2.11.1 release and I want to
> > propose myself to be the release manager of the minor release.
> >
> >
> > * RELEASE TIMELINE *
> >
> > Scope Freeze: December 16, 2021
> > Code Freeze: December 16, 2021
> > Voting Date: December 21, 2021
> > Release Date: December 24, 2021
> >
> >
> > * RELEASE SCOPE *
> >
> > LOG4J dependency update
> > https://issues.apache.org/jira/browse/IGNITE-16101
> > https://issues.apache.org/jira/browse/IGNITE-16127
> >
> > B+Tree Corrupted exception when using a key extracted from a BinaryObject
> > https://issues.apache.org/jira/browse/IGNITE-12911
> >
> > Regression: Ignite node crash(CorruptedTreeException: B+Tree is corrupted)
> > https://issues.apache.org/jira/browse/IGNITE-15943
> >
> > .NET: ClientFailoverSocket sets logger too late, resulting in null
> > loggers downstream
> > https://issues.apache.org/jira/browse/IGNITE-14776
> >
> > The iterator of the ClientCacheQueryCursor can be closed during 
> > serialization.
> > https://issues.apache.org/jira/browse/IGNITE-15346
> >
> > Possible owners desync when a node is restarted while rebalancing with
> > enabled persistence
> > https://issues.apache.org/jira/browse/IGNITE-15315
> >
> > Thin client: Tx can fail if there are concurrent tx rollbacks by timeout
> > https://issues.apache.org/jira/browse/IGNITE-15732
> >
> > AssertionError: Unexpected rebalance on rebalanced cluster
> > https://issues.apache.org/jira/browse/IGNITE-15033
> >
> > JmxMetricExporterSpi throws assertion error on a filtered metric unregister
> > https://issues.apache.org/jira/browse/IGNITE-15252
> >
> > ClassNotFoundException on an attempt to invoke service method from
> > Java ThinClient after a cluster failover
> > https://issues.apache.org/jira/browse/IGNITE-15256
> >
> > NullPointerException on an attempt to create a Java ThinClient with
> > BinaryConfiguration
> > https://issues.apache.org/jira/browse/IGNITE-15138
> >
> > Java thin client: Type name is not cached on client-side for
> > OptimizerMarshaller types
> > https://issues.apache.org/jira/browse/IGNITE-15924
> >
> > select count * returns multiple rows
> > https://issues.apache.org/jira/browse/IGNITE-14120
> >
> > Fix StackOverflowError in case if an exception is suppressed with itself
> > https://issues.apache.org/jira/browse/IGNITE-15716
> >
> >
> > WDYT?
>
>

Re: Apache Ignite 2.11.1 RELEASE [Time, Scope, Manager]

[Maxim Muzafarov]

Folks,

This is also a good candidate to include in the proposed release.

AssertionError in B+Tree under load
https://issues.apache.org/jira/browse/IGNITE-15990

On Thu, 16 Dec 2021 at 15:54, Pavel Tupitsyn  wrote:
>
> Maxim,
>
> Thanks for taking this, scope looks good to me.
> I think we can even start the vote today or tomorrow, given the severity of
> log4j issue.
>
> Pavel
>
> On Thu, Dec 16, 2021 at 3:44 PM Maxim Muzafarov  wrote:
>
> > Dear Ignite Community!
> >
> > I suggest preparing the Apache Ignite 2.11.1 release and I want to
> > propose myself to be the release manager of the minor release.
> >
> >
> > * RELEASE TIMELINE *
> >
> > Scope Freeze: December 16, 2021
> > Code Freeze: December 16, 2021
> > Voting Date: December 21, 2021
> > Release Date: December 24, 2021
> >
> >
> > * RELEASE SCOPE *
> >
> > LOG4J dependency update
> > https://issues.apache.org/jira/browse/IGNITE-16101
> > https://issues.apache.org/jira/browse/IGNITE-16127
> >
> > B+Tree Corrupted exception when using a key extracted from a BinaryObject
> > https://issues.apache.org/jira/browse/IGNITE-12911
> >
> > Regression: Ignite node crash(CorruptedTreeException: B+Tree is corrupted)
> > https://issues.apache.org/jira/browse/IGNITE-15943
> >
> > .NET: ClientFailoverSocket sets logger too late, resulting in null
> > loggers downstream
> > https://issues.apache.org/jira/browse/IGNITE-14776
> >
> > The iterator of the ClientCacheQueryCursor can be closed during
> > serialization.
> > https://issues.apache.org/jira/browse/IGNITE-15346
> >
> > Possible owners desync when a node is restarted while rebalancing with
> > enabled persistence
> > https://issues.apache.org/jira/browse/IGNITE-15315
> >
> > Thin client: Tx can fail if there are concurrent tx rollbacks by timeout
> > https://issues.apache.org/jira/browse/IGNITE-15732
> >
> > AssertionError: Unexpected rebalance on rebalanced cluster
> > https://issues.apache.org/jira/browse/IGNITE-15033
> >
> > JmxMetricExporterSpi throws assertion error on a filtered metric unregister
> > https://issues.apache.org/jira/browse/IGNITE-15252
> >
> > ClassNotFoundException on an attempt to invoke service method from
> > Java ThinClient after a cluster failover
> > https://issues.apache.org/jira/browse/IGNITE-15256
> >
> > NullPointerException on an attempt to create a Java ThinClient with
> > BinaryConfiguration
> > https://issues.apache.org/jira/browse/IGNITE-15138
> >
> > Java thin client: Type name is not cached on client-side for
> > OptimizerMarshaller types
> > https://issues.apache.org/jira/browse/IGNITE-15924
> >
> > select count * returns multiple rows
> > https://issues.apache.org/jira/browse/IGNITE-14120
> >
> > Fix StackOverflowError in case if an exception is suppressed with itself
> > https://issues.apache.org/jira/browse/IGNITE-15716
> >
> >
> > WDYT?
> >

Apache Ignite 2.11.1 RELEASE [Time, Scope, Manager]

[Maxim Muzafarov]

Dear Ignite Community!

I suggest preparing the Apache Ignite 2.11.1 release and I want to
propose myself to be the release manager of the minor release.


* RELEASE TIMELINE *

Scope Freeze: December 16, 2021
Code Freeze: December 16, 2021
Voting Date: December 21, 2021
Release Date: December 24, 2021


* RELEASE SCOPE *

LOG4J dependency update
https://issues.apache.org/jira/browse/IGNITE-16101
https://issues.apache.org/jira/browse/IGNITE-16127

B+Tree Corrupted exception when using a key extracted from a BinaryObject
https://issues.apache.org/jira/browse/IGNITE-12911

Regression: Ignite node crash(CorruptedTreeException: B+Tree is corrupted)
https://issues.apache.org/jira/browse/IGNITE-15943

.NET: ClientFailoverSocket sets logger too late, resulting in null
loggers downstream
https://issues.apache.org/jira/browse/IGNITE-14776

The iterator of the ClientCacheQueryCursor can be closed during serialization.
https://issues.apache.org/jira/browse/IGNITE-15346

Possible owners desync when a node is restarted while rebalancing with
enabled persistence
https://issues.apache.org/jira/browse/IGNITE-15315

Thin client: Tx can fail if there are concurrent tx rollbacks by timeout
https://issues.apache.org/jira/browse/IGNITE-15732

AssertionError: Unexpected rebalance on rebalanced cluster
https://issues.apache.org/jira/browse/IGNITE-15033

JmxMetricExporterSpi throws assertion error on a filtered metric unregister
https://issues.apache.org/jira/browse/IGNITE-15252

ClassNotFoundException on an attempt to invoke service method from
Java ThinClient after a cluster failover
https://issues.apache.org/jira/browse/IGNITE-15256

NullPointerException on an attempt to create a Java ThinClient with
BinaryConfiguration
https://issues.apache.org/jira/browse/IGNITE-15138

Java thin client: Type name is not cached on client-side for
OptimizerMarshaller types
https://issues.apache.org/jira/browse/IGNITE-15924

select count * returns multiple rows
https://issues.apache.org/jira/browse/IGNITE-14120

Fix StackOverflowError in case if an exception is suppressed with itself
https://issues.apache.org/jira/browse/IGNITE-15716


WDYT?

Re: 0-day CVE in log4j

[Maxim Muzafarov]

Folks,

Should we describe all the WA available for the issue [1]? There is
already a lot of information about CVE, and nevertheless, it will not
be superfluous.

[1] https://issues.apache.org/jira/browse/IGNITE-16101

On Mon, 13 Dec 2021 at 15:37, Ivan Daschinsky  wrote:
>
> Unfortunately, we need patch our Log4j2 adapter in order to work with
> log4j-2.15
> So there is no choice other than to release 2.11.1
>
> пн, 13 дек. 2021 г. в 15:21, Anton Vinogradov :
>
> > Folks,
> >
> > My 200 rubles here,
> > > I want to include it to the 2.12 scope.
> > Why not 2.11.1 as well?
> > We should provide a fixed version for current customers asap.
> > 2.12 require migration, while 2.11.1 can be applied as-is.
> >
> >
> > On Mon, Dec 13, 2021 at 12:18 PM Stephen Darlington <
> > stephen.darling...@gridgain.com> wrote:
> >
> > > Another workaround appears to be using the
> > > -Dlog4j2.formatMsgNoLookups=true option. Also, “Java versions greater
> > than
> > > 6u211, 7u201, 8u191, and 11.0.1 are less affected by this attack vector,
> > at
> > > least in theory, because the JNDI can't load remote code using LDAP.”
> > >
> > > (
> > >
> > https://arstechnica.com/information-technology/2021/12/minecraft-and-other-apps-face-serious-threat-from-new-code-execution-bug/
> > > )
> > >
> > > > On 12 Dec 2021, at 10:56, Dmitriy Pavlov  wrote:
> > > >
> > > > Hi Igniters,
> > > >
> > > > Preliminary: change of the log4j version does not affect any tests
> > > > (Alexander Nikolaev, correct me if I'm wrong).
> > > >
> > > > If you're using embedded Ignite, it's perfectly possible to enforce
> > > jog4j2
> > > > dependency to be 2.15.0 in your project final pom.xml or build.gradle
> > or
> > > > any other build system properties.
> > > >
> > > > https://issues.apache.org/jira/browse/IGNITE-16101 ticket seems to be
> > > > a blocker for 2.12. But for now, as a workaround, it's possible to
> > select
> > > > the latest version manually.
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > сб, 11 дек. 2021 г. в 09:47, Nikita Amelchev :
> > > >
> > > >> Hello.
> > > >>
> > > >> The issue to update dependency was created:
> > > >> https://issues.apache.org/jira/browse/IGNITE-16101
> > > >>
> > > >> I want to include it to the 2.12 scope.
> > > >>
> > > >> сб, 11 дек. 2021 г., 09:19 Raymond Wilson  > >:
> > > >>
> > > >>> All
> > > >>>
> > > >>> This blew up today: CVE-2021-44228 (
> > > >>>
> > > >>>
> > > >>
> > >
> > https://www.bleepingcomputer.com/news/security/new-zero-day-exploit-for-log4j-java-library-is-an-enterprise-nightmare/
> > > >>> )
> > > >>>
> > > >>> Will there be a risk assessment with respect to Ignite for this CVE?
> > > >>>
> > > >>> Thanks,
> > > >>> Raymond.
> > > >>>
> > > >>> --
> > > >>> 
> > > >>> Raymond Wilson
> > > >>> Trimble Distinguished Engineer, Civil Construction Software (CCS)
> > > >>> 11 Birmingham Drive | Christchurch, New Zealand
> > > >>> raymond_wil...@trimble.com
> > > >>>
> > > >>> <
> > > >>>
> > > >>
> > >
> > https://worksos.trimble.com/?utm_source=Trimble_medium=emailsign_campaign=Launch
> > > 
> > > >>>
> > > >>
> > >
> > >
> > >
> >
>
>
> --
> Sincerely yours, Ivan Daschinskiy

Re: 0-day CVE in log4j

[Maxim Muzafarov]

+1 for the 2.11.1

On Mon, 13 Dec 2021 at 15:21, Anton Vinogradov  wrote:
>
> Folks,
>
> My 200 rubles here,
> > I want to include it to the 2.12 scope.
> Why not 2.11.1 as well?
> We should provide a fixed version for current customers asap.
> 2.12 require migration, while 2.11.1 can be applied as-is.
>
>
> On Mon, Dec 13, 2021 at 12:18 PM Stephen Darlington <
> stephen.darling...@gridgain.com> wrote:
>
> > Another workaround appears to be using the
> > -Dlog4j2.formatMsgNoLookups=true option. Also, “Java versions greater than
> > 6u211, 7u201, 8u191, and 11.0.1 are less affected by this attack vector, at
> > least in theory, because the JNDI can't load remote code using LDAP.”
> >
> > (
> > https://arstechnica.com/information-technology/2021/12/minecraft-and-other-apps-face-serious-threat-from-new-code-execution-bug/
> > )
> >
> > > On 12 Dec 2021, at 10:56, Dmitriy Pavlov  wrote:
> > >
> > > Hi Igniters,
> > >
> > > Preliminary: change of the log4j version does not affect any tests
> > > (Alexander Nikolaev, correct me if I'm wrong).
> > >
> > > If you're using embedded Ignite, it's perfectly possible to enforce
> > jog4j2
> > > dependency to be 2.15.0 in your project final pom.xml or build.gradle or
> > > any other build system properties.
> > >
> > > https://issues.apache.org/jira/browse/IGNITE-16101 ticket seems to be
> > > a blocker for 2.12. But for now, as a workaround, it's possible to select
> > > the latest version manually.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > сб, 11 дек. 2021 г. в 09:47, Nikita Amelchev :
> > >
> > >> Hello.
> > >>
> > >> The issue to update dependency was created:
> > >> https://issues.apache.org/jira/browse/IGNITE-16101
> > >>
> > >> I want to include it to the 2.12 scope.
> > >>
> > >> сб, 11 дек. 2021 г., 09:19 Raymond Wilson :
> > >>
> > >>> All
> > >>>
> > >>> This blew up today: CVE-2021-44228 (
> > >>>
> > >>>
> > >>
> > https://www.bleepingcomputer.com/news/security/new-zero-day-exploit-for-log4j-java-library-is-an-enterprise-nightmare/
> > >>> )
> > >>>
> > >>> Will there be a risk assessment with respect to Ignite for this CVE?
> > >>>
> > >>> Thanks,
> > >>> Raymond.
> > >>>
> > >>> --
> > >>> 
> > >>> Raymond Wilson
> > >>> Trimble Distinguished Engineer, Civil Construction Software (CCS)
> > >>> 11 Birmingham Drive | Christchurch, New Zealand
> > >>> raymond_wil...@trimble.com
> > >>>
> > >>> <
> > >>>
> > >>
> > https://worksos.trimble.com/?utm_source=Trimble_medium=emailsign_campaign=Launch
> > 
> > >>>
> > >>
> >
> >
> >

Re: [DISCUSSION] Remove outdated ignite-sys-cache

[Maxim Muzafarov]

 for the user. This does
> >>> not
> >>>>>>>> cover the case when the plugin developer wants to hide such cache
> >> and
> >>>>>>>> protect it form the end user (at least, via public api).
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> S.
> >>>>>>>>
> >>>>>>>> пт, 3 дек. 2021 г., 14:15 Nikolay Izhikov :
> >>>>>>>>
> >>>>>>>>> Vyacheslav, Val, can you please clarify - What is the issue if
> >>>>>>> third-party
> >>>>>>>>> plugins will create «ignite-sys-cache» from the code?
> >>>>>>>>>
> >>>>>>>>> Like just replacing `Ignite#cache` with the
> >>> `Ignite#getOrCreateCache`.
> >>>>>>>>>
> >>>>>>>>>> 2 дек. 2021 г., в 16:13, Вячеслав Коптилин <
> >>> slava.kopti...@gmail.com
> >>>>>>
> >>>>>>>>> написал(а):
> >>>>>>>>>>
> >>>>>>>>>> Hello Maxim,
> >>>>>>>>>>
> >>>>>>>>>>> I don't understand why you are using *backwards compatibility*
> >> for
> >>>>>>>>>> completely internal things.
> >>>>>>>>>>> Why you are thinking in terms of users usage when are talking
> >>> about
> >>>>>>>>>> ignite-sys-cache but not thinking when refactoring
> >>>>>>>>>> First of all, we are talking about all plugin developers. It does
> >>> not
> >>>>>>>>>> matter it is open-source or proprietary plugins.
> >>>>>>>>>> Honestly, I don't have a list of all possible plugins that have
> >>>>> already
> >>>>>>>>>> been developed and available under the ASF license, for instance.
> >>>>>>>>>> Do you have such a list? Can you be sure that this change will
> >> not
> >>>>>>> affect
> >>>>>>>>>> anyone?
> >>>>>>>>>>
> >>>>>>>>>>> I don't understand why you are using *backwards compatibility*
> >> for
> >>>>>>>>>> completely internal things.
> >>>>>>>>>>> Why you are thinking in terms of users usage when are talking
> >>> about
> >>>>>>>>>> ignite-sys-cache but not thinking when refactoring
> >>>>>>>>>> The system cache was the crucial thing in the architecture of
> >>> Apache
> >>>>>>>>> Ignite
> >>>>>>>>>> 1.x and 2.x (at least 2.1 - 2.11?)
> >>>>>>>>>>
> >>>>>>>>>>> All the internals have been reworked and nobody even mentioned
> >>> that
> >>>>> it
> >>>>>>>>>> may affect some of the plugin developers.
> >>>>>>>>>> Yep, perhaps, some internal parts of Apache Ignite were reworked
> >> in
> >>>>>>> order
> >>>>>>>>>> to avoid using the system cache.
> >>>>>>>>>> However, it is still a part of Ignite and it works and can be
> >> used
> >>> in
> >>>>>>>>>> plugins.
> >>>>>>>>>> Honestly, the mentioned alternative, I mean the distributed
> >>>>>>> metastorage,
> >>>>>>>>> is
> >>>>>>>>>> the INTERNAL thing as well.
> >>>>>>>>>> It means that plugin developer depends on INTERNAL entities. (it
> >>> does
> >>>>>>> not
> >>>>>>>>>> matter system-cache/metastorage)
> >>>>>>>>>> IMHO, such questions should be CAREFULLY discussed with no rush.
> >>>>>>>>>>
> >>>>>>>>>>> I do not propose to rush with the ignite-sys-cache removal. I'd
> >>> like
> >>>>>>> to
> >>>>>>>>>> collect all the technical stuff that we depend on, fix all of
> >> the

Re: [DISCUSSION][IEP-80] Breaking changes in Ignite-2.x

[Maxim Muzafarov]

Ivan,

It seems shmem is already in the remove list [1].

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist

On Fri, 3 Dec 2021 at 10:42, Ivan Daschinsky  wrote:
>
> So if nobody wants it to resurrect, maybe it is worth removing it?
>
>
> пт, 3 дек. 2021 г. в 09:25, Ivan Pavlukhin :
>
> > Latest that I heard that it literally was never in use.
> >
> > 2021-11-29 19:44 GMT+03:00, Ivan Daschinsky :
> > > There is JNI library in ipc/shmem directory. It even compiles with
> > minimal
> > > modification on modern gcc (9.3.0)
> > > But there is no script to build jar with native library.
> > >
> > > May be it is possible to create separate module, refactor it a bit,
> > change
> > > build process (CMake)?
> > > Is there a technical reason why it is abandoned?
> > >
> > > пн, 29 нояб. 2021 г. в 19:24, Ivan Daschinsky :
> > >
> > >> Guys, what is the status of ignite-shmem and TcpCommunication through
> > it?
> > >>
> > >> 1. Native part has not been built at all since 2015
> > >> 2. It is currently broken in master -- I've fixed some NPE and metrics
> > >> conversion locally and it works for me. It is broken for almost a year.
> > >> 3. GridShmemCommunicationClient is not covered by tests.
> > >>
> > >> What do you think we should do with this?
> > >>
> > >> сб, 27 нояб. 2021 г. в 23:32, Vyacheslav Daradur :
> > >>
> > >>> LGTM. Merged to master.
> > >>>
> > >>> Thank you for your contribution!
> > >>>
> > >>> On Fri, Nov 26, 2021 at 12:20 PM Maxim Muzafarov 
> > >>> wrote:
> > >>>
> > >>> > Folks,
> > >>> >
> > >>> > This is a friendly reminder :-)
> > >>> > PR [1] is ready for review. Will anyone take a look?
> > >>> >
> > >>> > [1] https://github.com/apache/ignite/pull/9577/files
> > >>> >
> > >>> > On Sat, 20 Nov 2021 at 03:17, Maxim Muzafarov 
> > >>> wrote:
> > >>> > >
> > >>> > > Folks,
> > >>> > >
> > >>> > >
> > >>> > > I've prepared the changes related to the legacy Service Grid
> > removal
> > >>> > > for the 2.13 release. Here is the issue [1] and the PR [2] of these
> > >>> > > changes.
> > >>> > >
> > >>> > > Some important notes:
> > >>> > >
> > >>> > > - Removed GridServiceProcessor legacy implementation (internal)
> > >>> > > - The IGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED system property
> > >>> > > was removed (this is a breaking change)
> > >>> > > - The ATTR_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED node attribute
> > was
> > >>> > > removed (this is a breaking change)
> > >>> > > - The node with 2.13 won't be able to connect to 2.12 (assume
> > Ignite
> > >>> > > services are used)
> > >>> > >
> > >>> > > The legacy test suite [3] will be removed after the [1] issue will
> > >>> > > be
> > >>> > merged.
> > >>> > >
> > >>> > >
> > >>> > > Who can take a look at this PR?
> > >>> > >
> > >>> > >
> > >>> > > [1] https://issues.apache.org/jira/browse/IGNITE-15758
> > >>> > > [2] https://github.com/apache/ignite/pull/9577/files
> > >>> > > [3]
> > >>> >
> > >>>
> > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ServiceGridLegacyMode
> > >>> > >
> > >>> > > On Fri, 22 Oct 2021 at 12:43, Nikolay Izhikov  > >
> > >>> > wrote:
> > >>> > > >
> > >>> > > > Hello.
> > >>> > > >
> > >>> > > > In the scope of IEP-80 Breaking changes in Ignite-2.x PR for the
> > >>> > following API are prepared:
> > >>> > > >
> > >>> > > > 1. MVCC
> > >>> > > > - https://issues.apache.org/jira/browse/IGNITE-15757
> > >>> > > > - https://github.com/apache/ignite/pull/9516
> > >>> >

Re: [DISCUSSION] Remove outdated ignite-sys-cache

[Maxim Muzafarov]

Pavel,


I don't understand why you are using *backwards compatibility* for
completely internal things. Why you are thinking in terms of users
usage when are talking about ignite-sys-cache but not thinking when
refactoring, for instance, all the checkpoint classes? Take a look at
the [1] issue. All the internals have been reworked and nobody even
mentioned that it may affect some of the plugin developers. This is
really strange, so I can't agree with you.


I do not propose to rush with the ignite-sys-cache removal. I'd like
to collect all the technical stuff that we depend on, fix all of them
and after everything will be ready do a final removal. Slava already
mentioned some crucial cases, so I hope you and Val also help with the
rest of them. Let's be more precise in terms *what we need to fix*.


I've made some investigations related to the ignite-sys-cache and here
is my proposal:

1. Add deprecation for the 2.12 release. I hope it is still possible.

2. Apache Ignite core still have some dependencies on ignite-sys-cache
that should fix for 2.13:

2.1. CLUSTER_NAME property: when it's not set the `deploymentId` of
system cache is used. Let's move it to metastorage.
2.2. When the Security is enabled each compute task name (hash to be
more precise) is written to the ignite-sys-cache [2]. From my point of
view, we can remove it in 2.13. Can anyone check?
2.3. Slava mentioned some issues with the distributed metastorage that
might be fixed. I think this is doable.

3. Remove the system cache in 2.14.



[1] https://issues.apache.org/jira/browse/IGNITE-13143
[2] 
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/task/GridTaskProcessor.java#L201

On Thu, 2 Dec 2021 at 12:56, Pavel Tupitsyn  wrote:
>
> Maxim,
>
> > I don't think that we should wait for 3-rd party plugins to be updated
> > this is an awful practice when the open-source product releases depend
> > on some of the proprietary plugins
>
> This makes no sense, sorry.
>
> It is not that we depend on 3rd party plugins.
> It is that *our users depend on us to preserve backwards compatibility*.
> No one likes when their app breaks suddenly because of a library update.
>
> We know about one use case for sys-cache in GridGain, but there may be
> more, no one knows.
> Every breaking change should be carried out carefully and gradually.
>
>
> On Thu, Dec 2, 2021 at 12:34 PM Maxim Muzafarov  wrote:
>
> > Slava,
> >
> > Thank you for the comments.
> >
> > > Maxim, the community must provide a reasonable time interval in order to
> > notify all contributors and wait for updating all 3-rd party plugins.
> >
> > This is not actually true. We must notify about changes as earlier as
> > possible and not only users but all the developers also. However, I
> > don't think that we should wait for 3-rd party plugins to be updated
> > this is an awful practice when the open-source product releases depend
> > on some of the proprietary plugins. There is no dependency between
> > Apache Ignite releases and proprietary plugin releases. If someone
> > desires to upgrade to a new version of Apache Ignite it can update its
> > plugins any time he likes.
> >
> > > We just need to provide a window that is enough to cover all related
> > issues.
> >
> > Can you share all the issues you know, please?
> >
> > > distributed meta storage does not provide the ability to atomically
> > change several properties at the same time (there are no transactions on
> > this API).
> >
> > Can you share an example of what kind of properties we intend to
> > change at the same? Will it be enough to change them through a single
> > thread (e.g. the discovery thread or the exchange thread)? I agree
> > here that distributed metastorage should provide such an ability,
> > however, I can't find any real examples for Apache Ignite internal
> > needs. Please, share the details and let's fix it.
> >
> > On Wed, 1 Dec 2021 at 23:19, Valentin Kulichenko
> >  wrote:
> > >
> > > Agree with Slava. Two months is not enough time, especially considering
> > > that the system cache is not functionally equivalent to the metastorage.
> > I
> > > suggest we do the following:
> > >
> > > 1. Write down the differences between the system cache and the
> > metastorage,
> > > and provide a transition guide for plugin developers.
> > > 2. Deprecate the system cache in 2.13.
> > > 3. Remove the system cache in one of the further releases. I don't think
> > > it's reasonable to do this earlier than mid next year (even that is
> > > potentially too early).
> > >
>

Re: [DISCUSSION] Remove outdated ignite-sys-cache

[Maxim Muzafarov]

Slava,

Thank you for the comments.

> Maxim, the community must provide a reasonable time interval in order to 
> notify all contributors and wait for updating all 3-rd party plugins.

This is not actually true. We must notify about changes as earlier as
possible and not only users but all the developers also. However, I
don't think that we should wait for 3-rd party plugins to be updated
this is an awful practice when the open-source product releases depend
on some of the proprietary plugins. There is no dependency between
Apache Ignite releases and proprietary plugin releases. If someone
desires to upgrade to a new version of Apache Ignite it can update its
plugins any time he likes.

> We just need to provide a window that is enough to cover all related issues.

Can you share all the issues you know, please?

> distributed meta storage does not provide the ability to atomically change 
> several properties at the same time (there are no transactions on this API).

Can you share an example of what kind of properties we intend to
change at the same? Will it be enough to change them through a single
thread (e.g. the discovery thread or the exchange thread)? I agree
here that distributed metastorage should provide such an ability,
however, I can't find any real examples for Apache Ignite internal
needs. Please, share the details and let's fix it.

On Wed, 1 Dec 2021 at 23:19, Valentin Kulichenko
 wrote:
>
> Agree with Slava. Two months is not enough time, especially considering
> that the system cache is not functionally equivalent to the metastorage. I
> suggest we do the following:
>
> 1. Write down the differences between the system cache and the metastorage,
> and provide a transition guide for plugin developers.
> 2. Deprecate the system cache in 2.13.
> 3. Remove the system cache in one of the further releases. I don't think
> it's reasonable to do this earlier than mid next year (even that is
> potentially too early).
>
> Removing the system cache is the right move, but let's be more considerate
> to the users. There is absolutely no need to rush.
>
> -Val
>
> On Wed, Dec 1, 2021 at 7:28 AM Вячеслав Коптилин 
> wrote:
>
> > Hi Maxim,
> >
> > > On the other hand, I don't see any valuable reason why the change can't
> > be done and we should wait for the future that never comes.
> > Maxim, the community must provide a reasonable time interval in order to
> > notify all contributors and wait for updating all 3-rd party plugins.
> > Honestly, it does not seem to me that two, three months (the current
> > timeline - end of March is the release date, so the end of Feb is code
> > freeze) are quite enough.
> >
> > > I don't see any reasons why we should keep something in the CORE module
> > that is being used at PLUGINS only. This is a lack of architecture design
> > that must be fixed for sure;
> > I agree with you. We just need to provide a window that is enough to cover
> > all related issues.
> > For example, distributed meta storage does not provide the ability to
> > atomically change several properties at the same time (there are no
> > transactions on this API).
> >
> > Perhaps, it would be nice to plan to remove the system cache on 2.14 or
> > even 2.15. What do you think?
> >
> > Thanks,
> > S.
> >
> >
> > вт, 30 нояб. 2021 г. в 13:58, Maxim Muzafarov :
> >
> > > Hello Val,
> > >
> > > Thank you for sharing the details. On the one hand, I agree with you
> > > that there is no need to haste with this change and it must be
> > > prepared carefully. On the other hand, I don't see any valuable reason
> > > why the change can't be done and we should wait for the future that
> > > never comes.
> > >
> > > Please, consider the following my considerations:
> > >
> > > - The release 2.13 is not started yet. It will take months to be
> > > released (e.g. the end of March as a possible release date). The time
> > > is more than enough;
> > > - The 2.13 release has breaking changes, so it is a good opportunity
> > > to fix some gaps;
> > > - I don't see any reasons why we should keep something in the CORE
> > > module that is being used at PLUGINS only. This is a lack of
> > > architecture design that must be fixed for sure;
> > > - The cache affects cluster stability and require additional human
> > > resources for the code maintenance;
> > > - As a straightforward solution plugins can create their own internal
> > > caches and use them ever they like (or use the metastorage as I
> > > mentioned earlier). Moving system cache to plugin doesn

Re: [DISCUSSION] Remove outdated ignite-sys-cache

[Maxim Muzafarov]

Hello Val,

Thank you for sharing the details. On the one hand, I agree with you
that there is no need to haste with this change and it must be
prepared carefully. On the other hand, I don't see any valuable reason
why the change can't be done and we should wait for the future that
never comes.

Please, consider the following my considerations:

- The release 2.13 is not started yet. It will take months to be
released (e.g. the end of March as a possible release date). The time
is more than enough;
- The 2.13 release has breaking changes, so it is a good opportunity
to fix some gaps;
- I don't see any reasons why we should keep something in the CORE
module that is being used at PLUGINS only. This is a lack of
architecture design that must be fixed for sure;
- The cache affects cluster stability and require additional human
resources for the code maintenance;
- As a straightforward solution plugins can create their own internal
caches and use them ever they like (or use the metastorage as I
mentioned earlier). Moving system cache to plugin doesn't look so
complicated and harmful;

On Mon, 29 Nov 2021 at 23:07, Valentin Kulichenko
 wrote:
>
> Maxim,
>
> You're right that the system cache is still likely to be used by plugins.
> We at GridGain use it for security features, for example. As far as I know,
> that's not the only case.
>
> I also agree that the metastorage should be the preferred way for this kind
> of purposes, but is there any harm in keeping the system cache for now?
> Unlike the legacy Service Grid, this is not a public feature that can be
> used directly by a regular user, so I'm not sure why the rush.
>
> How about we instead deprecate the system cache, clearly document how to
> use the metastorage as an alternative, and then complete the removal
> sometime in the future?
>
> -Val
>
> On Sun, Nov 28, 2021 at 6:49 AM Maxim Muzafarov  wrote:
>
> > Igniters,
> >
> >
> > Since the legacy service grid implementation was removed [2] I'd like
> > to remove the ignite-sys-cache also. It is still possible that some of
> > Ignite plugins (e.g. security plugin) are still using this cache,
> > however, AFAIK this is not the reason to keep the outdated system
> > cache and these plugins must be migrated to the metastorage instead.
> >
> > I've filed the issue [1] for removal. Any objections?
> >
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-16008
> > [2] https://issues.apache.org/jira/browse/IGNITE-15758
> >

[DISCUSSION] Remove outdated ignite-sys-cache

[Maxim Muzafarov]

Igniters,


Since the legacy service grid implementation was removed [2] I'd like
to remove the ignite-sys-cache also. It is still possible that some of
Ignite plugins (e.g. security plugin) are still using this cache,
however, AFAIK this is not the reason to keep the outdated system
cache and these plugins must be migrated to the metastorage instead.

I've filed the issue [1] for removal. Any objections?


[1] https://issues.apache.org/jira/browse/IGNITE-16008
[2] https://issues.apache.org/jira/browse/IGNITE-15758

Re: [DISCUSSION][IEP-80] Breaking changes in Ignite-2.x

[Maxim Muzafarov]

Folks,

This is a friendly reminder :-)
PR [1] is ready for review. Will anyone take a look?

[1] https://github.com/apache/ignite/pull/9577/files

On Sat, 20 Nov 2021 at 03:17, Maxim Muzafarov  wrote:
>
> Folks,
>
>
> I've prepared the changes related to the legacy Service Grid removal
> for the 2.13 release. Here is the issue [1] and the PR [2] of these
> changes.
>
> Some important notes:
>
> - Removed GridServiceProcessor legacy implementation (internal)
> - The IGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED system property
> was removed (this is a breaking change)
> - The ATTR_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED node attribute was
> removed (this is a breaking change)
> - The node with 2.13 won't be able to connect to 2.12 (assume Ignite
> services are used)
>
> The legacy test suite [3] will be removed after the [1] issue will be merged.
>
>
> Who can take a look at this PR?
>
>
> [1] https://issues.apache.org/jira/browse/IGNITE-15758
> [2] https://github.com/apache/ignite/pull/9577/files
> [3] 
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ServiceGridLegacyMode
>
> On Fri, 22 Oct 2021 at 12:43, Nikolay Izhikov  wrote:
> >
> > Hello.
> >
> > In the scope of IEP-80 Breaking changes in Ignite-2.x PR for the following 
> > API are prepared:
> >
> > 1. MVCC
> > - https://issues.apache.org/jira/browse/IGNITE-15757
> > - https://github.com/apache/ignite/pull/9516
> >
> > 2. LOCAL caches
> > - https://issues.apache.org/jira/browse/IGNITE-15756
> > - https://github.com/apache/ignite/pull/9515
> >
> > 3. CacheConfiguration#rebalanceDelay
> > - https://issues.apache.org/jira/browse/IGNITE-15764
> > - https://github.com/apache/ignite/pull/9515
> >
> > Please, review.
> >
> > > 15 окт. 2021 г., в 16:23, Nikolay Izhikov  
> > > написал(а):
> > >
> > > THanks, Maksim.
> > >
> > > Tickets included in IEP scope and marked for d in 2.12-2.13
> > >
> > >> 15 окт. 2021 г., в 16:03, Maxim Muzafarov  написал(а):
> > >>
> > >> Let's deprecate RebalanceDelay and RebalanceMode=NONE also.
> > >>
> > >> [1] https://issues.apache.org/jira/browse/IGNITE-12662
> > >> [2] https://issues.apache.org/jira/browse/IGNITE-14613
> > >>
> > >> On Fri, 15 Oct 2021 at 15:46, Anton Vinogradov  wrote:
> > >>>
> > >>> +1
> > >>>
> > >>> On Fri, Oct 15, 2021 at 3:41 PM Nikita Amelchev 
> > >>> wrote:
> > >>>
> > >>>> +1 for deprecation in the 2.12 release
> > >>>>
> > >>>> пт, 15 окт. 2021 г. в 15:35, Nikolay Izhikov :
> > >>>>>
> > >>>>> Hello, Igniters.
> > >>>>>
> > >>>>> I’ve prepared IEP-80 [1] to track breaking changes that should be done
> > >>>> in Ignite 2.x.
> > >>>>>
> > >>>>> We agreed on the following algorithm to deal with breaking changes:
> > >>>>>
> > >>>>>   - Ignite 2.[x] - deprecate the API + notification of the users.
> > >>>>>   - Ignite 2.[x+1] - API removal.
> > >>>>>
> > >>>>>
> > >>>>> I propose to start these improvements with the d (depuration &
> > >>>> removal) of the following features:
> > >>>>>
> > >>>>>   - LOCAL caches
> > >>>>>   - MVCC caches
> > >>>>>   - legacy service grid implementation
> > >>>>>   - legacy JMX metrics beans.
> > >>>>>
> > >>>>> Deprecation in 2.12
> > >>>>> Removal in 2.13
> > >>>>>
> > >>>>> Please, share your opinion.
> > >>>>>
> > >>>>> [1]
> > >>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191334475
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Best wishes,
> > >>>> Amelchev Nikita
> > >>>>
> > >
> >

[DISCUSSION] [IEP-81] New Cluster Management API (Ignite 2.x)

[Maxim Muzafarov]

Igniters,


I'd like to propose a new internal cluster management API that will
simplify new cluster management commands creation and expose new
commands to CLI, REST, JMX Ignite interfaces without any additional
actions from the engineer adding a new command. This main goal of the
IEP is supposed to be available after the implementation of the 1-st
phase. From my point of view, the implementation will also provide
some additional features like auto ASCII-docs generation which can be
achieved with minor code changes.

Please, take a look at the IEP-81 [1] with a detailed explanation of
my proposal. Below you can find some crucial points from it.


= Current Limitations =

- The same commands through CLI, REST, JMX APIs don't have the same
input arguments and use different subsystems for command execution;
- A new command that is added must be manually exposed to all the
Ignite APIs (new implementation required for each new command being
added);
- New commands can't be added via Ignite Plugins and exposed to API;
- The own binary protocol is used (GridClient) for command executions
instead of the ignite thin client (IgniteClient);
- Security and role model: a user have to add compute tasks
permissions the same time as adding permissions for the process he
intended to use.
- New commands can't be added or executed at runtime


= Crutial Impelemntation Notes =

1. Create a one for all proxy compute task gate that will accept a map
of parameters for preparing management command based on input
parameters and executing it on ignite nodes.
For instance:

IgniteClient.compute().execute(ProxyManagementTask.class.getName(), attrs);

Map:
baseline.add=execute
baseline.add.projection=SINGLE
baseline.add.nodes=[consistendtId3, consistendeId4]

2. Create a CommandRegisty that will contain all available commanded
on the local ignite node. Commands will be added by command scanners
e.g. AnnotationCommandScanner, PackageCommandScanner,
URICommandScanner as well as registered manually at runtime by calling
`add` method on command registry. The CommandRegistry will also be
available for the thin clients in a standalone mode.

3. Prepare a command parsers for REST, JMX, CLI interfaces that will
use command registry and calling the proxy management task right away
with correct task input parameters.

4. Check the API [2] for commands that may be executed only on a
single node (the same as the VisorOneNodeTask) or on all nodes e.g.
collecting some information from each node and reducing it on a
originating node.


[1] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-81+Cluster+Management+API
[2] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-81+Cluster+Management+API#IEP81ClusterManagementAPI-CommandInterface

Re: Moving snapshot tests to their own test suites

[Maxim Muzafarov]

Petr,

For the RunAll - 0.2
For the RunAll(Nightly) - 1.0 (the 1.0 is better that 0.2 for sure)

On Thu, 25 Nov 2021 at 15:54, Petr Ivanov  wrote:
>
> 0.2 or 1.0?
>
> > On 25 Nov 2021, at 14:34, Maxim Muzafarov  wrote:
> >
> > Pert,
> >
> > I think for nightly builds this is the only right option for the
> > suites mentioned above.
> >
> > On Thu, 25 Nov 2021 at 14:33, Petr Ivanov  wrote:
> >>
> >> Hi, Maksim.
> >>
> >>
> >> Run All (Nightly) build will run suites with test scale factor 1.0 — will 
> >> it be a problem?
> >>
> >>> On 25 Nov 2021, at 14:22, Maxim Muzafarov  wrote:
> >>>
> >>> Folks,
> >>>
> >>> I've merged the PR [1] to the master branch and applied scale factor
> >>> 0.2 to the tests that were moved to dedicated suites.
> >>> I've created two suites and added them to the Run.All test suite.
> >>> - Snapshots [2]
> >>> - SnapshotsWithIndexes [3]
> >>>
> >>> [1] https://github.com/apache/ignite/pull/9584/files
> >>> [2] 
> >>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Snapshots_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> >>> [3] 
> >>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_SnapsohtWithIndexes_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> >>>
> >>> On Wed, 24 Nov 2021 at 15:30, Maxim Muzafarov  wrote:
> >>>>
> >>>> Igniters,
> >>>>
> >>>> Currently, there are a lot of snapshot tests running under the
> >>>> `Basic3` test suite. Since the amount of tests is actually growing it
> >>>> is not good to run them at the basic Ignite test suite.
> >>>>
> >>>> I propose moving all the tests to a dedicated test suite and running
> >>>> them independently taking into account that most of them require
> >>>> TEST_SCALE_FACTOR_PROPERTY to be configured. The default number of
> >>>> affinity partitions is 1024 and this is too big for TeamCity agents
> >>>> with slow HDD.
> >>>>
> >>>> I've prepared the PR [2] within the issue [1].
> >>>> Are there any objections to do such changes?
> >>>>
> >>>>
> >>>> [1] https://issues.apache.org/jira/browse/IGNITE-15233
> >>>> [2] https://github.com/apache/ignite/pull/9584/files
> >>>> [3] 
> >>>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_DiskPageCompressions1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> >>
>

Re: Moving snapshot tests to their own test suites

[Maxim Muzafarov]

Pert,

I think for nightly builds this is the only right option for the
suites mentioned above.

On Thu, 25 Nov 2021 at 14:33, Petr Ivanov  wrote:
>
> Hi, Maksim.
>
>
> Run All (Nightly) build will run suites with test scale factor 1.0 — will it 
> be a problem?
>
> > On 25 Nov 2021, at 14:22, Maxim Muzafarov  wrote:
> >
> > Folks,
> >
> > I've merged the PR [1] to the master branch and applied scale factor
> > 0.2 to the tests that were moved to dedicated suites.
> > I've created two suites and added them to the Run.All test suite.
> > - Snapshots [2]
> > - SnapshotsWithIndexes [3]
> >
> > [1] https://github.com/apache/ignite/pull/9584/files
> > [2] 
> > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Snapshots_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> > [3] 
> > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_SnapsohtWithIndexes_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> >
> > On Wed, 24 Nov 2021 at 15:30, Maxim Muzafarov  wrote:
> >>
> >> Igniters,
> >>
> >> Currently, there are a lot of snapshot tests running under the
> >> `Basic3` test suite. Since the amount of tests is actually growing it
> >> is not good to run them at the basic Ignite test suite.
> >>
> >> I propose moving all the tests to a dedicated test suite and running
> >> them independently taking into account that most of them require
> >> TEST_SCALE_FACTOR_PROPERTY to be configured. The default number of
> >> affinity partitions is 1024 and this is too big for TeamCity agents
> >> with slow HDD.
> >>
> >> I've prepared the PR [2] within the issue [1].
> >> Are there any objections to do such changes?
> >>
> >>
> >> [1] https://issues.apache.org/jira/browse/IGNITE-15233
> >> [2] https://github.com/apache/ignite/pull/9584/files
> >> [3] 
> >> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_DiskPageCompressions1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
>

Re: Moving snapshot tests to their own test suites

[Maxim Muzafarov]

Folks,

I've merged the PR [1] to the master branch and applied scale factor
0.2 to the tests that were moved to dedicated suites.
I've created two suites and added them to the Run.All test suite.
- Snapshots [2]
- SnapshotsWithIndexes [3]

[1] https://github.com/apache/ignite/pull/9584/files
[2] 
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Snapshots_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
[3] 
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_SnapsohtWithIndexes_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv

On Wed, 24 Nov 2021 at 15:30, Maxim Muzafarov  wrote:
>
> Igniters,
>
> Currently, there are a lot of snapshot tests running under the
> `Basic3` test suite. Since the amount of tests is actually growing it
> is not good to run them at the basic Ignite test suite.
>
> I propose moving all the tests to a dedicated test suite and running
> them independently taking into account that most of them require
> TEST_SCALE_FACTOR_PROPERTY to be configured. The default number of
> affinity partitions is 1024 and this is too big for TeamCity agents
> with slow HDD.
>
> I've prepared the PR [2] within the issue [1].
> Are there any objections to do such changes?
>
>
> [1] https://issues.apache.org/jira/browse/IGNITE-15233
> [2] https://github.com/apache/ignite/pull/9584/files
> [3] 
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_DiskPageCompressions1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv

Moving snapshot tests to their own test suites

[Maxim Muzafarov]

Igniters,

Currently, there are a lot of snapshot tests running under the
`Basic3` test suite. Since the amount of tests is actually growing it
is not good to run them at the basic Ignite test suite.

I propose moving all the tests to a dedicated test suite and running
them independently taking into account that most of them require
TEST_SCALE_FACTOR_PROPERTY to be configured. The default number of
affinity partitions is 1024 and this is too big for TeamCity agents
with slow HDD.

I've prepared the PR [2] within the issue [1].
Are there any objections to do such changes?


[1] https://issues.apache.org/jira/browse/IGNITE-15233
[2] https://github.com/apache/ignite/pull/9584/files
[3] 
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_DiskPageCompressions1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv

Re: Move Azure, AWS, GCE to the ignite-extensions

[Maxim Muzafarov]

Petr,

There is only the GCE suite left to be configured. I've created an
issue [1] to do this. Please, take a look.

[1] https://issues.apache.org/jira/browse/IGNITE-15981

On Wed, 24 Nov 2021 at 12:00, Petr Ivanov  wrote:
>
> Hi, Maksim.
>
>
> Can you file a ticket about recreating test suites for extensions, please?
> I will attend to it in nearest time.
>
>
> > On 23 Nov 2021, at 17:14, Maxim Muzafarov  wrote:
> >
> > Hello Petr,
> >
> > Can you assist me with configuring the GCE [1] suite on the TC
> > Extensions project? Currently, I have an issue with moving environment
> > variables from the old GCE suite [2] to the new one.
> >
> > I need to create the following envs:
> > - env.test.gce.account.id
> > - env.test.gce.p12.path
> > - env.test.gce.project.name
> >
> > However the `id` seems to be a password, so it's hidden on the admin
> > panel. Can you please help me with this?
> >
> > [1] 
> > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteExtensions_Tests_Gce_IgniteExtensions_Tests=%3Cdefault%3E=buildTypeStatusDiv
> > [2] 
> > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_GceOld_IgniteTests24Java8=ignite-2.12=buildTypeStatusDiv
> >
> > On Mon, 25 Oct 2021 at 14:22, Maxim Muzafarov  wrote:
> >>
> >> Folks,
> >>
> >> I've moved the azure, gce, aws modules to the ignite-extensions project.
> >> https://issues.apache.org/jira/browse/IGNITE-15541
> >>
> >> Building the modules in the ignite-extension project will prepare an
> >> appropriate release zip file containing all the necessary
> >> dependencies:
> >> - ignite-aws-ext.zip
> >> - ignite-gce-ext.zip
> >> - ignite-auzre-ext.zip
> >>
> >>
> >> On Wed, 13 Oct 2021 at 17:09, Stephen Darlington
> >>  wrote:
> >>>
> >>> Okay, I phrased that badly. I mean an extra platform-specific ZIP file 
> >>> that I used to augment the generic Ignite ZIP file.
> >>>
> >>> So, to run on Azure I’d download ignite.zip + azure.zip.
> >>>
> >>> Extending ignite.sh would also be great, kind of like what’s happening 
> >>> with Ignite 3 as far as I can tell.
> >>>
> >>> What I’m advocating is not needing to use Maven just to run Ignite on 
> >>> Azure, AWS, etc.
> >>>
> >>>> On 13 Oct 2021, at 14:35, Petr Ivanov  wrote:
> >>>>
> >>>> Our self-contained zip file currently is over 400Mb and continues to 
> >>>> grow.
> >>>> Even considering that internet speeds has grown too, it is nonsense to 
> >>>> force user to download such an archive where 90% are useless for most 
> >>>> cases.
> >>>>
> >>>> Also we can:
> >>>> — pack all extensions in single binary with latests releases (and update 
> >>>> after each extension release) or even one by one
> >>>> — extend ignite.sh to download remote libs when extension is activated 
> >>>> via command line
> >>>>
> >>>>
> >>>> Antoine de Saint-Exupéry once said that 'perfection is achieved, not 
> >>>> when there is nothing more to add, but when there is nothing left to 
> >>>> take away'.
> >>>> We are not obliged to make Apache Ignite ideal, but we certainly can 
> >>>> move that way — I am sure the result will exceed expectations.
> >>>>
> >>>>
> >>>>
> >>>>> On 13 Oct 2021, at 16:02, Stephen Darlington 
> >>>>>  wrote:
> >>>>>
> >>>>> Having extensions in Maven Central makes perfect sense for tools that 
> >>>>> need to be built and integrated with other code, Spring integrations 
> >>>>> for example.
> >>>>>
> >>>>> That’s not the case for extensions that are required just to run 
> >>>>> Ignite. A self-contained zip file for each platform would work.
> >>>>>
> >>>>>> On 13 Oct 2021, at 13:41, Maxim Muzafarov  wrote:
> >>>>>>
> >>>>>> Nikolay,
> >>>>>>
> >>>>>> All extensions will be available at the maven central for download.
> >>>>>>
> >>>>>> Previously extensions have a dependent version on the ignite core, so
> >>>>>> each time the Ignite was released it made sense

Re: Move Azure, AWS, GCE to the ignite-extensions

[Maxim Muzafarov]

Hello Petr,

Can you assist me with configuring the GCE [1] suite on the TC
Extensions project? Currently, I have an issue with moving environment
variables from the old GCE suite [2] to the new one.

I need to create the following envs:
- env.test.gce.account.id
- env.test.gce.p12.path
- env.test.gce.project.name

However the `id` seems to be a password, so it's hidden on the admin
panel. Can you please help me with this?

[1] 
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteExtensions_Tests_Gce_IgniteExtensions_Tests=%3Cdefault%3E=buildTypeStatusDiv
[2] 
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_GceOld_IgniteTests24Java8=ignite-2.12=buildTypeStatusDiv

On Mon, 25 Oct 2021 at 14:22, Maxim Muzafarov  wrote:
>
> Folks,
>
> I've moved the azure, gce, aws modules to the ignite-extensions project.
> https://issues.apache.org/jira/browse/IGNITE-15541
>
> Building the modules in the ignite-extension project will prepare an
> appropriate release zip file containing all the necessary
> dependencies:
> - ignite-aws-ext.zip
> - ignite-gce-ext.zip
> - ignite-auzre-ext.zip
>
>
> On Wed, 13 Oct 2021 at 17:09, Stephen Darlington
>  wrote:
> >
> > Okay, I phrased that badly. I mean an extra platform-specific ZIP file that 
> > I used to augment the generic Ignite ZIP file.
> >
> > So, to run on Azure I’d download ignite.zip + azure.zip.
> >
> > Extending ignite.sh would also be great, kind of like what’s happening with 
> > Ignite 3 as far as I can tell.
> >
> > What I’m advocating is not needing to use Maven just to run Ignite on 
> > Azure, AWS, etc.
> >
> > > On 13 Oct 2021, at 14:35, Petr Ivanov  wrote:
> > >
> > > Our self-contained zip file currently is over 400Mb and continues to grow.
> > > Even considering that internet speeds has grown too, it is nonsense to 
> > > force user to download such an archive where 90% are useless for most 
> > > cases.
> > >
> > > Also we can:
> > > — pack all extensions in single binary with latests releases (and update 
> > > after each extension release) or even one by one
> > > — extend ignite.sh to download remote libs when extension is activated 
> > > via command line
> > >
> > >
> > > Antoine de Saint-Exupéry once said that 'perfection is achieved, not when 
> > > there is nothing more to add, but when there is nothing left to take 
> > > away'.
> > > We are not obliged to make Apache Ignite ideal, but we certainly can move 
> > > that way — I am sure the result will exceed expectations.
> > >
> > >
> > >
> > >> On 13 Oct 2021, at 16:02, Stephen Darlington 
> > >>  wrote:
> > >>
> > >> Having extensions in Maven Central makes perfect sense for tools that 
> > >> need to be built and integrated with other code, Spring integrations for 
> > >> example.
> > >>
> > >> That’s not the case for extensions that are required just to run Ignite. 
> > >> A self-contained zip file for each platform would work.
> > >>
> > >>> On 13 Oct 2021, at 13:41, Maxim Muzafarov  wrote:
> > >>>
> > >>> Nikolay,
> > >>>
> > >>> All extensions will be available at the maven central for download.
> > >>>
> > >>> Previously extensions have a dependent version on the ignite core, so
> > >>> each time the Ignite was released it made sense to include all the
> > >>> extensions into the uber-zip file. Each extension has its own release
> > >>> version now, so an extension can be upgraded and used independently,
> > >>> what is the reason include it in the single uber-zip file? Probably it
> > >>> would be better to provide a self-contained zip file for each cloud
> > >>> platform.
> > >>>
> > >>> If I've missed your issue, so can you clarify the problem in more 
> > >>> detail?
> > >>>
> > >>> On Wed, 13 Oct 2021 at 14:37, Nikolay Izhikov  
> > >>> wrote:
> > >>>>
> > >>>> Maxim.
> > >>>>
> > >>>>> Currently, they are copied from the optional
> > >>>>> directory of the ignite binary package but would be copied from an
> > >>>>> appropriate ignite extension binary package.
> > >>>>
> > >>>> But how, the user will download this binary package?
> > >>>> Right now, all the user need 

Re: [DISCUSSION][IEP-80] Breaking changes in Ignite-2.x

[Maxim Muzafarov]

Folks,


I've prepared the changes related to the legacy Service Grid removal
for the 2.13 release. Here is the issue [1] and the PR [2] of these
changes.

Some important notes:

- Removed GridServiceProcessor legacy implementation (internal)
- The IGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED system property
was removed (this is a breaking change)
- The ATTR_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED node attribute was
removed (this is a breaking change)
- The node with 2.13 won't be able to connect to 2.12 (assume Ignite
services are used)

The legacy test suite [3] will be removed after the [1] issue will be merged.


Who can take a look at this PR?


[1] https://issues.apache.org/jira/browse/IGNITE-15758
[2] https://github.com/apache/ignite/pull/9577/files
[3] 
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ServiceGridLegacyMode

On Fri, 22 Oct 2021 at 12:43, Nikolay Izhikov  wrote:
>
> Hello.
>
> In the scope of IEP-80 Breaking changes in Ignite-2.x PR for the following 
> API are prepared:
>
> 1. MVCC
> - https://issues.apache.org/jira/browse/IGNITE-15757
> - https://github.com/apache/ignite/pull/9516
>
> 2. LOCAL caches
> - https://issues.apache.org/jira/browse/IGNITE-15756
> - https://github.com/apache/ignite/pull/9515
>
> 3. CacheConfiguration#rebalanceDelay
> - https://issues.apache.org/jira/browse/IGNITE-15764
> - https://github.com/apache/ignite/pull/9515
>
> Please, review.
>
> > 15 окт. 2021 г., в 16:23, Nikolay Izhikov  
> > написал(а):
> >
> > THanks, Maksim.
> >
> > Tickets included in IEP scope and marked for d in 2.12-2.13
> >
> >> 15 окт. 2021 г., в 16:03, Maxim Muzafarov  написал(а):
> >>
> >> Let's deprecate RebalanceDelay and RebalanceMode=NONE also.
> >>
> >> [1] https://issues.apache.org/jira/browse/IGNITE-12662
> >> [2] https://issues.apache.org/jira/browse/IGNITE-14613
> >>
> >> On Fri, 15 Oct 2021 at 15:46, Anton Vinogradov  wrote:
> >>>
> >>> +1
> >>>
> >>> On Fri, Oct 15, 2021 at 3:41 PM Nikita Amelchev 
> >>> wrote:
> >>>
> >>>> +1 for deprecation in the 2.12 release
> >>>>
> >>>> пт, 15 окт. 2021 г. в 15:35, Nikolay Izhikov :
> >>>>>
> >>>>> Hello, Igniters.
> >>>>>
> >>>>> I’ve prepared IEP-80 [1] to track breaking changes that should be done
> >>>> in Ignite 2.x.
> >>>>>
> >>>>> We agreed on the following algorithm to deal with breaking changes:
> >>>>>
> >>>>>   - Ignite 2.[x] - deprecate the API + notification of the users.
> >>>>>   - Ignite 2.[x+1] - API removal.
> >>>>>
> >>>>>
> >>>>> I propose to start these improvements with the d (depuration &
> >>>> removal) of the following features:
> >>>>>
> >>>>>   - LOCAL caches
> >>>>>   - MVCC caches
> >>>>>   - legacy service grid implementation
> >>>>>   - legacy JMX metrics beans.
> >>>>>
> >>>>> Deprecation in 2.12
> >>>>> Removal in 2.13
> >>>>>
> >>>>> Please, share your opinion.
> >>>>>
> >>>>> [1]
> >>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191334475
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Best wishes,
> >>>> Amelchev Nikita
> >>>>
> >
>

Re: Apache Ignite 2.12 RELEASE [Time, Scope, Manager]

[Maxim Muzafarov]

Folks,

I've fixed almost all the review comments [1]. Hopefully, the changes
will be merged by the end of the week.

[1] https://issues.apache.org/jira/browse/IGNITE-14744

On Mon, 8 Nov 2021 at 15:42, Nikita Amelchev  wrote:
>
> Hello, Pavel.
>
> The code freeze is blocked by two issues discussed above [1] [2]. The
> issues are in the final review state and should be merged soon.
>
> The bugfix is useful and can be cherry-picked, thank you.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-15530
> [2] https://issues.apache.org/jira/browse/IGNITE-14744
>
>
> пн, 8 нояб. 2021 г. в 14:46, Pavel Tupitsyn :
>
> >
> > Igniters,
> >
> > What's the code freeze status?
> > Can I cherry-pick a bugfix [1] ?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-15807
> >
> > On Tue, Nov 2, 2021 at 4:39 PM Ivan Daschinsky  wrote:
> >
> > > Thanks, cherry-picked to master.
> > >
> > > вт, 2 нояб. 2021 г. в 16:00, Nikita Amelchev :
> > >
> > > > Ivan,
> > > >
> > > > Yes, the patch can be cherry-picked.
> > > >
> > > > вт, 2 нояб. 2021 г. в 15:55, Ivan Daschinsky :
> > > > >
> > > > > Since code freeze is postponed, may be I can cherry-pick my patch
> > > already
> > > > > merged to master?
> > > > > https://issues.apache.org/jira/browse/IGNITE-15806
> > > > >
> > > > > пт, 29 окт. 2021 г. в 20:24, Nikita Amelchev :
> > > > >
> > > > > > Maksim T., Maxim M., Ok.
> > > > > >
> > > > > > I think we can move code freeze to +1 week to await these issues.
> > > > > >
> > > > > > пт, 29 окт. 2021 г. в 15:53, Maxim Muzafarov :
> > > > > > >
> > > > > > > Folks,
> > > > > > >
> > > > > > > I've previously mentioned that I'd like to include the [1] issue 
> > > > > > > in
> > > > > > > the release. Currently, the status is "Patch Available" and it's
> > > > > > > actively reviewing now. I'd be happy if we wait a couple of days
> > > and
> > > > > > > add this improvement to the release.
> > > > > > >
> > > > > > > I've also created an issue [2] to remove the ambiguity output
> > > message
> > > > > > > for the snapshot check and idle verify procedures. This is a minor
> > > > > > > output message change, however, it was directly requested by 
> > > > > > > users.
> > > > > > > Would you don't mind if we include this issue in the release also?
> > > > > > >
> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14744
> > > > > > > [2] https://issues.apache.org/jira/browse/IGNITE-15849
> > > > > > >
> > > > > > > On Fri, 29 Oct 2021 at 14:19, Maksim Timonin <
> > > > timonin.ma...@gmail.com>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > Status update on my issue:
> > > > > > > >
> > > > > > > > IGNITE-15530 [1] is in "Patch Available" state, Anton Vinogradov
> > > > > > agreed to
> > > > > > > > review this ticket.
> > > > > > > >
> > > > > > > > Also, I'm preparing IndexQuery docs in ticket IGNITE-15745 [2].
> > > I'm
> > > > > > going
> > > > > > > > to submit a patch with docs today/tomorrow, and want to include
> > > > them in
> > > > > > > > 2.12 too.
> > > > > > > >
> > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-15530
> > > > > > > > [2] https://issues.apache.org/jira/browse/IGNITE-15745
> > > > > > > >
> > > > > > > > On Thu, Oct 28, 2021 at 11:06 AM Ilya Kasnacheev <
> > > > > > ilya.kasnach...@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hello!
> > > > > > > > >
> > > > > > > > > I have prepared a fix for sqlline.sh -e:
> > > > > > > > > https://github.com/apache/ignite/pull/9536
> > > > > > > > >
> > >