Re: [ANNOUNCE] Welcome Kirill Tkalenko as a new committer

[Petr Ivanov]

Congratulations, Kirill!


> On 10 Oct 2022, at 17:15, Pavel Tupitsyn  wrote:
> 
> The Project Management Committee (PMC) for Apache Ignite
> has invited Kirill Tkalenko to become a committer and we are pleased
> to announce that they have accepted.
> 
> Kirill is an active contributor and community member, he made significant
> additions to Ignite 2.x and 3.x code bases, WAL and PageMemory improvements
> among others.
> 
> 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 Kirill, and congratulating him on the new role
> in
> the Apache Ignite Community!
> 
> Regards,
> Pavel Tupitsyn

Re: [ANNOUNCE] New PMC member: Ivan Daschinsky

[Petr Ivanov]

Congratulations!


> On 17 Sep 2022, at 16:33, Dmitriy Pavlov  wrote:
> 
> Hi Igniters!
> 
> The Project Management Committee (PMC) for Apache Ignite has invited
> Ivan Daschinsky to become a member of the PMC and we are pleased to
> announce that he has accepted.
> 
> Ivan contributed the Ignite Python thin client. And he is still maintaining
> it.
> He is also actively supporting users.
> 
> Please join me in congratulating Ivan on his new role.
> 
> Best Regards,
> Dmitriy Pavlov
> on behalf of Apache Ignite PMC

Re: TeamCity 1 maintenance

[Petr Ivanov]

The migration is complete, we are restoring operations.
Currently the number of Linux agents is limited, full count (50) will be 
delivered until tomorrow.

There is a ticket for INFRA [1] to update domain name IP.
To start working with TeamCity 1 immediately, please use WA and hardcode 
216.218.135.140 ci.ignite.apache.org in you /etc/hosts file.


Thank you!



[1] https://issues.apache.org/jira/browse/INFRA-23693

> On 14 Sep 2022, at 16:14, Petr Ivanov  wrote:
> 
> Dear community,
> 
> 
> TeamCity 1 (ci.ignite.apache.org) is moving to the new hardware.
> Effective immediately the queue will be paused, and after last build is 
> finished the process will start.
> 
> Please expect service downtime until tomorrow 09:00 UTC.
> 
> Until then, please use TeamCity 2 (ci2.ignite.apache.org) as a backup.
> 
> 
> End of maintenance as well as possible delays will be reported in this thread.
> Stay tuned!

Re: TeamCity 1 maintenance

[Petr Ivanov]

Just overall hardware upgrade in terms of better CPU and faster RAM.
Plus there will be 2 agents per disk, not 3 which should have positive 
influence.

Fine tuning will be done a bit later during next maintenance.

> On 14 Sep 2022, at 16:20, Anton Vinogradov  wrote:
> 
> Hi,
> 
> Is it possible to share old/new hardware specs, or at least the difference?
> Will it become faster?
> 
> On Wed, Sep 14, 2022 at 4:14 PM Petr Ivanov  wrote:
> 
>> Dear community,
>> 
>> 
>> TeamCity 1 (ci.ignite.apache.org) is moving to the new hardware.
>> Effective immediately the queue will be paused, and after last build is
>> finished the process will start.
>> 
>> Please expect service downtime until tomorrow 09:00 UTC.
>> 
>> Until then, please use TeamCity 2 (ci2.ignite.apache.org) as a backup.
>> 
>> 
>> End of maintenance as well as possible delays will be reported in this
>> thread.
>> Stay tuned!

TeamCity 1 maintenance

[Petr Ivanov]

Dear community,


TeamCity 1 (ci.ignite.apache.org) is moving to the new hardware.
Effective immediately the queue will be paused, and after last build is 
finished the process will start.

Please expect service downtime until tomorrow 09:00 UTC.

Until then, please use TeamCity 2 (ci2.ignite.apache.org) as a backup.


End of maintenance as well as possible delays will be reported in this thread.
Stay tuned!

Re: [RESULT][VOTE] Ignite Packaging IEP

[Petr Ivanov]

Hi, Mikhail!


Did you mean Apache Ignite 3?
I think we should not forget to add 2 or 3 respectively, 'cause these are 
different products whatsoever.


Thank you!

> On 29 Aug 2022, at 17:32, Mikhail Pochatkin  wrote:
> 
> Hello Igniters,
> 
> Switching Apache Ignite build system to Gradle and agreement on all target
> package distribution formats for Apache Ignite has been accepted.
> 
> Alexander Polovtcev +1
> Vyaceslav Koptilin +1
> Andrey Gura +1
> 
> Vote thread:
> https://lists.apache.org/thread/mrwzck7olzgkt25tzg5co7b6v5so1m93
> Ignite Packaging IEP Ignite Packaging IEP

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

[Petr Ivanov]

Hi, Taras.

Granted!

> On 22 Aug 2022, at 15:34, Taras Ledkov  wrote:
> 
> Hi,
> 
> 1. Petr, could you grant me TC permissions to run release builds please?
> 2. Pavel, please cherry pick your patch for IGNITE-17559 [1] to the release 
> branch ignite-2.14 [2]. Or we could move the issue to the next release?
> 
> [1]. https://issues.apache.org/jira/browse/IGNITE-17559
> [2]. https://github.com/apache/ignite/tree/ignite-2.14

Re: [ANNOUNCE] New PMC member: Taras Ledkov

[Petr Ivanov]

Congratulations!

> On 20 Aug 2022, at 00:18, Dmitriy Pavlov  wrote:
> 
> Hi Igniters!
> 
> The Project Management Committee (PMC) for Apache Ignite has invited
> Taras Ledkov to become a member of the PMC and we are pleased to
> announce that he has accepted.
> 
> Taras is a veteran committer, and it is needless to say how long
> and successfully he is contributing to the Apache Ignite.
> Taras is responsible for a solid bulk of SQL and JDBC code.
> 
> Please join me in congratulating Taras on his new role.
> 
> Best Regards,
> Dmitriy Pavlov
> on behalf of Apache Ignite PMC

Re: [ANNOUNCE] New PMC member: Vyacheslav Koptilin

[Petr Ivanov]

Congrats!
Well deserved!

> On 17 Aug 2022, at 17:34, Kseniya Romanova  wrote:
> 
> Hi Igniters!
> 
> The Project Management Committee (PMC) for Apache Ignite has invited
> Vyacheslav Koptilin to become a member of the PMC and we are pleased to
> announce that he has accepted.
> 
> Vyacheslav is a veteran committer and contributes a lot to the Ignite
> storage https://github.com/sk0x50.
> 
> Please join me in congratulating Vyacheslav on his new role.
> 
> Best Regards,
> Kseniya Romanova
> on behalf of Apache Ignite PMC

Re: [DISCUSSION] IEP-93: Ignite Packaging

[Petr Ivanov]

Hi, Mikhail!


The IEP looks great and there are a lot of work to be done.
I guess we are waiting now for the initial Gradle build implementation to start 
applying changes on TC and further work for packaging?

> On 15 Aug 2022, at 13:43, Mikhail Pochatkin  wrote:
> 
> Hello, Igniters.
> 
> I'd like to start a discussion about Ignite Packaging for Apache Ignite
> 3[1]. The main purpose of these changes is related to improving Apache
> Ignite 3 distribution process.
> 
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-93%3A+Ignite+Packaging

Re: [CATCH All] team city bot permissions to trigger builds

[Petr Ivanov]

Hi, Sergey.


What bot?


Regards,
Petr Ivanov
Head of IT
IT & Development Solutions | GRIDGAIN SYSTEMS
+7 (911) 945-00-59

> On 3 Aug 2022, at 11:33, Sergey Korotkov  wrote:
> 
> Hello colleagues,
> 
> I have troubles invoking builds and re-runs from the team city bot interface.
> 
> If I click on the corresponding buttons ("Trigger build" or "Re-run possible 
> blockers") it shows the "Internal Server Error [500]." in the UI and the 
> chrome dev tools shows that bot backend actually return the following error 
> message:
> 
> --
> 
> Service https://ci.ignite.apache.org/app/rest/buildQueue returned Invalid 
> Response Code : 403:
> Responding with error, status code: 403 (Forbidden).
> Details: jetbrains.buildServer.serverSide.auth.AccessDeniedException: You do 
> not have "Comment build" permission in project with internal id: project17
> Access denied. Check the user has enough permissions to perform the operation.
> 
> --
> 
> 
> Is it a bug or I need more permissions in fact?
> 
> If my current permissions are not enough would you please give me more?
> 
> 
> My teamcity user name is: serge.korotkov
> 
> 
> Thanks,
> 
> --
> 
>Sergey

Re: Apache Ignite Docker Image Apache ignite/ignite:2.13.0 has many vulnerabilities

[Petr Ivanov]

Hi, Rameish!

Are there vulnerabilities in Apache Ignite's jars, dependency's jars or 
container software?
Also — can you share the way you've run checks, please?


> On 9 Jun 2022, at 08:13, Gadamsetty, Rameish 
>  wrote:
> 
> Hi Team,
> 
> All, We ran Twist lock scan on Docker Image Apache ignite/ignite:2.13.0 and 
> observed many vulnerabilities, Can we get new image with fixes or is there 
> any other way to fix vulnerabilities?
> 
> Thanks & Regards,
> Rameish G.V.N

Re: [DISCUSSION] Remove scalar module

[Petr Ivanov]

Hi!


+1 for removal.
That module is long time obsolete and prevents project from JDK upgrades at 
least.

> On 7 Apr 2022, at 15:15, Ilya Kasnacheev  wrote:
> 
> Hello!
> 
> I think it is a good idea, it takes ages to compile and I assume the Scala
> version we use is really outdated now.
> 
> Regards,
> -- 
> Ilya Kasnacheev
> 
> 
> чт, 7 апр. 2022 г. в 14:07, Николай Ижиков :
> 
>> Hello, Igniters.
>> 
>> Looks like scalar module abandoned for at least for 4 years - no user-list
>> questions, no source updates.
>> I propose to remove it completely.
>> 
>> WDYT?

Re: [IGNITE-16293] Support multi-platform Docker images - ASF JIRA

[Petr Ivanov]

Someone with not x86-64 architecture should help with creating and testing 
images — and they can be included to release cycle.


> On 11 Mar 2022, at 20:22, Jeremy Meyer  wrote:
> 
> Not an answer to your question, but some thoughts..  I have an apple
> Silicon M1 mac. While creating the exercises for the PubNub data streaming
> demo for the Control Center / Nebula trainings, where we build the image
> from docker image "openjdk:11" (previous versions don't work)  I discovered
> a few, nasty little gotcha's in Docker on M1 including apparent differences
> in the way multicast and DNS works (or doesn't work) in the Docker network.
> For example, the nodes of my cluster never discovered each other until I
> specified an actual server name  "docker-ignite-server-node-1:47500..47509"  
> in
> the discoverySPI settings.
> 
> So for M1 it seems that it isn't just the architecture you would need to
> test,  there are some annoying little differences in implementation.
> 
> Happy to help test after this training deadline has been met, end of this
> month. I do need to update the Monitoring tutorial, because right now it
> doesn't work on Linux or M1.
> 
> Jeremy.
> 
> On Fri, Mar 11, 2022 at 12:04 PM Stephen Darlington <
> stephen.darling...@gridgain.com> wrote:
> 
>> Hi all,
>> 
>> I opened this ticket recently, but think it needs further discussion.
>> https://issues.apache.org/jira/browse/IGNITE-16293 <
>> https://issues.apache.org/jira/browse/IGNITE-16293>
>> 
>> The motivation for the ticket came from a user request for an image that
>> ran natively on an M1 MacBook (70695484 <
>> https://stackoverflow.com/questions/70685637/apache-ignite-docker-image-not-compatible-on-apple-m1-max/70695484#70695484>).
>> I’m honestly quite surprised that it’s taken this long for anyone to ask!
>> I’ve run Ignite on my Raspberry Pi from time-to-time and ARM-based servers
>> are also becoming increasingly common.
>> 
>> However, this question led me down a rabbit-hole, resulting in three
>> further questions:
>> Should we support Docker images with architectures other than x86-64?
>> If yes, which ones?
>> And how should we support them?
>> We currently have images for x86-64 and, for a couple of versions,
>> additional images for s390x. So one argument in favour of the first point
>> is that we already do! Of course, extra code requires more support and some
>> work on the build servers. I think the effort is low but it’s non-zero.
>> 
>> I don’t think we need to go crazy here. I think adding an ARM image would
>> open up support for Raspberry Pi’s and Apple Silicon Macs.
>> 
>> Docker also has the ability to cross-compile (working-with-buildx <
>> https://docs.docker.com/buildx/working-with-buildx/>) so there’s no need
>> for any specialised new hardware. (I’m unsure if this option works for
>> s390x?)
>> 
>> Currently, our cross-platform support is achieved just with tags. There is
>> a better way where, in addition to the tags, you add a manifest. The
>> manifest allows a client to pick the right image automatically.
>> (multi-platform-docker-builds <
>> https://www.docker.com/blog/multi-platform-docker-builds/>) As an
>> example, when I run this on my Raspberry Pi I get the ARMv7 image:
>> 
>> sudo docker run -it --rm --net=host ghcr.io/sdarlington/ignite-arm:2.12.0
>> 
>> But if I run the same command on an Apple Silicon Mac (I think — I don’t
>> have one to test!), it would use the aarch64 image. I built both the ARMv7
>> and aarch64 images on my Intel Mac.
>> 
>> Thoughts?
>> 
>> Regards,
>> Stephen

Re: [ANNOUNCE] Welcome Alexander Lapin as a new committer

[Petr Ivanov]

Congratulations!

> On 9 Mar 2022, at 17:46, Kseniya Romanova  wrote:
> 
> Igniters! The Apache Ignite Project Management Committee (PMC) has invited
> Alexander Lapin to become a new committer and are happy to announce that he
> has
> accepted.
> 
> Alexander contributed to the Ignite several important improvements of the
> JDBC thin driver, and tracing framework.  Also, he created some valuable
> content about Tracing and Data Rebalance. Now, he is deeply involved in
> developing Apache Ignite 3.0.
> 
> 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 Alexander, and congratulating him on the new
> role in the Apache Ignite Community.
> 
> Cheers,
> Kseniya Romanova

Re: java 17 support

[Petr Ivanov]

Adding ability to compile Ignite 2 with JDK11+ will require so much refactoring 
and, sometimes, rethinking of approaches, that it will become different project 
in some ways.
And there is such different project — Ignite 3.

I do no think that Ignite 2 will continue its lifecycle indefinitely and sooner 
or later will be superseded by Ignite 3 which will support all latest JDKs.


However — some code refactoring in order to run (not compile) Ignite 2 on 
modern JDKs (until the end of life) seems to be worth the efforts.

> On 2 Feb 2022, at 15:25, Nikolay Izhikov  wrote:
> 
>> will definitely not be moved to JDK more than 8th.
> 
> I think is a matter to discuss :)
> Why we should stay on JDK8 forever?
> 
> 
>> 2 февр. 2022 г., в 15:23, Petr Ivanov  написал(а):
>> 
>> Hi, Davide!
>> 
>> 
>> Ignite 3 will support at least 11th JDK but that can be changed (for the 
>> better) on initial release.
>> 
>> Ignite 2 is subject to discuss, it currently runs on 11th and there should 
>> be a patch that added JDK 17 runtime support, but codebase (compile) will 
>> definitely not be moved to JDK more than 8th.
>> 
>>> On 28 Jan 2022, at 18:28, Davide Imbriaco  wrote:
>>> 
>>> hi,
>>> 
>>> I've been using ignite in a project based on java 17 (which is the latest
>>> LTS java release). I see that ignite requires java 8 or 11... with java 17
>>> it works fine so far (just a couple minor issues easily resolved), but I
>>> was wondering if there is a roadmap for official java 17 support, just to
>>> be sure. Maybe this is scheduled for Ignite 3?
>>> 
>>> thank you, bye,
>>> D
>> 
> 

Re: java 17 support

[Petr Ivanov]

Hi, Davide!


Ignite 3 will support at least 11th JDK but that can be changed (for the 
better) on initial release.

Ignite 2 is subject to discuss, it currently runs on 11th and there should be a 
patch that added JDK 17 runtime support, but codebase (compile) will definitely 
not be moved to JDK more than 8th.

> On 28 Jan 2022, at 18:28, Davide Imbriaco  wrote:
> 
> hi,
> 
> I've been using ignite in a project based on java 17 (which is the latest
> LTS java release). I see that ignite requires java 8 or 11... with java 17
> it works fine so far (just a couple minor issues easily resolved), but I
> was wondering if there is a roadmap for official java 17 support, just to
> be sure. Maybe this is scheduled for Ignite 3?
> 
> thank you, bye,
> D

Re: The conception of using two TeamCity servers

[Petr Ivanov]

There was a reason to store VCS settings in ROOT project — minimising git polls 
which often caused 'too many connections' error, because each new VCS is 
separate instance even if it is the same as in the other project.
Duplicating VCSs will reduce git performance.


Also — if we are going to have synced instances of TCs, it should be full sync 
with all settings and all projects.
Otherwise — you have admin permissions that is more then enough to dump and 
restore pretty much any setting, except user database.



> On 17 Dec 2021, at 16:43, Anton Vinogradov  wrote:
> 
> Petr,
> 
>> However, ROOT project will still be not under VCS and some major settings
> like VCS roots, Clean-Up rules, custom step runners and so much more will
> stay out of Git-based sync.
> VCS roots are project-related and should not be stored somewhere outside
> the project.
> Also, having different roots at different TCs looks like a proper
> configuration.
> For example, TC2 may not contain the Ignite-3 project.
> 
> On Fri, Dec 17, 2021 at 4:13 PM Petr Ivanov  wrote:
> 
>> Separate JIRA project will ruin the concept of introducing changes for
>> both code and build settings in single branch of single project.
>> 
>> 
>>> On 17 Dec 2021, at 15:14, Anton Vinogradov  wrote:
>>> 
>>> Petr,
>>> 
>>>> I strongly suggest avoiding a separate repository for project settings.
>>>> Let's store them in https://github.com/apache/ignite
>>> 
>>> Sounds good, but we must avoid dozens of additional commits in this case.
>>> Each commit should be properly formalized and related to the issue.
>>> We may create a special Jira project for CI issues to separate commits.
>>> 
>>> On Fri, Dec 17, 2021 at 2:46 PM Pavel Tupitsyn 
>> wrote:
>>> 
>>>> Petr,
>>>> 
>>>>> why should I edit code in Apache Ignite 2.x repo to introduce new
>> changes
>>>> in Apache Ignite 3.x build settings
>>>> 
>>>> I thought we can store 3.x settings in 3.x repo and so on.
>>>> 
>>>> Looks like it does not work as I hoped it would.
>>>> Thanks for your answers.
>>>> 
>>>> On Fri, Dec 17, 2021 at 2:35 PM Petr Ivanov 
>> wrote:
>>>> 
>>>>> Pavel,
>>>>> 
>>>>> 
>>>>> If you are referring to this paragraph
>>>>> 
>>>>>   • If you are using TeamCity feature branches, you can define a
>>>>> branch specification when creating a project from URL (Git only) or in
>>>> the
>>>>> VCS root used for versioned settings. TeamCity will run a build in a
>>>> branch
>>>>> using the settings from this branch.
>>>>> 
>>>>> then it is only for new projects.
>>>>> After setting current one all settings will be acquired from the chosen
>>>>> branch and it will not be able to change (only create new project from
>>>> new
>>>>> branch).
>>>>> 
>>>>> 
>>>>> And it still can be done from separate repository.
>>>>> 
>>>>> 
>>>>> Choosing one of the project's repo to host settings for every other
>>>>> project seems non-logical — why should I edit code in Apache Ignite 2.x
>>>>> repo to introduce new changes in Apache Ignite 3.x build settings?
>>>>> 
>>>>>> On 17 Dec 2021, at 14:28, Pavel Tupitsyn 
>> wrote:
>>>>>> 
>>>>>> Petr,
>>>>>> 
>>>>>>> you cannot run new suite added in branch because it just won't be
>>>>> visible
>>>>>> from UI
>>>>>> 
>>>>>> That's unfortunate.
>>>>>> However, a more important scenario is "make changes to the existing
>>>>> project
>>>>>> in a branch", which is supported, as I understand [1]
>>>>>> 
>>>>>> [1]
>>>>>> 
>>>>> 
>>>> 
>> https://www.jetbrains.com/help/teamcity/storing-project-settings-in-version-control.html#Defining+Settings+to+Apply+to+Builds
>>>>>> 
>>>>>> On Fri, Dec 17, 2021 at 2:19 PM Petr Ivanov 
>>>> wrote:
>>>>>> 
>>>>>>> TeamCity DSL just does not work as you wish it should.
>>>>>>> 
>>>>>>> 
>>>>>>> Changes from branches are not visible: you cannot run new suite 

Re: The conception of using two TeamCity servers

[Petr Ivanov]

Separate JIRA project will ruin the concept of introducing changes for both 
code and build settings in single branch of single project.


> On 17 Dec 2021, at 15:14, Anton Vinogradov  wrote:
> 
> Petr,
> 
>> I strongly suggest avoiding a separate repository for project settings.
>> Let's store them in https://github.com/apache/ignite
> 
> Sounds good, but we must avoid dozens of additional commits in this case.
> Each commit should be properly formalized and related to the issue.
> We may create a special Jira project for CI issues to separate commits.
> 
> On Fri, Dec 17, 2021 at 2:46 PM Pavel Tupitsyn  wrote:
> 
>> Petr,
>> 
>>> why should I edit code in Apache Ignite 2.x repo to introduce new changes
>> in Apache Ignite 3.x build settings
>> 
>> I thought we can store 3.x settings in 3.x repo and so on.
>> 
>> Looks like it does not work as I hoped it would.
>> Thanks for your answers.
>> 
>> On Fri, Dec 17, 2021 at 2:35 PM Petr Ivanov  wrote:
>> 
>>> Pavel,
>>> 
>>> 
>>> If you are referring to this paragraph
>>> 
>>>• If you are using TeamCity feature branches, you can define a
>>> branch specification when creating a project from URL (Git only) or in
>> the
>>> VCS root used for versioned settings. TeamCity will run a build in a
>> branch
>>> using the settings from this branch.
>>> 
>>> then it is only for new projects.
>>> After setting current one all settings will be acquired from the chosen
>>> branch and it will not be able to change (only create new project from
>> new
>>> branch).
>>> 
>>> 
>>> And it still can be done from separate repository.
>>> 
>>> 
>>> Choosing one of the project's repo to host settings for every other
>>> project seems non-logical — why should I edit code in Apache Ignite 2.x
>>> repo to introduce new changes in Apache Ignite 3.x build settings?
>>> 
>>>> On 17 Dec 2021, at 14:28, Pavel Tupitsyn  wrote:
>>>> 
>>>> Petr,
>>>> 
>>>>> you cannot run new suite added in branch because it just won't be
>>> visible
>>>> from UI
>>>> 
>>>> That's unfortunate.
>>>> However, a more important scenario is "make changes to the existing
>>> project
>>>> in a branch", which is supported, as I understand [1]
>>>> 
>>>> [1]
>>>> 
>>> 
>> https://www.jetbrains.com/help/teamcity/storing-project-settings-in-version-control.html#Defining+Settings+to+Apply+to+Builds
>>>> 
>>>> On Fri, Dec 17, 2021 at 2:19 PM Petr Ivanov 
>> wrote:
>>>> 
>>>>> TeamCity DSL just does not work as you wish it should.
>>>>> 
>>>>> 
>>>>> Changes from branches are not visible: you cannot run new suite added
>> in
>>>>> branch because it just won't be visible from UI because project UI is
>>>>> rendered from default branch only),
>>>>> and at least snapshot dependencies are taken from default branch only:
>>>>> even if you will add dependency on already visible Run All
>>> configuration,
>>>>> it will be ignored.
>>>>> 
>>>>> 
>>>>> Also about storing in already existing apache/ignite repository — that
>>>>> will break the model about current separation on ignite and ignite-3,
>>>>> ignite-extensions and so-on.
>>>>> As we have different repositories for different parts of our project
>> and
>>>>> TeamCity unites them all — repository should be separate.
>>>>> And when JB will fix the branches issues — we still will be able to
>> use
>>> it
>>>>> with creating branches with the same name on both project and TC
>>> repository.
>>>>> 
>>>>>> On 17 Dec 2021, at 14:06, Pavel Tupitsyn 
>> wrote:
>>>>>> 
>>>>>> Witaliy,
>>>>>> 
>>>>>>> repository is created
>>>>>>> only in the master branch
>>>>>> 
>>>>>> I strongly suggest avoiding a separate repository for project
>> settings.
>>>>>> Let's store them in https://github.com/apache/ignite
>>>>>> 
>>>>>> *1. We should be able to test code changes together with CI/CD
>>> changes.*
>>>>>> *2. We should be able to

Re: The conception of using two TeamCity servers

[Petr Ivanov]

Using Kotlin we no longer need templates, as any build configuration (as 
object) can be heavily customised, parametrised and reused as many times as you 
like.

However, if we are going to separate build settings per project, in me 
experience — we may need some kind of lib with common customisations and custom 
build settings objects, like maven or script step runners.
Otherwise there will be lots of duplicate code.



But syncing secrets will be a bit tricky.
Currently custom UID should be created for the project with secret, which can 
be later reused in Kotlin DSL as reference.
Secret is indeed kept on the hard drive of the server with TC instance.
And I am not sure that we can add the same UID on the second instance.



> On 17 Dec 2021, at 15:32, Виталий Осилов  wrote:
> 
>> I thought we can store 3.x settings in 3.x repo and so on.
> 
> It's not a good idea to use different repositories.
> 
> Ignite also has many different modules, but all are situated in the same
> project.
> 
> 
> If we use different repositories, we can get a situation when a template
> from another project will be deleted.
> 
> Best regards,
> Osipov Vitaliy
> osipov.wita...@gmail.com
> 
> 
> пт, 17 дек. 2021 г. в 15:14, Anton Vinogradov :
> 
>> Petr,
>> 
>>> I strongly suggest avoiding a separate repository for project settings.
>>> Let's store them in https://github.com/apache/ignite
>> 
>> Sounds good, but we must avoid dozens of additional commits in this case.
>> Each commit should be properly formalized and related to the issue.
>> We may create a special Jira project for CI issues to separate commits.
>> 
>> On Fri, Dec 17, 2021 at 2:46 PM Pavel Tupitsyn 
>> wrote:
>> 
>>> Petr,
>>> 
>>>> why should I edit code in Apache Ignite 2.x repo to introduce new
>> changes
>>> in Apache Ignite 3.x build settings
>>> 
>>> I thought we can store 3.x settings in 3.x repo and so on.
>>> 
>>> Looks like it does not work as I hoped it would.
>>> Thanks for your answers.
>>> 
>>> On Fri, Dec 17, 2021 at 2:35 PM Petr Ivanov  wrote:
>>> 
>>>> Pavel,
>>>> 
>>>> 
>>>> If you are referring to this paragraph
>>>> 
>>>>• If you are using TeamCity feature branches, you can define a
>>>> branch specification when creating a project from URL (Git only) or in
>>> the
>>>> VCS root used for versioned settings. TeamCity will run a build in a
>>> branch
>>>> using the settings from this branch.
>>>> 
>>>> then it is only for new projects.
>>>> After setting current one all settings will be acquired from the chosen
>>>> branch and it will not be able to change (only create new project from
>>> new
>>>> branch).
>>>> 
>>>> 
>>>> And it still can be done from separate repository.
>>>> 
>>>> 
>>>> Choosing one of the project's repo to host settings for every other
>>>> project seems non-logical — why should I edit code in Apache Ignite 2.x
>>>> repo to introduce new changes in Apache Ignite 3.x build settings?
>>>> 
>>>>> On 17 Dec 2021, at 14:28, Pavel Tupitsyn 
>> wrote:
>>>>> 
>>>>> Petr,
>>>>> 
>>>>>> you cannot run new suite added in branch because it just won't be
>>>> visible
>>>>> from UI
>>>>> 
>>>>> That's unfortunate.
>>>>> However, a more important scenario is "make changes to the existing
>>>> project
>>>>> in a branch", which is supported, as I understand [1]
>>>>> 
>>>>> [1]
>>>>> 
>>>> 
>>> 
>> https://www.jetbrains.com/help/teamcity/storing-project-settings-in-version-control.html#Defining+Settings+to+Apply+to+Builds
>>>>> 
>>>>> On Fri, Dec 17, 2021 at 2:19 PM Petr Ivanov 
>>> wrote:
>>>>> 
>>>>>> TeamCity DSL just does not work as you wish it should.
>>>>>> 
>>>>>> 
>>>>>> Changes from branches are not visible: you cannot run new suite
>> added
>>> in
>>>>>> branch because it just won't be visible from UI because project UI
>> is
>>>>>> rendered from default branch only),
>>>>>> and at least snapshot dependencies are taken from default branch
>> only:
>>>>>> even if you will add dependency on al

Re: The conception of using two TeamCity servers

[Petr Ivanov]

We CAN store build settings per project — ignite, ignite-3, ignite-extensions 
and so on.
However, ROOT project will still be not under VCS and some major settings like 
VCS roots, Clean-Up rules, custom step runners and so much more will stay out 
of Git-based sync.
And in order to achieve full settings sync we should store root project with 
all subprojects.

Yet, there is a trade-off variant, where we can store ROOT settings in separate 
repo (let's call it ignite-tc) and under it set each project to inherit 
settings from there own repositories.

We can start with all settings, extracting and moving project by project into 
theirs respectful repositories.

> On 17 Dec 2021, at 14:46, Pavel Tupitsyn  wrote:
> 
> Petr,
> 
>> why should I edit code in Apache Ignite 2.x repo to introduce new changes
> in Apache Ignite 3.x build settings
> 
> I thought we can store 3.x settings in 3.x repo and so on.
> 
> Looks like it does not work as I hoped it would.
> Thanks for your answers.
> 
> On Fri, Dec 17, 2021 at 2:35 PM Petr Ivanov  wrote:
> 
>> Pavel,
>> 
>> 
>> If you are referring to this paragraph
>> 
>>• If you are using TeamCity feature branches, you can define a
>> branch specification when creating a project from URL (Git only) or in the
>> VCS root used for versioned settings. TeamCity will run a build in a branch
>> using the settings from this branch.
>> 
>> then it is only for new projects.
>> After setting current one all settings will be acquired from the chosen
>> branch and it will not be able to change (only create new project from new
>> branch).
>> 
>> 
>> And it still can be done from separate repository.
>> 
>> 
>> Choosing one of the project's repo to host settings for every other
>> project seems non-logical — why should I edit code in Apache Ignite 2.x
>> repo to introduce new changes in Apache Ignite 3.x build settings?
>> 
>>> On 17 Dec 2021, at 14:28, Pavel Tupitsyn  wrote:
>>> 
>>> Petr,
>>> 
>>>> you cannot run new suite added in branch because it just won't be
>> visible
>>> from UI
>>> 
>>> That's unfortunate.
>>> However, a more important scenario is "make changes to the existing
>> project
>>> in a branch", which is supported, as I understand [1]
>>> 
>>> [1]
>>> 
>> https://www.jetbrains.com/help/teamcity/storing-project-settings-in-version-control.html#Defining+Settings+to+Apply+to+Builds
>>> 
>>> On Fri, Dec 17, 2021 at 2:19 PM Petr Ivanov  wrote:
>>> 
>>>> TeamCity DSL just does not work as you wish it should.
>>>> 
>>>> 
>>>> Changes from branches are not visible: you cannot run new suite added in
>>>> branch because it just won't be visible from UI because project UI is
>>>> rendered from default branch only),
>>>> and at least snapshot dependencies are taken from default branch only:
>>>> even if you will add dependency on already visible Run All
>> configuration,
>>>> it will be ignored.
>>>> 
>>>> 
>>>> Also about storing in already existing apache/ignite repository — that
>>>> will break the model about current separation on ignite and ignite-3,
>>>> ignite-extensions and so-on.
>>>> As we have different repositories for different parts of our project and
>>>> TeamCity unites them all — repository should be separate.
>>>> And when JB will fix the branches issues — we still will be able to use
>> it
>>>> with creating branches with the same name on both project and TC
>> repository.
>>>> 
>>>>> On 17 Dec 2021, at 14:06, Pavel Tupitsyn  wrote:
>>>>> 
>>>>> Witaliy,
>>>>> 
>>>>>> repository is created
>>>>>> only in the master branch
>>>>> 
>>>>> I strongly suggest avoiding a separate repository for project settings.
>>>>> Let's store them in https://github.com/apache/ignite
>>>>> 
>>>>> *1. We should be able to test code changes together with CI/CD
>> changes.*
>>>>> *2. We should be able to have different project settings in different
>>>>> branches.*
>>>>> 
>>>>> For example, I may remove or rename a module in ignite/master branch
>> and
>>>>> update TC project accordingly,
>>>>> while it continues to work as before in ignite-2.12 branch where we
>>>> prepare
>>>>> the r

Re: The conception of using two TeamCity servers

[Petr Ivanov]

Pavel,


If you are referring to this paragraph

• If you are using TeamCity feature branches, you can define a branch 
specification when creating a project from URL (Git only) or in the VCS root 
used for versioned settings. TeamCity will run a build in a branch using the 
settings from this branch.

then it is only for new projects.
After setting current one all settings will be acquired from the chosen branch 
and it will not be able to change (only create new project from new branch).


And it still can be done from separate repository.


Choosing one of the project's repo to host settings for every other project 
seems non-logical — why should I edit code in Apache Ignite 2.x repo to 
introduce new changes in Apache Ignite 3.x build settings?

> On 17 Dec 2021, at 14:28, Pavel Tupitsyn  wrote:
> 
> Petr,
> 
>> you cannot run new suite added in branch because it just won't be visible
> from UI
> 
> That's unfortunate.
> However, a more important scenario is "make changes to the existing project
> in a branch", which is supported, as I understand [1]
> 
> [1]
> https://www.jetbrains.com/help/teamcity/storing-project-settings-in-version-control.html#Defining+Settings+to+Apply+to+Builds
> 
> On Fri, Dec 17, 2021 at 2:19 PM Petr Ivanov  wrote:
> 
>> TeamCity DSL just does not work as you wish it should.
>> 
>> 
>> Changes from branches are not visible: you cannot run new suite added in
>> branch because it just won't be visible from UI because project UI is
>> rendered from default branch only),
>> and at least snapshot dependencies are taken from default branch only:
>> even if you will add dependency on already visible Run All configuration,
>> it will be ignored.
>> 
>> 
>> Also about storing in already existing apache/ignite repository — that
>> will break the model about current separation on ignite and ignite-3,
>> ignite-extensions and so-on.
>> As we have different repositories for different parts of our project and
>> TeamCity unites them all — repository should be separate.
>> And when JB will fix the branches issues — we still will be able to use it
>> with creating branches with the same name on both project and TC repository.
>> 
>>> On 17 Dec 2021, at 14:06, Pavel Tupitsyn  wrote:
>>> 
>>> Witaliy,
>>> 
>>>> repository is created
>>>> only in the master branch
>>> 
>>> I strongly suggest avoiding a separate repository for project settings.
>>> Let's store them in https://github.com/apache/ignite
>>> 
>>> *1. We should be able to test code changes together with CI/CD changes.*
>>> *2. We should be able to have different project settings in different
>>> branches.*
>>> 
>>> For example, I may remove or rename a module in ignite/master branch and
>>> update TC project accordingly,
>>> while it continues to work as before in ignite-2.12 branch where we
>> prepare
>>> the release with older code.
>>> 
>>> This is super important and this is how most other projects do it (from
>> my
>>> experience).
>>> 
>>> 
>>> 
>>> On Fri, Dec 17, 2021 at 11:12 AM Виталий Осилов <
>> osipov.wita...@gmail.com>
>>> wrote:
>>> 
>>>> Dear Ignite Community!
>>>> 
>>>> I propose for discussion the conception of using two TeamCity servers
>> with
>>>> a roadmap.
>>>> https://ci.ignite.apache.org/
>>>> https://ci2.ignite.apache.org/
>>>> 
>>>> Storing project settings.
>>>> Servers synchronize configurations between themselves using the version
>>>> control-storing DSL (repository at https://github.com/apache). TeamCity
>>>> allows to store the settings in the DSL based on the kotlin language.
>>>> You can read more about the version control-storing DSL  here
>>>> 
>>>> 
>> https://www.jetbrains.com/help/teamcity/2021.2/kotlin-dsl.html#Getting+Started+with+Kotlin+DSL
>>>> This scheme will allow to maintain a single configuration for both TC
>> and
>>>> update configuration after a code review.
>>>> Changes in the suite should be made only in the master branch of the
>> stored
>>>> configuration. WebUI should be disabled on both TC.
>>>> The code-modified PR should be tested for compatibility before approval.
>>>> 
>>>> Configuring authentication.
>>>> It is proposed to switch sign in to TeamCity with using GitHub.com
>> account
>>>> (
>>>> 
>>>&g

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

[Petr Ivanov]

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.
>>>>>>> 
>>>>>>> 
>>>>>>> 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
>>>>>>> 
>>

Re: The conception of using two TeamCity servers

[Petr Ivanov]

TeamCity DSL just does not work as you wish it should.


Changes from branches are not visible: you cannot run new suite added in branch 
because it just won't be visible from UI because project UI is rendered from 
default branch only),
and at least snapshot dependencies are taken from default branch only: even if 
you will add dependency on already visible Run All configuration, it will be 
ignored.


Also about storing in already existing apache/ignite repository — that will 
break the model about current separation on ignite and ignite-3, 
ignite-extensions and so-on.
As we have different repositories for different parts of our project and 
TeamCity unites them all — repository should be separate.
And when JB will fix the branches issues — we still will be able to use it with 
creating branches with the same name on both project and TC repository.

> On 17 Dec 2021, at 14:06, Pavel Tupitsyn  wrote:
> 
> Witaliy,
> 
>> repository is created
>> only in the master branch
> 
> I strongly suggest avoiding a separate repository for project settings.
> Let's store them in https://github.com/apache/ignite
> 
> *1. We should be able to test code changes together with CI/CD changes.*
> *2. We should be able to have different project settings in different
> branches.*
> 
> For example, I may remove or rename a module in ignite/master branch and
> update TC project accordingly,
> while it continues to work as before in ignite-2.12 branch where we prepare
> the release with older code.
> 
> This is super important and this is how most other projects do it (from my
> experience).
> 
> 
> 
> On Fri, Dec 17, 2021 at 11:12 AM Виталий Осилов 
> wrote:
> 
>> Dear Ignite Community!
>> 
>> I propose for discussion the conception of using two TeamCity servers with
>> a roadmap.
>> https://ci.ignite.apache.org/
>> https://ci2.ignite.apache.org/
>> 
>> Storing project settings.
>> Servers synchronize configurations between themselves using the version
>> control-storing DSL (repository at https://github.com/apache). TeamCity
>> allows to store the settings in the DSL based on the kotlin language.
>> You can read more about the version control-storing DSL  here
>> 
>> https://www.jetbrains.com/help/teamcity/2021.2/kotlin-dsl.html#Getting+Started+with+Kotlin+DSL
>> This scheme will allow to maintain a single configuration for both TC and
>> update configuration after a code review.
>> Changes in the suite should be made only in the master branch of the stored
>> configuration. WebUI should be disabled on both TC.
>> The code-modified PR should be tested for compatibility before approval.
>> 
>> Configuring authentication.
>> It is proposed to switch sign in to TeamCity with using GitHub.com account
>> (
>> 
>> https://www.jetbrains.com/help/teamcity/configuring-authentication-settings.html#GitHub.com
>> )
>> and restriction of access for the organization (https : //
>> 
>> docs.github.com/en/organizations/collaborating-with-groups-in-organizations/about-organizations
>> .)
>> User rights are changed on each server by request in Jira.
>> 
>> Storing security credentials.
>> All credentials are stored on each server in the file "
>> / config / projects /  /pluginData/secure/credentials.json".
>> That is why it is supposed to configure the synchronization of this file
>> between two servers.
>> 
>> Maintenance.
>> All change requests of server's maintenance should be created in Jira
>> https://issues.apache.org/jira/projects/IGNITE
>> <https://issues.apache.org/jira/projects/IGNITE/summary>
>> Responsible for the servers and agents - TC1 Petr Ivanov and TC2 Vitaly
>> Osipov. They are responsible for the health of the servers (backups,
>> updates, agents, etc.)
>> Both TC servers must be updated sequentially with a minimum time interval
>> by request in Jira.
>> ---
>> At the first stage, it is required to synchronize the differences in
>> configurations.  The configuration from TC1 is uploaded to TC2.
>> If changes are required in this configuration, tasks are created in Jira to
>> change settings in TC1, then new configuration is re-uploaded to TC2.
>> Repository is created at https://github.com/apache. Tech-user is created
>> for connecting to this repository.  Tech-user should have RW access in the
>> master branch.
>> Checking TC2 functionality for several weeks.
>> Stage  2 - The option of "synchronization of the project settings with the
>> version control system" must be allowed  for the root-project on TC1 and
>> TC2.
>> The option "*Allow editing proje

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

[Petr Ivanov]

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
>>>>> 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
>>>

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

[Petr Ivanov]

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
>>>> 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
>

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

[Petr Ivanov]

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
>>> 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 

Re: [ANNOUNCE] Welcome Semyon Danilov as a new committer

[Petr Ivanov]

Congratulations!


> On 1 Dec 2021, at 01:48, Andrey Gura  wrote:
> 
> Igniters,
> 
> The Apache Ignite Project Management Committee (PMC) has invited
> Semyon Danilov  to become a new committer and are happy to announce
> that he
> has accepted.
> 
> Semyon contributes actively to the project's code base (AI  2 & 3) and
> helps a lot with the development environment set up (you know, all
> this Maven and plugins related issues).
> 
> 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 Ivan, and congratulating him on the new role in
> the Apache Ignite Community.
> 
> Best Regards,
> Andrey Gura

Re: [ANNOUNCE] Welcome Maxim Timonin as a new committer

[Petr Ivanov]

Great news! Congratulations, Maksim!


> On 29 Nov 2021, at 19:13, Kseniya Romanova  wrote:
> 
> Igniters,
> 
> The Project Management Committee (PMC) for Apache Ignite has invited Maxim
> Timonin to become a committer and we are pleased to announce that he has
> accepted.
> 
> Maxim makes valuable contributions to the Apache Ignite code, helps
> actively to applications developers on the user list, and made a good start
> in Project awareness contributing by presenting at Ignite Summit: Cloud
> Edition.
> 
> 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 Maxim, and congratulating him on the new role
> in the Apache Ignite Community!
> 
> Kseniya Romanova
> on behalf of Apache Ignite PMC

Re: Moving snapshot tests to their own test suites

[Petr Ivanov]

My concern was only that 1.0 is too high for TC overall.
If it is OK for Nightly builds — no problems.


However — ordinary Run All uses 0.1 scale and to use 0.2 in that suite we 
should hardcode it inside the suite (or to be more precise — compute based on 
input).

> On 25 Nov 2021, at 16:06, Maxim Muzafarov  wrote:
> 
> 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

[Petr Ivanov]

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

[Petr Ivanov]

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: Move Azure, AWS, GCE to the ignite-extensions

[Petr Ivanov]

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 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:
>>>>>>

Re: Install libnuma-dev on TC agents

[Petr Ivanov]

Hi, Ivan.


Lib has been installed on all agents.

> On 17 Nov 2021, at 18:38, Ivan Daschinsky  wrote:
> 
> Hi, folks.
> 
> Currently, I'm developing custom numa-aware allocator and development is 
> almost done. [1]
> 
> In order to run and build tests, it is required to install libnuma-dev packet 
> on TC agents.
> 
> Peter, could you please install it, it is available on default package repo.
> 
> [1] -- https://issues.apache.org/jira/browse/IGNITE-15922 
> 
> 
> -- 
> Sincerely yours, Ivan Daschinskiy

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

[Petr Ivanov]

Thanks, Sergey.

I've also reconfigured nightly builds for ignite-2.12 branch.


> On 22 Oct 2021, at 17:32, Сергей Утцель  wrote:
> 
> I configured TC bot to 'ignite-2.12' instead of 'ignite-2.11'

Re: Invalid version in nightly builds of AI 2.x

[Petr Ivanov]

Hi. Ivan.


Thanks!
I will attend to the issue in nearest time.

> On 22 Oct 2021, at 12:25, Ivan Daschinsky  wrote:
> 
> Hi folks!
> 
> Recently I've discovered that nightly builds are generated with invalid 
> version
> Namely 3.0.0.x instead of 2.12.0.x.
> The main reason -- recent changes in maven pom's. 
> I've filled ticket [1] and described thoroughly what should be fixed.
> 
> Peter, could you take a look?
> 
> [1] -- https://issues.apache.org/jira/browse/IGNITE-15768 
> 

Re: Ci and ci2 settings synchronization

[Petr Ivanov]

Hi, Nikolay.


Currently, I know only how to sync build settings — we should move to Kotlin.
But that is not an easy task — lots of code should be written before we can 
move, several repositories established and so on.

Considering server instance settings like user database — tempted DB admin is 
required to prepare custom scripts that will replicate users info directly in 
database (and script maintenance will also be required due to annual DB scheme 
migration).


> On 21 Oct 2021, at 16:51, Nikolay Izhikov  wrote:
> 
> Hello, Igniters.
> 
> As you may know, recently, Sberbank sponsored servers capacity to setup new 
> instance of Team City [1]  to run Ignite tests.
> 
> Right now, ci2 is fully ready for daily usage.
> We have exported and prepared Kotlin scripts [2] to keep TC settings as a 
> code [3].
> 
> I think we should adjust both TC instances to use the same settings and run 
> tests in the same way.
> 
> ci.ignite.apache.org is sponsored and run by Grid Gain so 
> 
> Denis, Valentin, Petr, let's have a call to discuss how and when we can 
> implement these changes?
> 
> [1] https://ci2.ignite.apache.org
> [2] https://github.com/willy983/ci_tc_configuration
> [3] https://www.jetbrains.com/help/teamcity/kotlin-dsl.html
> 
> 
>> 3 авг. 2021 г., в 18:33, Dmitry Pavlov  написал(а):
>> 
>> Hi Igniters,
>> 
>> I'm glad to announce that SberTech made an internal aggreement to sponsor a 
>> computing power to provide backup TeamCity instance. This instance is 
>> intended to be a geo-independent, secondary instance with availablility for 
>> community members. 
>> 
>> Thanks to JetBrains for providing license keys for TeamCity as their part of 
>> opensource sponsoring program.
>> 
>> Most likely, we'll setup some domain name as tc.i.a.o or ci2.i.a.o. Please 
>> share your vision what would be most obvious.
>> 
>> After a private discussions with Vitaliy Osipov and Petr Ivanov, I do 
>> believe that it would be possible to preserve current registered users. 
>> Build configurations are to be the same for the secondary instance. 
>> Technical details on how is could be achieved will be available later (most 
>> likely we'll start a sepearate thread to dicuss that).
>> 
>> You are more than welcome to be an early adopters.
>> 
>> Sincerely,
>> Dmitriy Pavlov
>> 
> 

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

[Petr Ivanov]

Try now, please.

> On 21 Oct 2021, at 17:47, Nikita Amelchev  wrote:
> 
> Hi,
> 
> Petr, could you grant me TC permissions to run release builds please?
> 
> ср, 20 окт. 2021 г. в 10:25, Pavel Tupitsyn :
> 
>> 
>> Igniters,
>> 
>> I've filed a blocker - release configurations on TeamCity should be fixed
>> after recent .NET project structure refactoring:
>> https://issues.apache.org/jira/browse/IGNITE-15779
>> 
>> I'm on vacation right now with limited internet access, I'll work on this
>> ASAP next week.
>> 
>> On Wed, Oct 13, 2021 at 2:33 PM Nikita Amelchev 
>> wrote:
>> 
>>> Igniters,
>>> 
>>> Scope freeze is planned for Friday, October 15.
>>> I suggest creating the release branch on that date.
>>> 
>>> The wiki page with the release info. [1] Please, check the fix version
>>> of your issues.
>>> 
>>> There are no unresolved blockers.
>>> There are 3 important issues in the review state. [2]
>>> 
>>> Also, please, pay attention to unresolved documentation issues. [3]
>>> 
>>> [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.12
>>> [2]
>>> https://issues.apache.org/jira/issues/?jql=(resolution%20%3D%20Unresolved%20AND%20project%20%3D%20%27Ignite%27%20AND%20type%20in%20(%22New%20Feature%22%2C%20Task%2C%20Sub-task%2C%20Improvement)%20AND%20fixVersion%20in%20(%272.12%27)%20AND%20(component%20is%20EMPTY%20OR%20component%20not%20in%20(documentation))%20AND%20(labels%20in%20(%27important%27)%20OR%20Flags%20%3D%20Important))%20order%20by%20summary
>>> [3]
>>> 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%20NOT%20IN%20(Resolved%2C%20Closed)%20AND%20component%20in%20(documentation)%20ORDER%20BY%20priority%20%20%20%20%20%20%20%20%20
>>> 
>>> пт, 1 окт. 2021 г. в 19:06, Pavel Tupitsyn :
 
 I'm working on IGNITE-15504 and plan to finish it early next week.
 
 On Fri, Oct 1, 2021 at 6:08 PM Nikita Amelchev 
>>> wrote:
 
> Igniters,
> 
> I have created the wiki page for the 2.12 release. [1]
> 
> The release scope contains 1 issue that is marked as a blocker:
> IGNITE-15504 .NET: SDK 2.1 is out of support, make sure project can be
> developed with newer SDKs [2]
> 
> Folks, do not forget to document features (65 issues still not
>>> resolved).
> [3]
> 
> Maxim, Ivan,
> +1 to add these issues to the 2.12 scope.
> 
> [1]
>>> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.12
> [2] https://issues.apache.org/jira/browse/IGNITE-15504
> [3]
> 
>>> 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%20NOT%20IN%20(Resolved%2C%20Closed)%20AND%20component%20in%20(documentation)%20ORDER%20BY%20priority%20%20%20%20%20%20%20%20%20
> 
> ср, 29 сент. 2021 г. в 11:28, Ivan Daschinsky :
>> 
>> Created issues related building ODBC module, running C++ suites and
>> removing VS project files
>> 
>> 1. https://issues.apache.org/jira/browse/IGNITE-15637
>> 2.https://issues.apache.org/jira/browse/IGNITE-15636
>> 
>> вс, 26 сент. 2021 г. в 19:50, Ivan Daschinsky :
>> 
>>> +1
>>> 
>>> Let's consider building odbc driver using Visual C++ 2017?
>>> 
>>> 2015, 2017 and 2019 share the same redistributable package and it
>>> is
> the
>>> default one in Windows 10.
>>> 
>>> Also, let's remove vs project files, since the most of you all
>>> agree
> that
>>> it is redundant.
>>> 
>>> If both suggestions are ok, I will create ticketa soon.
>>> 
>>> вс, 26 сент. 2021 г., 17:10 Pavel Tupitsyn :
>>> 
 +1
 
 On Fri, Sep 24, 2021 at 8:04 PM Maxim Muzafarov <
>>> mmu...@apache.org>
 wrote:
 
> Hello Nikita,
> 
> +1 if you will lead this release.
> 
> 
> I'd suggest including into the release scope this one issue too:
> 
> Snapshot restore must support restoring with indexes rebuild
> https://issues.apache.org/jira/browse/IGNITE-14744
> 
> Hopefully, it will be completed by the end of October.
> 
> On Fri, 24 Sept 2021 at 19:48, Nikita Amelchev <
> namelc...@apache.org>
> wrote:
>> 
>> Dear Ignite Community!
>> 
>> I suggest starting Apache Ignite 2.12 release activities.
>> 
>> For now, we've accumulated a hundred resolved issues with new
> features
>> and bug fixes which are waiting for their release date. For
> example,
>> 
>> CDC Application
>> Index Query API
>> Utility for analyzing indexes
>> Java compute tasks for C++
>> SQL commands statistics
>> etc.
>> 
>> I want to propose myself to be the 

Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3

[Petr Ivanov]

Generation is a good one.
Also we can use variant from DEB packaging versioning — EPOCH.

> On 17 Oct 2021, at 02:52, Valentin Kulichenko  
> wrote:
> 
> Folks,
> 
> Since there are controversial opinions regarding the topic, I've cancelled
> the vote and would like to resurrect the discussion.
> 
> There are a couple of items that I would like to hear your opinions on.
> 
> 1. I still propose to have a separate Confluence space for Ignite 3. This
> makes total sense to me - Ignite 2 and 3 have such different architectures,
> that mixing their internal documentations is really confusing. The same
> goes for IEPs.
> 2. If we create a mandatory field to Jira as we discussed, what should be
> the name? Current suggestions are "Architecture" and "Generation". Are
> there any other ideas?
> 
> Please let me know your thoughts.
> 
> -Val
> 
> On Tue, Oct 5, 2021 at 1:34 AM Ivan Pavlukhin  wrote:
> 
>> Sorry, If I missed something in the thread but in case of a separate
>> JIRA project how are users supposed to create e.g. bug tickets? How
>> can we make sure that users will not use a wrong JIRA project often?
>> 
>> 2021-10-05 2:50 GMT+03:00, Valentin Kulichenko <
>> valentin.kuliche...@gmail.com>:
>>> Ivan,
>>> 
>>> I'm not pushing, I'm trying to apply the lazy consensus. It soon will be
>> a
>>> whole month since I've started the discussion - more than enough to
>> express
>>> concerns and provide alternative suggestions. Please keep in mind that we
>>> are trying to address a very specific technical problem that influences
>> the
>>> development. "Do nothing" is not really an option here.
>>> 
>>> Either way, I will put the initial suggestion for the vote.
>>> 
>>> -Val
>>> 
>>> On Thu, Sep 30, 2021 at 12:24 AM Ivan Pavlukhin 
>>> wrote:
>>> 
>>>> Val,
>>>> 
>>>>> Let's discuss this until the end of the week. If there is no clear
>>>> picture on option #2 by then, I suggest we go with #1.
>>>> 
>>>> For a moment I felt that the proposal is pushed. Let's not do so. The
>>>> subject is very important, years impact I suppose. And the best way
>>>> here is to reach absolute consensus. Without tight timelines so far.
>>>> In case if we fail with consensus we can arrange formal voting.
>>>> 
>>>> 2021-09-29 14:34 GMT+03:00, Petr Ivanov :
>>>>> I am watching how Apache Ignite does evolve for over a 3 years already
>>>> and
>>>>> see that such hidden (almost no Open Source Community points could be
>>>>> achieved for refactoring and addressing something that is not directly
>>>>> project's source executable code) issues drown under constant pressure
>>>>> of
>>>>> new features and releases.
>>>>> 
>>>>> I have never created issues for Maven build refactoring (for
>> instanced)
>>>>> because I understand that 1) it is almost impossible for current tech
>>>> debt
>>>>> already accumulated and 2) to won't be welcomed by community because
>> of
>>>>> indirect relationship to main project's goals.
>>>>> Considering other parts, please, note [1], [2], [3], [4], [5], [6],
>>>>> [7],
>>>> [8]
>>>>> and many many more issues that have no separate ticket.
>>>>> 
>>>>> My point — such technical debt is overwhelming and will be never ever
>>>>> approached.
>>>>> That is one of the reasons why Ignite 3 being built from scratch,
>>>>> having
>>>> in
>>>>> mind all mistakes we've already made and lots of errors we will never
>>>>> do
>>>>> just because there would be no legacy basic for that.
>>>>> 
>>>>> 
>>>>> 
>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-7190
>>>>> [2] https://issues.apache.org/jira/browse/IGNITE-7326
>>>>> [3] https://issues.apache.org/jira/browse/IGNITE-7672
>>>>> [4] https://issues.apache.org/jira/browse/IGNITE-8496
>>>>> [5] https://issues.apache.org/jira/browse/IGNITE-9866
>>>>> [6] https://issues.apache.org/jira/browse/IGNITE-10600
>>>>> [7] https://issues.apache.org/jira/browse/IGNITE-10683
>>>>> [8] https://issues.apache.org/jira/browse/IGNITE-10696
>>>>> 
>>>>> 
>>>>> 
>&g

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

[Petr Ivanov]

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 is Ignite distributive.
>>> 
>>> 
 13 окт. 2021 г., в 14:32, Maxim Muzafarov  написал(а):
 
 Stephen,
 
 I guess the required classes of IP-finders should be in the classpath
 (libs directory). Currently, they are copied from the optional
 directory of the ignite binary package but would be copied from an
 appropriate ignite extension binary package. Probably I'm missing
 something but almost nothing changes in that process from my point of
 view. The documentation pages will be updated prior to the release.
 
 On Wed, 13 Oct 2021 at 13:44, Stephen Darlington
  wrote:
> 
> I understand the motivation from a development point of view, but how 
> will this work for end users? Currently, the documentation talks about 
> extensions only in terms of importing maven dependencies (download.cgi 
> ). If I’m trying to 
> start a cluster on Azure, how does that work? Do I need to build my own 
> server?
> 
> Regards,
> Stephen
> 
>> On 13 Oct 2021, at 11:35, Nikita Amelchev  wrote:
>> 
>> +1 to migrate and include to the Ignite 2.12 scope
>> 
>> пн, 20 сент. 2021 г. в 17:09, Denis Magda :
>>> 
>>> Perfect, thanks, Maxim!
>>> 
>>> -
>>> Denis
>>> 
>>> 
>>> On Mon, Sep 20, 2021 at 8:29 AM Maxim Muzafarov  
>>> wrote:
>>> 
 Folks,
 
 
 I've created an issue [1] to move all cloud-based IP-finders to the
 ignite-extensions. The motivation is the same as with migration of
 Spring Data integration - to remove integration dependency of the
 release cycle on Ignite releases.
 
 
 [1] https://issues.apache.org/jira/browse/IGNITE-15541
 
>> 
>> 
>> 
>> --
>> Best wishes,
>> Amelchev Nikita
> 
> 
>>> 
> 
> 

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

[Petr Ivanov]

+1


Those parts still very optional nowadays.

> On 20 Sep 2021, at 15:29, Maxim Muzafarov  wrote:
> 
> Folks,
> 
> 
> I've created an issue [1] to move all cloud-based IP-finders to the
> ignite-extensions. The motivation is the same as with migration of
> Spring Data integration - to remove integration dependency of the
> release cycle on Ignite releases.
> 
> 
> [1] https://issues.apache.org/jira/browse/IGNITE-15541

Re: [VOTE] Create separate Jira project and Confluence space for Ignite 3

[Petr Ivanov]

+1

> On 5 Oct 2021, at 02:52, Valentin Kulichenko  
> wrote:
> 
> Hello Community,
> 
> As discussed in [1], I would like to propose the creation of a separate
> Jira project and Confluence space for Ignite 3.
> 
> Ignite 2 and Ignite 3 are developed in parallel in separate repos, so we
> need a clear separation in other tools as well - this will help to
> streamline the development process. Please refer to the discussion for more
> details.
> 
> [1]
> https://lists.apache.org/thread.html/rdcad3fc64b9f3a848c93089baae2bee1124a97869a94f4a04dd80fdf%40%3Cdev.ignite.apache.org%3E
> 
> Voting options:
> 
>   - +1 - Agree with the suggestion
>   - 0 - Don't care much about the suggestion
>   - -1 - Disagree with the suggestion
> 
> This is a majority vote.
> 
> Voting ends in 72 hours, at 5pm PDT on October 7:
> https://www.timeanddate.com/counters/fullscreen.html?mode=a=20211007T17=2021=10=7=17=0=0=224
> 
> -Val

Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3

[Petr Ivanov]

I am watching how Apache Ignite does evolve for over a 3 years already and see 
that such hidden (almost no Open Source Community points could be achieved for 
refactoring and addressing something that is not directly project's source 
executable code) issues drown under constant pressure of new features and 
releases.

I have never created issues for Maven build refactoring (for instanced) because 
I understand that 1) it is almost impossible for current tech debt already 
accumulated and 2) to won't be welcomed by community because of indirect 
relationship to main project's goals.
Considering other parts, please, note [1], [2], [3], [4], [5], [6], [7], [8] 
and many many more issues that have no separate ticket.

My point — such technical debt is overwhelming and will be never ever 
approached.
That is one of the reasons why Ignite 3 being built from scratch, having in 
mind all mistakes we've already made and lots of errors we will never do just 
because there would be no legacy basic for that.



[1] https://issues.apache.org/jira/browse/IGNITE-7190
[2] https://issues.apache.org/jira/browse/IGNITE-7326
[3] https://issues.apache.org/jira/browse/IGNITE-7672
[4] https://issues.apache.org/jira/browse/IGNITE-8496
[5] https://issues.apache.org/jira/browse/IGNITE-9866
[6] https://issues.apache.org/jira/browse/IGNITE-10600
[7] https://issues.apache.org/jira/browse/IGNITE-10683
[8] https://issues.apache.org/jira/browse/IGNITE-10696





> On 29 Sep 2021, at 14:14, Nikolay Izhikov  wrote:
> 
>> — issues related to Maven build? possible Gradle upgrade?
> 
> I’m not aware of the issues.
> Can you, please, send a tickets or description of existing issues?
> Anyway, it seems change of build tool can be done at any time we want
> 
>> — issues related to run scripts?
>> — issues related to release and delivery processes and scripts?
> 
> I’m not aware of those too.
> Can you point to then, please?
> 
>> Are they going to be addressed during Apache Ignite evolution too?
> 
> Yes, from my point of view.
> 
>> 29 сент. 2021 г., в 14:03, Petr Ivanov  написал(а):
>> 
>> And what about:
>> — issues related to Maven build? possible Gradle upgrade?
>> — issues related to run scripts?
>> — issues related to release and delivery processes and scripts?
>> 
>> Are they going to be addressed during Apache Ignite evolution too?
>> 
>>> On 29 Sep 2021, at 13:47, Nikolay Izhikov  wrote:
>>> 
>>>> Does you vision of evolutionary improvement involve technical debt 
>>>> addressing
>>> 
>>> Yes, of course.
>>> 
>>> My vision was the following (from the bird eye):
>>> 
>>> - 2.20 - removals of LOCAL caches, MVCC and other abandoned features. (User 
>>> API doesn’t change).
>>> - 2.30 - replace static XML configuration with the new dynamic approach.
>>> - 2.40 - replace H2 SQL engine with the Calcite
>>> 
>>> etc. 
>>> 
>>> Versions depends on feature readiness.
>>> 
>>> Anyway, I step back with the initial Ignite3 development, because, don’t 
>>> want to interfere the progress.
>>> 
>>> Respect to the developers who have courage to develop such complex things 
>>> from scratch.
>>> 
>>>> 29 сент. 2021 г., в 12:55, Petr Ivanov  написал(а):
>>>> 
>>>> 
>>>>> I believe that we should improve Ignite evolutionary and not 
>>>>> revolutionary.
>>>>> First of all, change user API with the slow improvements step by step.
>>>> 
>>>> Nikolay,
>>>> 
>>>> Does you vision of evolutionary improvement involve technical debt 
>>>> addressing?
>>>> 
>>>> 
>>>>> 
>>>>> 
>>>>>> 29 сент. 2021 г., в 11:43, Ilya Kasnacheev  
>>>>>> написал(а):
>>>>>> 
>>>>>> Hello!
>>>>>> 
>>>>>> If we go the second route, we can call the field "Generation".
>>>>>> 
>>>>>> Generation: Ignite 2.x
>>>>>> Generation: Ignite 3
>>>>>> 
>>>>>> (no new tickets should ever be filed for Ignite 1.x but if they are, they
>>>>>> should go to the first Generation)
>>>>>> 
>>>>>> Regards.
>>>>>> -- 
>>>>>> Ilya Kasnacheev
>>>>>> 
>>>>>> 
>>>>>> ср, 29 сент. 2021 г. в 00:33, Valentin Kulichenko <
>>>>>> valentin.kuliche...@gmail.com>:
>>>>>> 
>>>>>>>

Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3

[Petr Ivanov]

And what about:
 — issues related to Maven build? possible Gradle upgrade?
 — issues related to run scripts?
 — issues related to release and delivery processes and scripts?

Are they going to be addressed during Apache Ignite evolution too?

> On 29 Sep 2021, at 13:47, Nikolay Izhikov  wrote:
> 
>> Does you vision of evolutionary improvement involve technical debt addressing
> 
> Yes, of course.
> 
> My vision was the following (from the bird eye):
> 
> - 2.20 - removals of LOCAL caches, MVCC and other abandoned features. (User 
> API doesn’t change).
> - 2.30 - replace static XML configuration with the new dynamic approach.
> - 2.40 - replace H2 SQL engine with the Calcite
> 
> etc. 
> 
> Versions depends on feature readiness.
> 
> Anyway, I step back with the initial Ignite3 development, because, don’t want 
> to interfere the progress.
> 
> Respect to the developers who have courage to develop such complex things 
> from scratch.
> 
>> 29 сент. 2021 г., в 12:55, Petr Ivanov  написал(а):
>> 
>> 
>>> I believe that we should improve Ignite evolutionary and not revolutionary.
>>> First of all, change user API with the slow improvements step by step.
>> 
>> Nikolay,
>> 
>> Does you vision of evolutionary improvement involve technical debt 
>> addressing?
>> 
>> 
>>> 
>>> 
>>>> 29 сент. 2021 г., в 11:43, Ilya Kasnacheev  
>>>> написал(а):
>>>> 
>>>> Hello!
>>>> 
>>>> If we go the second route, we can call the field "Generation".
>>>> 
>>>> Generation: Ignite 2.x
>>>> Generation: Ignite 3
>>>> 
>>>> (no new tickets should ever be filed for Ignite 1.x but if they are, they
>>>> should go to the first Generation)
>>>> 
>>>> Regards.
>>>> -- 
>>>> Ilya Kasnacheev
>>>> 
>>>> 
>>>> ср, 29 сент. 2021 г. в 00:33, Valentin Kulichenko <
>>>> valentin.kuliche...@gmail.com>:
>>>> 
>>>>> As for the original topic, we need to come to a solution. Let me summarize
>>>>> what we've discussed so far.
>>>>> 
>>>>> -PROBLEM-
>>>>> 
>>>>> Ignite 3 is the next major version of Apache Ignite. It targets the same
>>>>> use cases and provides a similar set of features as Ignite 2. At the same
>>>>> time, Ignite 2 and Ignite 3 are *technically* separate projects. They are
>>>>> developed in different repositories (and therefore are based on different
>>>>> codebases) and implement different internal architectures. To achieve a
>>>>> more efficient development process, we need to create a clear separation
>>>>> between 2.x and 3.x within *development resources* (Jira and Confluence).
>>>>> 
>>>>> -POSSIBLE SOLUTIONS-
>>>>> 
>>>>> 1. Create a separate Jira project and Confluence space for Ignite 3
>>>>> (initial suggestion).
>>>>> 2. Add a *mandatory* field in Jira to identify whether a ticket belongs to
>>>>> 2.x or 3.x.
>>>>> 
>>>>> If we go with #2, there are still several things to figure out:
>>>>> 
>>>>> - What is the name of this field? It needs to be intuitive to anyone who
>>>>> joins the community.
>>>>> - We need to make sure that Ignite 3 tickets are not mapped to 2.x
>>>>> versions, and vice versa. Can we restrict this in Jira? Or we will have
>>>>> to
>>>>> monitor this manually?
>>>>> - What do we do with Confluence?
>>>>> 
>>>>> Nikolay, Ilya, Denis, and others who opposed the initial suggestion: if 
>>>>> you
>>>>> still prefer the second option, could you please address the points above?
>>>>> I don't think it can be treated as an actual suggestion until we cover
>>>>> these details.
>>>>> 
>>>>> Let's discuss this until the end of the week. If there is no clear picture
>>>>> on option #2 by then, I suggest we go with #1.
>>>>> 
>>>>> -Val
>>>>> 
>>>>> On Tue, Sep 28, 2021 at 11:22 PM Valentin Kulichenko <
>>>>> valentin.kuliche...@gmail.com> wrote:
>>>>> 
>>>>>> Folks,
>>>>>> 
>>>>>> Versioning is a separate topic. We agreed on the current scheme in March
>>>>&g

Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3

[Petr Ivanov]

> I believe that we should improve Ignite evolutionary and not revolutionary.
> First of all, change user API with the slow improvements step by step.

Nikolay,

Does you vision of evolutionary improvement involve technical debt addressing?


> 
> 
>> 29 сент. 2021 г., в 11:43, Ilya Kasnacheev  
>> написал(а):
>> 
>> Hello!
>> 
>> If we go the second route, we can call the field "Generation".
>> 
>> Generation: Ignite 2.x
>> Generation: Ignite 3
>> 
>> (no new tickets should ever be filed for Ignite 1.x but if they are, they
>> should go to the first Generation)
>> 
>> Regards.
>> -- 
>> Ilya Kasnacheev
>> 
>> 
>> ср, 29 сент. 2021 г. в 00:33, Valentin Kulichenko <
>> valentin.kuliche...@gmail.com>:
>> 
>>> As for the original topic, we need to come to a solution. Let me summarize
>>> what we've discussed so far.
>>> 
>>> -PROBLEM-
>>> 
>>> Ignite 3 is the next major version of Apache Ignite. It targets the same
>>> use cases and provides a similar set of features as Ignite 2. At the same
>>> time, Ignite 2 and Ignite 3 are *technically* separate projects. They are
>>> developed in different repositories (and therefore are based on different
>>> codebases) and implement different internal architectures. To achieve a
>>> more efficient development process, we need to create a clear separation
>>> between 2.x and 3.x within *development resources* (Jira and Confluence).
>>> 
>>> -POSSIBLE SOLUTIONS-
>>> 
>>> 1. Create a separate Jira project and Confluence space for Ignite 3
>>> (initial suggestion).
>>> 2. Add a *mandatory* field in Jira to identify whether a ticket belongs to
>>> 2.x or 3.x.
>>> 
>>> If we go with #2, there are still several things to figure out:
>>> 
>>>  - What is the name of this field? It needs to be intuitive to anyone who
>>>  joins the community.
>>>  - We need to make sure that Ignite 3 tickets are not mapped to 2.x
>>>  versions, and vice versa. Can we restrict this in Jira? Or we will have
>>> to
>>>  monitor this manually?
>>>  - What do we do with Confluence?
>>> 
>>> Nikolay, Ilya, Denis, and others who opposed the initial suggestion: if you
>>> still prefer the second option, could you please address the points above?
>>> I don't think it can be treated as an actual suggestion until we cover
>>> these details.
>>> 
>>> Let's discuss this until the end of the week. If there is no clear picture
>>> on option #2 by then, I suggest we go with #1.
>>> 
>>> -Val
>>> 
>>> On Tue, Sep 28, 2021 at 11:22 PM Valentin Kulichenko <
>>> valentin.kuliche...@gmail.com> wrote:
>>> 
>>>> Folks,
>>>> 
>>>> Versioning is a separate topic. We agreed on the current scheme in March
>>>> [1]. If someone thinks we need to change it, please create a new thread
>>> and
>>>> present your suggestions.
>>>> 
>>>> [1]
>>>> 
>>> https://lists.apache.org/thread.html/r17ebaad35ca2bd70e716e67683ae7fec9bd97372b6cc57a7e9c81f9d%40%3Cdev.ignite.apache.org%3E
>>>> 
>>>> -Val
>>>> 
>>>> On Tue, Sep 28, 2021 at 12:37 PM Petr Ivanov 
>>> wrote:
>>>> 
>>>>> Seems rational.
>>>>> 
>>>>> 
>>>>> But still 2.11.0 and 21.1.0 for the time being will look like similar or
>>>>> error in either version...
>>>>> 
>>>>> 
>>>>>> On 27 Sep 2021, at 18:11, Ivan Pavlukhin  wrote:
>>>>>> 
>>>>>> I mean that Ignite 2.x will continue to use old scheme and Ignite 3
>>>>>> will be e.g. Ignite 21.1 and so on.
>>>>>> 
>>>>>> 2021-09-27 14:57 GMT+03:00, Petr Ivanov :
>>>>>>> How will not they clash if version is based only on date?
>>>>>>> 
>>>>>>>> On 27 Sep 2021, at 14:33, Ivan Pavlukhin 
>>> wrote:
>>>>>>>> 
>>>>>>>> Today it is quite common to use calendar-based versioning scheme,
>>> e.g.
>>>>>>>> [1]. We can consider it for Ignite 3. Luckily versions will not
>>> clash.
>>>>>>>> 
>>>>>>>> [1] https://www.cockroachlabs.com/docs/releases/index.html
>>>>>>>> 
>>>>>

Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3

[Petr Ivanov]

Seems rational.


But still 2.11.0 and 21.1.0 for the time being will look like similar or error 
in either version...


> On 27 Sep 2021, at 18:11, Ivan Pavlukhin  wrote:
> 
> I mean that Ignite 2.x will continue to use old scheme and Ignite 3
> will be e.g. Ignite 21.1 and so on.
> 
> 2021-09-27 14:57 GMT+03:00, Petr Ivanov :
>> How will not they clash if version is based only on date?
>> 
>>> On 27 Sep 2021, at 14:33, Ivan Pavlukhin  wrote:
>>> 
>>> Today it is quite common to use calendar-based versioning scheme, e.g.
>>> [1]. We can consider it for Ignite 3. Luckily versions will not clash.
>>> 
>>> [1] https://www.cockroachlabs.com/docs/releases/index.html
>>> 
>>> 2021-09-27 10:49 GMT+03:00, Petr Ivanov :
>>>> That name will definitely confuse Jira users.
>>>> 
>>>> Let's stick to basic devision by 2.x and 3.x — it seems most intuitive
>>>> and
>>>> has lots of examples inside ASF, look at the Tomcat for instance.
>>>> 
>>>>> On 25 Sep 2021, at 21:05, Saikat Maitra 
>>>>> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I like the major version update like Ignite 3.0 but if we were to come
>>>>> up
>>>>> with a name my other suggestion would be
>>>>> 
>>>>> Ignite-kernel
>>>>> 
>>>>> kernel - for the central or most important part of something
>>>>> 
>>>>> Also taken references from Compute kernel - a routine compiled for high
>>>>> throughput accelerators
>>>>> 
>>>>> https://en.wikipedia.org/wiki/Compute_kernel
>>>>> 
>>>>> Regards,
>>>>> Saikat
>>>>> 
>>>>> 
>>>>> On Sat, Sep 25, 2021 at 3:12 AM Valentin Kulichenko <
>>>>> valentin.kuliche...@gmail.com> wrote:
>>>>> 
>>>>>> Kafka and Spark didn't split codebases (at least to my knowledge).
>>>>>> Separating codebases was the fundamental step, everything else is a
>>>>>> technicality.
>>>>>> 
>>>>>> Having said that, I will be OK with your suggestion as I don't really
>>>>>> see
>>>>>> a
>>>>>> difference, although I'm not sure we will be able to come up with a
>>>>>> name
>>>>>> that is more intuitive than a separate project :)
>>>>>> 
>>>>>> Let's see what others think.
>>>>>> 
>>>>>> -Val
>>>>>> 
>>>>>> On Sat, Sep 25, 2021 at 12:23 AM Denis Magda 
>>>>>> wrote:
>>>>>> 
>>>>>>> Moving the discussion back to the dev list.
>>>>>>> 
>>>>>>> Val, Andrey, for that purpose we can ask INFRA to create a
>>>>>>> special mandatory field such as "Architecture" with two predefined
>>>>>> values -
>>>>>>> "Ignite 2.x" and "Ignite 3.x". Come up with a better name, it needs
>>>>>>> to
>>>>>>> be
>>>>>>> intuitive enough even for users who submit issues. What disturbs me
>>>>>>> is
>>>>>> that
>>>>>>> neither Kafka nor Spark have a different project for the recently
>>>>>> released
>>>>>>> versions 3. A different GitHub project is not that disturbing.
>>>>>>> 
>>>>>>> -
>>>>>>> Denis
>>>>>>> 
>>>>>>> 
>>>>>>> On Fri, Sep 24, 2021 at 4:09 AM Valentin Kulichenko <
>>>>>>> valentin.kuliche...@gmail.com> wrote:
>>>>>>> 
>>>>>>>> Denis,
>>>>>>>> 
>>>>>>>> From a purely technical perspective, these are indeed two separate
>>>>>>>> projects, because they are based on different codebases. The split
>>>>>> you're
>>>>>>>> talking about happened a year ago, when we created the repo for
>>>>>>>> Ignite
>>>>>> 3.
>>>>>>>> This significantly differs from the 1.x->2.x transition, as these
>>>>>>>> two
>>>>>>>> shared the codebase.
>>>>>>>> 
>>>>>>

Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3

[Petr Ivanov]

How will not they clash if version is based only on date?

> On 27 Sep 2021, at 14:33, Ivan Pavlukhin  wrote:
> 
> Today it is quite common to use calendar-based versioning scheme, e.g.
> [1]. We can consider it for Ignite 3. Luckily versions will not clash.
> 
> [1] https://www.cockroachlabs.com/docs/releases/index.html
> 
> 2021-09-27 10:49 GMT+03:00, Petr Ivanov :
>> That name will definitely confuse Jira users.
>> 
>> Let's stick to basic devision by 2.x and 3.x — it seems most intuitive and
>> has lots of examples inside ASF, look at the Tomcat for instance.
>> 
>>> On 25 Sep 2021, at 21:05, Saikat Maitra  wrote:
>>> 
>>> Hi,
>>> 
>>> I like the major version update like Ignite 3.0 but if we were to come up
>>> with a name my other suggestion would be
>>> 
>>> Ignite-kernel
>>> 
>>> kernel - for the central or most important part of something
>>> 
>>> Also taken references from Compute kernel - a routine compiled for high
>>> throughput accelerators
>>> 
>>> https://en.wikipedia.org/wiki/Compute_kernel
>>> 
>>> Regards,
>>> Saikat
>>> 
>>> 
>>> On Sat, Sep 25, 2021 at 3:12 AM Valentin Kulichenko <
>>> valentin.kuliche...@gmail.com> wrote:
>>> 
>>>> Kafka and Spark didn't split codebases (at least to my knowledge).
>>>> Separating codebases was the fundamental step, everything else is a
>>>> technicality.
>>>> 
>>>> Having said that, I will be OK with your suggestion as I don't really see
>>>> a
>>>> difference, although I'm not sure we will be able to come up with a name
>>>> that is more intuitive than a separate project :)
>>>> 
>>>> Let's see what others think.
>>>> 
>>>> -Val
>>>> 
>>>> On Sat, Sep 25, 2021 at 12:23 AM Denis Magda  wrote:
>>>> 
>>>>> Moving the discussion back to the dev list.
>>>>> 
>>>>> Val, Andrey, for that purpose we can ask INFRA to create a
>>>>> special mandatory field such as "Architecture" with two predefined
>>>> values -
>>>>> "Ignite 2.x" and "Ignite 3.x". Come up with a better name, it needs to
>>>>> be
>>>>> intuitive enough even for users who submit issues. What disturbs me is
>>>> that
>>>>> neither Kafka nor Spark have a different project for the recently
>>>> released
>>>>> versions 3. A different GitHub project is not that disturbing.
>>>>> 
>>>>> -
>>>>> Denis
>>>>> 
>>>>> 
>>>>> On Fri, Sep 24, 2021 at 4:09 AM Valentin Kulichenko <
>>>>> valentin.kuliche...@gmail.com> wrote:
>>>>> 
>>>>>> Denis,
>>>>>> 
>>>>>> From a purely technical perspective, these are indeed two separate
>>>>>> projects, because they are based on different codebases. The split
>>>> you're
>>>>>> talking about happened a year ago, when we created the repo for Ignite
>>>> 3.
>>>>>> This significantly differs from the 1.x->2.x transition, as these two
>>>>>> shared the codebase.
>>>>>> 
>>>>>> For the same reason, a bug filed for 2.x can't be just transitioned to
>>>>>> 3.x. It will either not exist in 3.x in the first place, or will
>>>> require
>>>>> a
>>>>>> completely different fix, which will mean two different tickets.
>>>>>> 
>>>>>> That said, I still believe that Ignite 2 and Ignite 3 are just
>>>> different
>>>>>> versions of the same product, because, as you correctly mentioned,
>>>>>> they
>>>>>> target "same users, community, use cases". At the same time, they are
>>>>>> developed as different projects on the technical level. Let's not
>>>> confuse
>>>>>> these two aspects with each other - they are largely orthogonal.
>>>>>> 
>>>>>> At this point, creating a Jira project doesn't change anything
>>>>>> fundamentally. It's only about ease of use of our tooling and
>>>>>> efficient
>>>>>> ticket management.
>>>>>> 
>>>>>> -Val
>>>>>> 
>>>>>> On Thu, Sep 

Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3

[Petr Ivanov]

t;>>> wrote:
>>>>> 
>>>>>> Val,
>>>>>> 
>>>>>> I don't see any issues having different projects under Ignite's brand
>>>>>> from the developer's side except the versioning issue. This is a bad
>>>>>> case when two different projects must have dependent versions and
>> even
>>>>>> worse when some marketing things affect the development and release
>>>>>> processes.
>>>>>> 
>>>>>> I agree with Nikolay and Ilya - the right way here is having
>>>>>> "Ignite" and versioning started from zero. However,
>> both
>>>>>> of Ignite's can easily co-exist.
>>>>>> 
>>>>>> On Tue, 21 Sept 2021 at 22:13, Valentin Kulichenko
>>>>>>  wrote:
>>>>>>> 
>>>>>>> Ilya,
>>>>>>> 
>>>>>>> What exactly is this different focus and different values? Why
>>> exactly
>>>>>> do you think Ignite 3 will never cover all the current features? And
>>> why is
>>>>>> this the criteria in the first place? I work on both Ignite 2 and
>>> Ignite 3
>>>>>> almost every day and I simply don't think all this is true. I
>> honestly
>>>>>> can't understand what this fuss is all about.
>>>>>>> 
>>>>>>> Folks, quite frankly, this discussion seems counterproductive at
>> this
>>>>>> point. Are there any particular suggestions? If so, let's discuss
>> them.
>>>>>> Otherwise, let's just do some coding - isn't that why we are all
>> here?
>>> :)
>>>>>>> 
>>>>>>> -Val
>>>>>>> 
>>>>>>> On Tue, Sep 21, 2021 at 9:52 PM Ilya Kasnacheev <
>>>>>> ilya.kasnach...@gmail.com> wrote:
>>>>>>>> 
>>>>>>>> Hello!
>>>>>>>> 
>>>>>>>> I concur with Nikolay. Maybe Ignite 3 should be called "Ignite
>> >>>>> adverb>" because it is a product with a different focus and values
>>> which
>>>>>> has no plans to cover the entirety of Ignite's features.
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> --
>>>>>>>> Ilya Kasnacheev
>>>>>>>> 
>>>>>>>> 
>>>>>>>> вт, 21 сент. 2021 г. в 17:56, Nikolay Izhikov <
>> nizhi...@apache.org
>>>> :
>>>>>>>>> 
>>>>>>>>> Hello, Ignite PMC.
>>>>>>>>> 
>>>>>>>>> Is there any reason to keep calling Ignite3 as "Ignite"?
>>>>>>>>> 
>>>>>>>>> It seems to me that from the very beginning Ignite3 is a new
>>>>>> database engine built on completely new architecture.
>>>>>>>>> Ignite2 and Ignite3 has nothing similar except the name. All is
>>>>>> different
>>>>>>>>> - source code.
>>>>>>>>> - repository.
>>>>>>>>> - features.
>>>>>>>>> - API.
>>>>>>>>> - road map.
>>>>>>>>> - contributors.
>>>>>>>>> - contribution rules.
>>>>>>>>> - release cycle.
>>>>>>>>> *** you are here ***
>>>>>>>>> - jira
>>>>>>>>> - confluence
>>>>>>>>> 
>>>>>>>>> Should we accept the fact that thing we calling as "Ignite3" is
>>> just
>>>>>> another project?
>>>>>>>>> Can you, please, share your vision on how Ignite and Ignite3
>> should
>>>>>> coexists?
>>>>>>>>> 
>>>>>>>>> вт, 21 сент. 2021 г. в 17:13, Dmitry Pavlov >> :
>>>>>>>>>> 
>>>>>>>>>> Ok, if nobody minds, I'll create spaces a bit later.
>>>>>>>>>> 
>>>>>>>>>> I hope it is not too urgent.
>>>>>>>>>> 
>>>>>>>>>> Sincerely,
>>>>>>>>>> Dmitriy Pavlov
>>>>>>>>>> 
>>>>>>>>>> On 2021/09/21 10:37:42, Valentin Kulichenko <
>>>>>> valentin.kuliche...@gmail.com> wrote:
>>>>>>>>>>> Hi Dmitry,
>>>>>>>>>>> 
>>>>>>>>>>> According to Infra, this has to be done through
>>>>>> http://selfserve.apache.org/,
>>>>>>>>>>> but only PMC chairs have access.
>>>>>>>>>>> 
>>>>>>>>>>> Could you please assist with the creation of the Jira project
>>> and
>>>>>>>>>>> Confluence space?
>>>>>>>>>>> 
>>>>>>>>>>> -Val
>>>>>>>>>>> 
>>>>>>>>>>> On Tue, Sep 21, 2021 at 10:46 AM Valentin Kulichenko <
>>>>>>>>>>> valentin.kuliche...@gmail.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> Infra requests created:
>>>>>>>>>>>> 
>>>>>>>>>>>>   - https://issues.apache.org/jira/browse/INFRA-22349
>>>>>>>>>>>>   - https://issues.apache.org/jira/browse/INFRA-22350
>>>>>>>>>>>> 
>>>>>>>>>>>> -Val
>>>>>>>>>>>> 
>>>>>>>>>>>> On Mon, Sep 20, 2021 at 10:50 AM Petr Ivanov <
>>>>>> mr.wei...@gmail.com> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> +1
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Since we've agreed that there are two projects (that are
>>>>>> Ignite2 and
>>>>>>>>>>>>> Ignite3), separate development environments seem to be
>>> logical
>>>>>> and natural
>>>>>>>>>>>>> course of things.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 18 Sep 2021, at 12:42, Alexander Polovtcev <
>>>>>> alexpolovt...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>> This is a welcome proposal, because we already have some
>>>>>> pending Ignite
>>>>>>>>>>>>> 3
>>>>>>>>>>>>>> specific documents, and it is not clear where to put them
>>> at
>>>>>> the moment.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Sat, Sep 18, 2021 at 4:22 AM Valentin Kulichenko <
>>>>>>>>>>>>>> valentin.kuliche...@gmail.com> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Igniters,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I think it's clear to all of us that Ignite 2.x and 3.x
>>>>>> will coexist
>>>>>>>>>>>>> for a
>>>>>>>>>>>>>>> while. They are developed in separate Git repos, but we
>>>>>> still
>>>>>>>>>>>>> accumulate
>>>>>>>>>>>>>>> the tickets for both versions in the same Jira project,
>>>>>> which seems to
>>>>>>>>>>>>>>> complicate the ticket management.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> For example, we use the "ignite-3" label for 3.x
>> tickets,
>>>>>> but this
>>>>>>>>>>>>> approach
>>>>>>>>>>>>>>> is fragile. If someone forgets to add the label to a new
>>>>>> ticket, it's
>>>>>>>>>>>>>>> likely to be lost. We need a better separation.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> All the above is true for Wiki as well - we use a single
>>>>>> Confluence
>>>>>>>>>>>>> space.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I suggest creating a new Jira project and a new
>> Confluence
>>>>>> space for
>>>>>>>>>>>>> Ignite
>>>>>>>>>>>>>>> 3 and moving all the relevant tickets and pages there.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Any thoughts or objections?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> -Val
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> With regards,
>>>>>>>>>>>>>> Aleksandr Polovtcev
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>> 
>>>>> 
>>> 
>> 

Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3

[Petr Ivanov]

+1

Since we've agreed that there are two projects (that are Ignite2 and Ignite3), 
separate development environments seem to be logical and natural course of 
things.

> On 18 Sep 2021, at 12:42, Alexander Polovtcev  wrote:
> 
> +1
> This is a welcome proposal, because we already have some pending Ignite 3
> specific documents, and it is not clear where to put them at the moment.
> 
> On Sat, Sep 18, 2021 at 4:22 AM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
> 
>> Igniters,
>> 
>> I think it's clear to all of us that Ignite 2.x and 3.x will coexist for a
>> while. They are developed in separate Git repos, but we still accumulate
>> the tickets for both versions in the same Jira project, which seems to
>> complicate the ticket management.
>> 
>> For example, we use the "ignite-3" label for 3.x tickets, but this approach
>> is fragile. If someone forgets to add the label to a new ticket, it's
>> likely to be lost. We need a better separation.
>> 
>> All the above is true for Wiki as well - we use a single Confluence space.
>> 
>> I suggest creating a new Jira project and a new Confluence space for Ignite
>> 3 and moving all the relevant tickets and pages there.
>> 
>> Any thoughts or objections?
>> 
>> -Val
>> 
> 
> 
> -- 
> With regards,
> Aleksandr Polovtcev

Re: [DISCUSSION] Remove VS project from C++

[Petr Ivanov]

+1

Let's keep the project clean and on the verge of preferable tech stack.


> On 15 Sep 2021, at 12:02, Ivan Pavlukhin  wrote:
> 
> +1 for removing VS project
> 
> 2021-09-15 12:01 GMT+03:00, Nikolay Izhikov :
>> +1
>> 
>>> 15 сент. 2021 г., в 11:57, Pavel Tupitsyn 
>>> написал(а):
>>> 
>>> -1
>>> 
>>> This may become an obstacle for some of the users and I'm not sure how it
>>> improves anything.
>>> 
 3. Sometimes even maintainers forget to add test sources to VS projects
>>> [1]
>>> We can add an automatic check for this (in form of a test).
>>> 
>>> On Wed, Sep 15, 2021 at 10:28 AM Zhenya Stanilovsky
>>>  wrote:
>>> 
 
 
 completely support !
 
> Igniters!
> 
> Currently we have CMake build system, that works on Windows, Linux and
> MacOs flawlessly
> 
> 1. CMake is supported natively in VS 2019
> 2. CMake can generate VS projects for about 20 years flawlessly.
> 3. Sometimes even maintainers forget to add test sources to VS projects
 [1]
> 4. Currently on TC we build Ignite C++ on windows and linux flawlessly
> using CMake
> 5. VS projects are not backward compatible. We have to add manually (or
> by
> sed or patch) some dependencies in order to build current VS projects
> on
> newer versions of VS.
> 
> So I suggest simpy to remove VS projects because of reasons I've
> written
> above.
> 
> WDYT?
> 
> 
> 
> [1] --  https://issues.apache.org/jira/browse/IGNITE-15511
 
 
 
 
>> 
>> 
> 
> 
> -- 
> 
> Best regards,
> Ivan Pavlukhin

Re: Request for new TC suite

[Petr Ivanov]

Hi, Maksim.


File a ticket please and I will see it through.

> On 14 Sep 2021, at 17:24, Maksim Timonin  wrote:
> 
> Hi, Igniters!
> 
> This is a request for a new TC suite. This PR [1] introduces new
> functionality (IndexQuery API). I've prepared a suite [1] with tests
> related to this API. I'd like to have an opportunity to run those tests in
> a separate TC suite. Currently for my PR only, and after merge it should be
> enabled for the master branch.
> 
> How can I do this?
> 
> Thanks!
> 
> [1] https://github.com/apache/ignite/pull/9118
> [2] Path is
> ./modules/indexing/src/test/java/org/apache/ignite/cache/query/IndexQueryTestSuite.java

Re: [VOTE] Allow or prohibit usages of the Guava library methods

[Petr Ivanov]

We can run dependency:tree command and search for guava in transitive 
dependencies.
Can you describe how it should be and where should this explicit dependency 
reside?

> On 13 Sep 2021, at 17:15, Alexander Polovtcev  wrote:
> 
> Petr,
> In the original thread we decided to add Guava as an explicit dependency in
> order to avoid dependency conflicts and to possibly shade it later. If
> there exists a check that will scan for Guava imports in Ignite code, that
> would probably be nice to have.
> 
> On Mon, Sep 13, 2021 at 12:54 PM Petr Ivanov  wrote:
> 
>> Should we somehow restrict using this dependency in the project with Maven
>> (or any other tools)?
>> 
>>> On 13 Sep 2021, at 12:47, Alexander Polovtcev 
>> wrote:
>>> 
>>> The voting has finished and the results are the following:
>>> 
>>> [+1 Allow]: 1
>>> [-1 Prohibit]: 5
>>> 
>>> Therefore it is decided to prohibit using Guava in Ignite 3 codebase,
>> even
>>> if it is included as a direct dependency. I will add this to the Ignite 3
>>> code style document (or similar) as soon as it is available.
>>> 
>>> On Thu, Sep 9, 2021 at 6:28 PM Alexei Scherbakov <
>>> alexey.scherbak...@gmail.com> wrote:
>>> 
>>>> I've checked Guava's feature list and came to a conclusion it's
>> usefulness
>>>> has been diminished by switching to base java 11.
>>>> 
>>>> -1 for general use, but we can use some code parts then needed.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ср, 8 сент. 2021 г. в 14:09, Вячеслав Коптилин <
>> slava.kopti...@gmail.com>:
>>>> 
>>>>> -1
>>>>> I am leaning toward -1 because of vulnerability issues (that is a
>>>> possible
>>>>> case in general).
>>>>> 
>>>>> Thanks,
>>>>> S.
>>>>> 
>>>>> ср, 8 сент. 2021 г. в 12:13, Andrey Mashenkov <
>>>> andrey.mashen...@gmail.com
>>>>>> :
>>>>> 
>>>>>> -1
>>>>>> Supporting few copy-pasted methods is much easier than support
>>>>> dependencies
>>>>>> compatibility.
>>>>>> 
>>>>>> On Tue, Sep 7, 2021 at 7:42 PM Zhenya Stanilovsky
>>>>>>  wrote:
>>>>>> 
>>>>>>> 
>>>>>>> Aleksandr, thanks for this activity.
>>>>>>> -1 from my side, all my decisions are in linked discussion.
>>>>>>> 
>>>>>>>> Dear Igniters,
>>>>>>>> 
>>>>>>>> In this thread
>>>>>>>> <
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> https://lists.apache.org/thread.html/r4120a03a2bf32098e54e21ae02e509b0d68f413bc7cc1f8f6d85c93d%40%3Cdev.ignite.apache.org%3E
>>>>>>>> 
>>>>>>>> we've been discussing the problems and opportunities of using Guava
>>>>>>>> < https://github.com/google/guava > in Ignite 3. We have agreed
>>>> that
>>>>> it
>>>>>>>> should be added as a shaded dependency, but we haven't decided
>>>> whether
>>>>>> to
>>>>>>>> allow using Guava methods in the Ignite codebase or not. Therefore I
>>>>>> would
>>>>>>>> like to propose a vote:
>>>>>>>> 
>>>>>>>> [+1 Allow]: allow using Guava methods, if justified.
>>>>>>>> [-1 Prohibit]: prohibit using all Guava methods.
>>>>>>>> 
>>>>>>>> The voting will commence on Monday, September 13th at 9:00 UTC. Also
>>>>>> feel
>>>>>>>> free to express your opinion in the original discussion thread.
>>>>>>>> 
>>>>>>>> --
>>>>>>>> With regards,
>>>>>>>> Aleksandr Polovtcev
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Best regards,
>>>>>> Andrey V. Mashenkov
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> 
>>>> Best regards,
>>>> Alexei Scherbakov
>>>> 
>>> 
>>> 
>>> --
>>> With regards,
>>> Aleksandr Polovtcev
>> 
>> 
> 
> -- 
> With regards,
> Aleksandr Polovtcev

Re: [VOTE] Allow or prohibit usages of the Guava library methods

[Petr Ivanov]

Should we somehow restrict using this dependency in the project with Maven (or 
any other tools)?

> On 13 Sep 2021, at 12:47, Alexander Polovtcev  wrote:
> 
> The voting has finished and the results are the following:
> 
> [+1 Allow]: 1
> [-1 Prohibit]: 5
> 
> Therefore it is decided to prohibit using Guava in Ignite 3 codebase, even
> if it is included as a direct dependency. I will add this to the Ignite 3
> code style document (or similar) as soon as it is available.
> 
> On Thu, Sep 9, 2021 at 6:28 PM Alexei Scherbakov <
> alexey.scherbak...@gmail.com> wrote:
> 
>> I've checked Guava's feature list and came to a conclusion it's usefulness
>> has been diminished by switching to base java 11.
>> 
>> -1 for general use, but we can use some code parts then needed.
>> 
>> 
>> 
>> 
>> 
>> ср, 8 сент. 2021 г. в 14:09, Вячеслав Коптилин :
>> 
>>> -1
>>> I am leaning toward -1 because of vulnerability issues (that is a
>> possible
>>> case in general).
>>> 
>>> Thanks,
>>> S.
>>> 
>>> ср, 8 сент. 2021 г. в 12:13, Andrey Mashenkov <
>> andrey.mashen...@gmail.com
 :
>>> 
 -1
 Supporting few copy-pasted methods is much easier than support
>>> dependencies
 compatibility.
 
 On Tue, Sep 7, 2021 at 7:42 PM Zhenya Stanilovsky
  wrote:
 
> 
> Aleksandr, thanks for this activity.
> -1 from my side, all my decisions are in linked discussion.
> 
>> Dear Igniters,
>> 
>> In this thread
>> <
> 
 
>>> 
>> https://lists.apache.org/thread.html/r4120a03a2bf32098e54e21ae02e509b0d68f413bc7cc1f8f6d85c93d%40%3Cdev.ignite.apache.org%3E
>> 
>> we've been discussing the problems and opportunities of using Guava
>> < https://github.com/google/guava > in Ignite 3. We have agreed
>> that
>>> it
>> should be added as a shaded dependency, but we haven't decided
>> whether
 to
>> allow using Guava methods in the Ignite codebase or not. Therefore I
 would
>> like to propose a vote:
>> 
>> [+1 Allow]: allow using Guava methods, if justified.
>> [-1 Prohibit]: prohibit using all Guava methods.
>> 
>> The voting will commence on Monday, September 13th at 9:00 UTC. Also
 feel
>> free to express your opinion in the original discussion thread.
>> 
>> --
>> With regards,
>> Aleksandr Polovtcev
> 
> 
> 
> 
 
 
 
 --
 Best regards,
 Andrey V. Mashenkov
 
>>> 
>> 
>> 
>> --
>> 
>> Best regards,
>> Alexei Scherbakov
>> 
> 
> 
> -- 
> With regards,
> Aleksandr Polovtcev

Re: Build failed on the ignite-azure module. Missing dependency in maven central repository

[Petr Ivanov]

Teamcity will be able to build release — we have caching proxy with Artifactory 
which seems has cached that artifact already.
I think I can provide it as a file to republish to mvnrepository, but I have no 
such permissions.

Who could help us with uploading it?


> On 27 Aug 2021, at 11:23, Maxim Muzafarov  wrote:
> 
> Folks,
> 
> I've recently tried to build the Apache Ignite project from scratch
> and got the following error:
> 
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: ⁣ ⁣01:27 min
> [INFO] Finished at: 2021-08-25T22:40:58+03:00
> [INFO] 
> 
> [ERROR] Failed to execute goal on project ignite-azure: Could not
> resolve dependencies for project
> org.apache.ignite:ignite-azure:jar:2.12.0-SNAPSHOT: Failure to find
> com.azure:azure-storage-blob:jar:12.0.0 in
> https://repo.maven.apache.org/maven2 was cached in the local
> repository, resolution will not be reattempted until the update
> interval of central has elapsed or updates are forced -> [Help 1]
> 
> It seems the azure-storage-blob is missing in the maven central
> repository [1]. The mirror is not available since the bintray was
> deprecated in May [2].
> 
> What should we do with this? I see the following:
> - bump up the version of the azure module (compilation error occurs,
> some fix required)
> - republish the 12.0.0 version to the maven. It seems it should be available 
> [3]
> 
> How it affects the 2.11 release? Should we file an issue if we need to
> bump up the version?
> 
> [1] https://repo1.maven.org/maven2/com/azure/azure-storage-blob/12.0.0
> [2] https://jcenter.bintray.com/
> [3] https://mvnrepository.com/artifact/com.azure/azure-storage-blob/12.0.0

Re: TeamCity (ci.ignite.apache.org) is not available.

[Petr Ivanov]

Second IP address is missing from domain record, and first is currently down.
The issue is being resolved by INFRA [1]



[1] https://issues.apache.org/jira/browse/INFRA-22230

> On 20 Aug 2021, at 16:10, Pavel Pereslegin  wrote:
> 
> Hello, Igniters!
> 
> Can someone check why TeamCity (ci.ignite.apache.org) is currently 
> unavailable?

Re: [ANNOUNCE] New committer: Petr Ivanov

[Petr Ivanov]

Hi, Igniters.


This is an honour to be among committers of Apache Ignite indeed.
Thanks for your trust, will do my best to meet it.

> On 19 Aug 2021, at 12:58, Dmitry Pavlov  wrote:
> 
> Hello Ignite community,
> 
> The Project Management Committee (PMC) for Apache Ignite
> has invited Petr Ivanov (vveider) to become a committer and we are pleased 
> to announce that he has accepted.
> 
> Petr is community veteran, who supports TeamCity instance, as well as TC Bot, 
> and other services. He contributes also to supporting our 
> checkstyle/PMD/maven scripts, docker images, DEB, and RPM packages, Ignite 
> start scripts, and many more things, which are crucial for Apache Ignite 
> development process and running in producition. 
> 
> Please join me in congratulating Petr with his new role in the community.
> 
> 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.
> 
> Best Regards,
> Dmitriy Pavlov
> on behalf of Apache Ignite PMC

Re: Storing Teamcity projects settings in Version Control

[Petr Ivanov]

After initial setup, there won't be lot's of changes, at least for PRs there 
will be single commit with both fix and TC changes.


> On 17 Aug 2021, at 13:05, Anton Vinogradov  wrote:
> 
> This will kill repo history.
> You'll see dozens of TC config updates vs a single Ignite fix

Re: Storing Teamcity projects settings in Version Control

[Petr Ivanov]

Unfortunately, it won't work. At least in the nearest future.


Currently, you cannot see project structure on TC in any branch except default 
(master/main).
And some things like snapshot dependencies are ONLY taken from default branch.

> On 17 Aug 2021, at 10:25, Pavel Tupitsyn  wrote:
> 
> Changes and updates to build scripts and project structure often come
> together with changes to TC configuration,
> it would be great to be able to test them by simply creating a new branch
> in a single repo.

Re: Storing Teamcity projects settings in Version Control

[Petr Ivanov]

Hi, Dmitry.


I think we should start with adding current projects as-is in form of 
autogenerated Kotlin code, but continue to use UI for editing.
Later at some point we should replace autogenerated code with valid one (this 
can be done configuration by configuration), that will allow use the power of 
DSL and programming language to create dynamic configuration and use other 
benefits.

Also, while I was thinking about it, I wondered — should we add whole TC config 
to single repository, or divide per project (AI 2.x, AI 3.x, Extensions, Thin 
Clients, etc.) and add corresponding TeamCity configuration as part of the 
project into the same repository.
TeamCity configuration is added in form of maven project in .teamcity directory 
in the project's root and will not interfere with the project itself. Also this 
scheme is preferable due to linear development cycle (no parallel versions in 
development for each project).

I think I am ready to drive this initiative when and if we agree on this matter 
and will discuss all the details of such migration.


> On 16 Aug 2021, at 19:36, Dmitry Pavlov  wrote:
> 
> Hi Igniters,
> 
> Once there was a discussion about placing our build configurations (TC) 
> settings in a VSC repository. This idea was suggested because we wanted to 
> validate internals of configs using IDE/text editor. 
> 
> https://www.jetbrains.com/help/teamcity/storing-project-settings-in-version-control.html
> 
> Now, with introduction of a second instance this idea migth be useful twice, 
> we'll be able to 
> - view, track history, track authorship (? I'm not 100% sure, it is to be 
> checked)
> - use VSC as a signle source of thurth
> - we can remove TC Bot's code for validating all configs using REST
> 
> How does that sound to you? Is it better to look at Kotlin DSL? Or could XML 
> be enought? 
> 
> Sincerely,
> Dmitriy Pavlov
> 

Re: [ANNOUNCE] Welcome Alexander Shapkin as a new committer

[Petr Ivanov]

Congratulations, Aleksandr!


> On 11 Aug 2021, at 12:10, Pavel Tupitsyn  wrote:
> 
> The Project Management Committee (PMC) for Apache Ignite has invited
> Alexander Shapkin to become a committer and we are pleased to announce that
> he has accepted.
> 
> Alexander is one of the most active user supporters and has contributed
> new features and improvements to the code.
> 
> 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 Alexander, and congratulating him on the new role
> in
> the Apache Ignite Community!
> 
> Best Regards,
> Pavel Tupitsyn

Re: Secondary TeamCity instance: ci2.ignite.apache.org

[Petr Ivanov]

Seems that preserving and syncing users will be difficult to achieve — that 
info is stored in DB, and partial DB replication is tricky.

Also ci2.ignite.apache.org is good name, but currently it is targeted the same 
IP as original one:
; ANSWER SECTION:
ci2.ignite.apache.org.  1726IN  A   195.144.253.150



> On 3 Aug 2021, at 18:33, Dmitry Pavlov  wrote:
> 
> Hi Igniters,
> 
> I'm glad to announce that SberTech made an internal aggreement to sponsor a 
> computing power to provide backup TeamCity instance. This instance is 
> intended to be a geo-independent, secondary instance with availablility for 
> community members. 
> 
> Thanks to JetBrains for providing license keys for TeamCity as their part of 
> opensource sponsoring program.
> 
> Most likely, we'll setup some domain name as tc.i.a.o or ci2.i.a.o. Please 
> share your vision what would be most obvious.
> 
> After a private discussions with Vitaliy Osipov and Petr Ivanov, I do believe 
> that it would be possible to preserve current registered users. Build 
> configurations are to be the same for the secondary instance. Technical 
> details on how is could be achieved will be available later (most likely 
> we'll start a sepearate thread to dicuss that).
> 
> You are more than welcome to be an early adopters.
> 
> Sincerely,
> Dmitriy Pavlov
> 

Re: MTCGA site is down

[Petr Ivanov]

I've created issue in INFRA project about this matter [1].

Please, stand by,



[1] https://issues.apache.org/jira/browse/INFRA-22150

> On 28 Jul 2021, at 09:42, Alex Plehanov  wrote:
> 
> Hello, Igniters!
> 
> Looks like the MTCGA site hosted on Apache Ignite domain [1] is currently
> down (at least since yesterday), however, this site hosted on GridGain
> domain [2] is working.
> Can anyone have a look what's happening?
> 
> [1] : mtcga.ignite.apache.org
> [2] : mtcga.gridgain.com

Checking generated sources with PMD

[Petr Ivanov]

Hi, Igniters!


While working with Semyon on IGNITE-15182 [1] we've stumbled upon the following 
dilemma, that I would like to discuss.

Currently, `mvn compile pmd:check` command (as mentioned in Devnotes) also adds 
to check generated sources and fails on them, while mvn install && mvn 
pmd:check (as it is done in TC) does not (the reason is in absence of execution 
of maven-compiler-plugin which is not called on `pmd:check` goal).
PR from [1] introduces solution to add generated and other sources to check, 
but now there is a question: should we really add additional sources for 
examination?
From one side generated sources are not in our direct control and it can be 
hard to impossible to fix them right, from another — generated sources still a 
part of project and some flaws and worst practices in it can influent project's 
stability in an unpredictable way.

Please, share your thoughts on the matter!




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

Re: Apache Ignite Repo 403 Forbidden

[Petr Ivanov]

Yes, it is.

Seems that Apache kept the storage, or JFrog helped somehow.
Some one from committer side should update http://apache.org/dist/ignite/deb 
link to redirect correctly.


Not sure though there is still a way to deliver new packages there.



> On 23 Jul 2021, at 13:19, Maxim Muzafarov  wrote:
> 
> Folks,
> 
> Artefacts are available here. Is this what we are looking for?
> 
> https://apache.jfrog.io/artifactory/ignite-deb/
> https://apache.jfrog.io/artifactory/ignite-rpm/
> 
> On Fri, 23 Jul 2021 at 12:15, Petr Ivanov  wrote:
>> 
>> No mirror.
>> 
>> Also http://apache.org/dist/ignite/deb/dists/apache-ignite/InRelease 
>> <http://apache.org/dist/ignite/deb/dists/apache-ignite/InRelease> is 
>> redirected to Bintray which is closed.
>> The only way to get packages now — get source code for corresponding release 
>> version and build package manually (there is script for that inside).
>> 
>> 
>> Regards,
>> Petr Ivanov
>> Head of IT
>> IT & Development Solutions | GRIDGAIN SYSTEMS
>> +7 (911) 945-00-59
>> 
>>> On 23 Jul 2021, at 06:09, Mustafa Sunka  wrote:
>>> 
>>> Is there a mirror available? I have an app I am trying to rebuild and am 
>>> unable to proceed without this install.
>>> 
>>> On Thu, Jul 22, 2021 at 5:09 PM Ilya Kasnacheev >> <mailto:ilya.kasnach...@gmail.com>> wrote:
>>> Hello!
>>> 
>>> + Petr
>>> 
>>> Bintray went away, and I guess we have to re-publish these to jfrog.
>>> 
>>> Regards,
>>> --
>>> Ilya Kasnacheev
>>> 
>>> 
>>> чт, 22 июл. 2021 г. в 20:39, Mustafa Sunka >> <mailto:mustafa.su...@e-hps.com>>:
>>> 
>>>> This looks very similar to an issue from last year:
>>>> 
>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__apache-2Dignite-2Dusers.70518.x6.nabble.com_Apache-2DIgnite-2Ddownloads-2Dare-2Dredirecting-2Dfrom-2Dhttps-2Dto-2Dhttp-2Dtd31428.html=DwIFaQ=f7K5vTjsy0ldRUVHx_C48Q=F_pxrwS6ECbSFnH54hVvzyOo5Yb0IvCiswhvjRVXOCs=XQgK5pAVCrRiCWaNfbv0pubokT-e6V1EU_ZQrEH8b70=Oy3AYmpDoeav2VjaPGM-zWUKLgzX42RUO1GsDRsdy44=
>>>>  
>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__apache-2Dignite-2Dusers.70518.x6.nabble.com_Apache-2DIgnite-2Ddownloads-2Dare-2Dredirecting-2Dfrom-2Dhttps-2Dto-2Dhttp-2Dtd31428.html=DwIFaQ=f7K5vTjsy0ldRUVHx_C48Q=F_pxrwS6ECbSFnH54hVvzyOo5Yb0IvCiswhvjRVXOCs=XQgK5pAVCrRiCWaNfbv0pubokT-e6V1EU_ZQrEH8b70=Oy3AYmpDoeav2VjaPGM-zWUKLgzX42RUO1GsDRsdy44=>
>>>> 
>>>> When I attempt to run `apt-get update` on Ubuntu 18.04 with the Apache
>>>> Ignite repository in /etc/apt/sources.list, the update fails due to an
>>>> https to http redirect.  Here's the output from stdout:
>>>> 
>>>> 
>>>> WARNING: apt does not have a stable CLI interface. Use with caution in
>>>> scripts.
>>>> 
>>>> Hit:1 
>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__azure.archive.ubuntu.com_ubuntu=DwIFaQ=f7K5vTjsy0ldRUVHx_C48Q=F_pxrwS6ECbSFnH54hVvzyOo5Yb0IvCiswhvjRVXOCs=XQgK5pAVCrRiCWaNfbv0pubokT-e6V1EU_ZQrEH8b70=2Ov6DP1Bap0srqqc3X-UtLngbcH27ecZ8-mULSqkiTI=
>>>>  
>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__azure.archive.ubuntu.com_ubuntu=DwIFaQ=f7K5vTjsy0ldRUVHx_C48Q=F_pxrwS6ECbSFnH54hVvzyOo5Yb0IvCiswhvjRVXOCs=XQgK5pAVCrRiCWaNfbv0pubokT-e6V1EU_ZQrEH8b70=2Ov6DP1Bap0srqqc3X-UtLngbcH27ecZ8-mULSqkiTI=>
>>>>   bionic InRelease
>>>> Get:2 
>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__azure.archive.ubuntu.com_ubuntu=DwIFaQ=f7K5vTjsy0ldRUVHx_C48Q=F_pxrwS6ECbSFnH54hVvzyOo5Yb0IvCiswhvjRVXOCs=XQgK5pAVCrRiCWaNfbv0pubokT-e6V1EU_ZQrEH8b70=2Ov6DP1Bap0srqqc3X-UtLngbcH27ecZ8-mULSqkiTI=
>>>>  
>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__azure.archive.ubuntu.com_ubuntu=DwIFaQ=f7K5vTjsy0ldRUVHx_C48Q=F_pxrwS6ECbSFnH54hVvzyOo5Yb0IvCiswhvjRVXOCs=XQgK5pAVCrRiCWaNfbv0pubokT-e6V1EU_ZQrEH8b70=2Ov6DP1Bap0srqqc3X-UtLngbcH27ecZ8-mULSqkiTI=>
>>>>   bionic-updates InRelease
>>>> [88.7 kB]
>>>> Get:4 
>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__azure.archive.ubuntu.com_ubuntu=DwIFaQ=f7K5vTjsy0ldRUVHx_C48Q=F_pxrwS6ECbSFnH54hVvzyOo5Yb0IvCiswhvjRVXOCs=XQgK5pAVCrRiCWaNfbv0pubokT-e6V1EU_ZQrEH8b70=2Ov6DP1Bap0srqqc3X-UtLngbcH27ecZ8-mULSqkiTI=
>>>>  
>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__azure.archive.ubuntu.com_ubuntu=DwIFaQ=f7K5vTjsy0ldRUVHx_C48Q=F_pxrwS6ECbSFnH54hVvzyOo5Yb0IvCiswhvjRVXOCs=XQgK5pAVCrRiCWaNfbv0pubokT-e6V1EU_ZQrEH8b70=2O

Re: Apache Ignite Repo 403 Forbidden

[Petr Ivanov]

No mirror.

Also http://apache.org/dist/ignite/deb/dists/apache-ignite/InRelease 
<http://apache.org/dist/ignite/deb/dists/apache-ignite/InRelease> is redirected 
to Bintray which is closed.
The only way to get packages now — get source code for corresponding release 
version and build package manually (there is script for that inside).


Regards,
Petr Ivanov
Head of IT
IT & Development Solutions | GRIDGAIN SYSTEMS
+7 (911) 945-00-59

> On 23 Jul 2021, at 06:09, Mustafa Sunka  wrote:
> 
> Is there a mirror available? I have an app I am trying to rebuild and am 
> unable to proceed without this install.
> 
> On Thu, Jul 22, 2021 at 5:09 PM Ilya Kasnacheev  <mailto:ilya.kasnach...@gmail.com>> wrote:
> Hello!
> 
> + Petr
> 
> Bintray went away, and I guess we have to re-publish these to jfrog.
> 
> Regards,
> -- 
> Ilya Kasnacheev
> 
> 
> чт, 22 июл. 2021 г. в 20:39, Mustafa Sunka  <mailto:mustafa.su...@e-hps.com>>:
> 
> > This looks very similar to an issue from last year:
> >
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__apache-2Dignite-2Dusers.70518.x6.nabble.com_Apache-2DIgnite-2Ddownloads-2Dare-2Dredirecting-2Dfrom-2Dhttps-2Dto-2Dhttp-2Dtd31428.html=DwIFaQ=f7K5vTjsy0ldRUVHx_C48Q=F_pxrwS6ECbSFnH54hVvzyOo5Yb0IvCiswhvjRVXOCs=XQgK5pAVCrRiCWaNfbv0pubokT-e6V1EU_ZQrEH8b70=Oy3AYmpDoeav2VjaPGM-zWUKLgzX42RUO1GsDRsdy44=
> >  
> > <https://urldefense.proofpoint.com/v2/url?u=http-3A__apache-2Dignite-2Dusers.70518.x6.nabble.com_Apache-2DIgnite-2Ddownloads-2Dare-2Dredirecting-2Dfrom-2Dhttps-2Dto-2Dhttp-2Dtd31428.html=DwIFaQ=f7K5vTjsy0ldRUVHx_C48Q=F_pxrwS6ECbSFnH54hVvzyOo5Yb0IvCiswhvjRVXOCs=XQgK5pAVCrRiCWaNfbv0pubokT-e6V1EU_ZQrEH8b70=Oy3AYmpDoeav2VjaPGM-zWUKLgzX42RUO1GsDRsdy44=>
> >  
> >
> > When I attempt to run `apt-get update` on Ubuntu 18.04 with the Apache
> > Ignite repository in /etc/apt/sources.list, the update fails due to an
> > https to http redirect.  Here's the output from stdout:
> >
> >
> > WARNING: apt does not have a stable CLI interface. Use with caution in
> > scripts.
> >
> > Hit:1 
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__azure.archive.ubuntu.com_ubuntu=DwIFaQ=f7K5vTjsy0ldRUVHx_C48Q=F_pxrwS6ECbSFnH54hVvzyOo5Yb0IvCiswhvjRVXOCs=XQgK5pAVCrRiCWaNfbv0pubokT-e6V1EU_ZQrEH8b70=2Ov6DP1Bap0srqqc3X-UtLngbcH27ecZ8-mULSqkiTI=
> >  
> > <https://urldefense.proofpoint.com/v2/url?u=http-3A__azure.archive.ubuntu.com_ubuntu=DwIFaQ=f7K5vTjsy0ldRUVHx_C48Q=F_pxrwS6ECbSFnH54hVvzyOo5Yb0IvCiswhvjRVXOCs=XQgK5pAVCrRiCWaNfbv0pubokT-e6V1EU_ZQrEH8b70=2Ov6DP1Bap0srqqc3X-UtLngbcH27ecZ8-mULSqkiTI=>
> >   bionic InRelease
> > Get:2 
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__azure.archive.ubuntu.com_ubuntu=DwIFaQ=f7K5vTjsy0ldRUVHx_C48Q=F_pxrwS6ECbSFnH54hVvzyOo5Yb0IvCiswhvjRVXOCs=XQgK5pAVCrRiCWaNfbv0pubokT-e6V1EU_ZQrEH8b70=2Ov6DP1Bap0srqqc3X-UtLngbcH27ecZ8-mULSqkiTI=
> >  
> > <https://urldefense.proofpoint.com/v2/url?u=http-3A__azure.archive.ubuntu.com_ubuntu=DwIFaQ=f7K5vTjsy0ldRUVHx_C48Q=F_pxrwS6ECbSFnH54hVvzyOo5Yb0IvCiswhvjRVXOCs=XQgK5pAVCrRiCWaNfbv0pubokT-e6V1EU_ZQrEH8b70=2Ov6DP1Bap0srqqc3X-UtLngbcH27ecZ8-mULSqkiTI=>
> >   bionic-updates InRelease
> > [88.7 kB]
> > Get:4 
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__azure.archive.ubuntu.com_ubuntu=DwIFaQ=f7K5vTjsy0ldRUVHx_C48Q=F_pxrwS6ECbSFnH54hVvzyOo5Yb0IvCiswhvjRVXOCs=XQgK5pAVCrRiCWaNfbv0pubokT-e6V1EU_ZQrEH8b70=2Ov6DP1Bap0srqqc3X-UtLngbcH27ecZ8-mULSqkiTI=
> >  
> > <https://urldefense.proofpoint.com/v2/url?u=http-3A__azure.archive.ubuntu.com_ubuntu=DwIFaQ=f7K5vTjsy0ldRUVHx_C48Q=F_pxrwS6ECbSFnH54hVvzyOo5Yb0IvCiswhvjRVXOCs=XQgK5pAVCrRiCWaNfbv0pubokT-e6V1EU_ZQrEH8b70=2Ov6DP1Bap0srqqc3X-UtLngbcH27ecZ8-mULSqkiTI=>
> >   bionic-backports InRelease
> > [74.6 kB]
> > Hit:5 
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__security.ubuntu.com_ubuntu=DwIFaQ=f7K5vTjsy0ldRUVHx_C48Q=F_pxrwS6ECbSFnH54hVvzyOo5Yb0IvCiswhvjRVXOCs=XQgK5pAVCrRiCWaNfbv0pubokT-e6V1EU_ZQrEH8b70=G6_zzVnIHvOkW-Y3DmaEkgIomjN4ruRMTMjrrzK1IFU=
> >  
> > <https://urldefense.proofpoint.com/v2/url?u=http-3A__security.ubuntu.com_ubuntu=DwIFaQ=f7K5vTjsy0ldRUVHx_C48Q=F_pxrwS6ECbSFnH54hVvzyOo5Yb0IvCiswhvjRVXOCs=XQgK5pAVCrRiCWaNfbv0pubokT-e6V1EU_ZQrEH8b70=G6_zzVnIHvOkW-Y3DmaEkgIomjN4ruRMTMjrrzK1IFU=>
> >   bionic-security InRelease
> > Hit:6 
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__packages.microsoft.com_ubuntu_18.04_prod=DwIFaQ=f7K5vTjsy0ldRUVHx_C48Q=F_pxrwS6ECbSFnH54hVvzyOo5Yb0IvCiswhvjRVXOCs=XQgK5pAVCrRiCWaNfbv0pubokT-e6V1EU_ZQrEH8b70=k2leSDqZA4M0XmZUsXQjt1dz4ItJlOnVUu-jXnZdTes=
> >  
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__packages.microsoft.com_ubuntu_18.04_prod

Re: Not enough permissions to run RC build

[Petr Ivanov]

Check you permissions now, please.



> On 20 Jul 2021, at 10:24, Alexey Gidaspov  wrote:
> 
> Petr, my login is agidaspov
> 
> On 2021/07/20 07:22:26, Petr Ivanov  wrote: 
>> Aleksey — what is your login / email in TC?
>> 
>> 
>>> On 19 Jul 2021, at 16:10, Alexey Gidaspov  wrote:
>>> 
>>> No, but I'm release manager for 2.11 release and I think I should be able 
>>> to run RC build. 
>>> 
>>> On 2021/07/19 12:47:46, Petr Ivanov  wrote: 
>>>> Hi!
>>>> 
>>>> 
>>>> Are you committer or PMC on Apache Ignite?
>>>> 
>>>> 
>>>>> On 19 Jul 2021, at 14:40, Alexey Gidaspov  wrote:
>>>>> 
>>>>> Hi, All!
>>>>> 
>>>>> I've found out that I don't have enough permissions to run RC build for 
>>>>> ignite-2.11 branch on TC. Can anyone help me?
>>>> 
>>>> 
>> 
>> 

Re: Not enough permissions to run RC build

[Petr Ivanov]

Aleksey — what is your login / email in TC?


> On 19 Jul 2021, at 16:10, Alexey Gidaspov  wrote:
> 
> No, but I'm release manager for 2.11 release and I think I should be able to 
> run RC build. 
> 
> On 2021/07/19 12:47:46, Petr Ivanov  wrote: 
>> Hi!
>> 
>> 
>> Are you committer or PMC on Apache Ignite?
>> 
>> 
>>> On 19 Jul 2021, at 14:40, Alexey Gidaspov  wrote:
>>> 
>>> Hi, All!
>>> 
>>> I've found out that I don't have enough permissions to run RC build for 
>>> ignite-2.11 branch on TC. Can anyone help me?
>> 
>> 

Re: Not enough permissions to run RC build

[Petr Ivanov]

Nikolay, Dmitriy, Anton — what do you think?



> On 19 Jul 2021, at 16:10, Alexey Gidaspov  wrote:
> 
> No, but I'm release manager for 2.11 release and I think I should be able to 
> run RC build. 
> 
> On 2021/07/19 12:47:46, Petr Ivanov  wrote: 
>> Hi!
>> 
>> 
>> Are you committer or PMC on Apache Ignite?
>> 
>> 
>>> On 19 Jul 2021, at 14:40, Alexey Gidaspov  wrote:
>>> 
>>> Hi, All!
>>> 
>>> I've found out that I don't have enough permissions to run RC build for 
>>> ignite-2.11 branch on TC. Can anyone help me?
>> 
>> 

Re: Not enough permissions to run RC build

[Petr Ivanov]

Hi!


Are you committer or PMC on Apache Ignite?


> On 19 Jul 2021, at 14:40, Alexey Gidaspov  wrote:
> 
> Hi, All!
> 
> I've found out that I don't have enough permissions to run RC build for 
> ignite-2.11 branch on TC. Can anyone help me?

Re: Temporary TC Outage

[Petr Ivanov]

Hi.


Faulty agents are disabled, disk will be replaced.


Thanks for note!

> On 24 Jun 2021, at 17:35, Pavel Pereslegin  wrote:
> 
> Hello Petr,
> 
> we currently have many errors "Failed to start build" on TeamCity
> due to "Unexpected error: java.lang.RuntimeException:
> java.io.FileNotFoundException: /opt/buildagent/work/directory.map
> (Read-only file system) " .[1]
> 
> Can you check what is wrong?
> 
> [1] 
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAll_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> 
> вт, 22 июн. 2021 г. в 11:59, Petr Ivanov :
>> 
>> Good news.
>> 
>> 
>> TC is back online.
>> In case of any problems, please, write them on dev list, I will check.
>> 
>> 
>>> On 21 Jun 2021, at 19:40, Dmitry Pavlov  wrote:
>>> 
>>> Hi Petr,
>>> 
>>> Sad news, but anyway, thank you for letting community know.
>>> 
>>> Sincerely,
>>> Dmitriy Pavlov
>>> 
>>> On 2021/06/21 16:19:16, Petr Ivanov  wrote:
>>>> Hi, Igniters!
>>>> 
>>>> 
>>>> Currently our TC instance is out of order due to power outage (power booth 
>>>> burned down).
>>>> Restoration can take 1-2 days at least.
>>>> 
>>>> I will keep you updated on further news. Please, stand by.
>> 

Re: Temporary TC Outage

[Petr Ivanov]

Good news.


TC is back online.
In case of any problems, please, write them on dev list, I will check.


> On 21 Jun 2021, at 19:40, Dmitry Pavlov  wrote:
> 
> Hi Petr,
> 
> Sad news, but anyway, thank you for letting community know. 
> 
> Sincerely,
> Dmitriy Pavlov
> 
> On 2021/06/21 16:19:16, Petr Ivanov  wrote: 
>> Hi, Igniters!
>> 
>> 
>> Currently our TC instance is out of order due to power outage (power booth 
>> burned down).
>> Restoration can take 1-2 days at least.
>> 
>> I will keep you updated on further news. Please, stand by.

Temporary TC Outage

[Petr Ivanov]

Hi, Igniters!


Currently our TC instance is out of order due to power outage (power booth 
burned down).
Restoration can take 1-2 days at least.

I will keep you updated on further news. Please, stand by.

Re: Access rights to Team City

[Petr Ivanov]

Hi, Aleksey.


What do you mean by "manage"?


> On 9 Jun 2021, at 12:42, Alexey Gidaspov  wrote:
> 
> Hi, All!
> 
> I've found out that I can't manage builds at Team City. Can anyone tell me 
> how can I get necessary access rights? My TC account name is agidaspov. 

Re: Building with maven 3.8.1

[Petr Ivanov]

My point is that we cannot test "Maven 3.8.1 works with Apache Ignite" on 
TeamCity currently - only locally or in Travis.
Just FYI :)


> On 24 May 2021, at 10:39, Ivan Daschinsky  wrote:
> 
> And so what? There are no changes in pom's (in this PR) that break
> build on earlier maven versions. Why we should trust this patch
> (moreover, it breaks even some travis ci checks)
> 
> пн, 24 мая 2021 г. в 10:09, Petr Ivanov :
>> 
>> Our TeamCity currently does not support 3.8.1 maven build runner.
>> I think it will be available with 2021.1 version that is going to be 
>> delivered soon.
>> 
>> 
>>> On 21 May 2021, at 12:28, Ivan Daschinsky  wrote:
>>> 
>>> Hi. But where is TC run? And I suppose, that
>>> https://travis-ci.com/github/apache/ignite/jobs/506675544 should be at
>>> least fixed
>>> 
>>> пт, 21 мая 2021 г. в 10:22, Petr Ivanov :
>>>> 
>>>> Hi, Ilya.
>>>> 
>>>> 
>>>> Left small comment on formatting issue.
>>>> Otherwise looks good!
>>>> 
>>>> 
>>>> Considering 3.8.1 maven support — we will be migrating builds there after 
>>>> TC 2021.1 will be delivered.
>>>> 
>>>> 
>>>>> On 20 May 2021, at 19:22, Ilya Korol  wrote:
>>>>> 
>>>>> Hi, all.
>>>>> 
>>>>> Maybe someone has already faced the issue with Ignite and latest Maven 
>>>>> release 3.8.1?
>>>>> 
>>>>> https://issues.apache.org/jira/browse/IGNITE-14753
>>>>> 
>>>>> From 3.8.1 maven supplied with config that will block any http 
>>>>> repository/mirror. (See details here 
>>>>> https://maven.apache.org/docs/3.8.1/release-notes.html#cve-2021-26291)
>>>>> 
>>>>> Attempt to perform a build produces several errors:
>>>>> 
>>>>> 
>>>>> 1. Third party dependencies
>>>>> 
>>>>> 1.1) jta, hibernate-4.2, hibernate-5.1, hibernate-5.3 (btw hibernate-* 
>>>>> modules aren't built during mvn install)
>>>>> 
>>>>> org.ow2.jotm:jotm-core:jar:2.2.3
>>>>> -> org.ow2.carol:carol:jar:3.0.8
>>>>> -> org.jacorb:jacorb:jar:2.2.3-jonas-patch-20071018
>>>>> 
>>>>> jotm is a test dependency. Switch to latest available version 2.3.1-M1 
>>>>> did the trick. I didn't find any changelog for latest jotm release (their 
>>>>> site jotm.ow2.org seems a bit abandoned). I checked a little the diff 
>>>>> between 2.2.3 and 2.3.1-M1 source jars. Seems that there was some changes 
>>>>> in RMI related facilities, but i don't have enough expertise make a 
>>>>> conclusion that switch to 2.3.1-M1 would be safe (even if tests would be 
>>>>> green). Due to state of JOTM project maybe we should consider using 
>>>>> another JTA implementation with ongoing support like Atomicos or Narayana 
>>>>> (this implementation is also from the JBoss family like Hibernate)?
>>>>> 
>>>>> 1.2) spark
>>>>> 
>>>>> [ERROR] Failed to execute goal on project ignite-spark: Could not resolve 
>>>>> dependencies for project 
>>>>> org.apache.ignite:ignite-spark:jar:2.11.0-SNAPSHOT: Failed to collect 
>>>>> dependencies at org.apache.spark:spark-core_2.11:jar:2.3.0 -> 
>>>>> net.java.dev.jets3t:jets3t:jar:0.9.4 -> 
>>>>> commons-codec:commons-codec:jar:1.15-SNAPSHOT: Failed to read artifact 
>>>>> descriptor for commons-codec:commons-codec:jar:1.15-SNAPSHOT: Could not 
>>>>> transfer artifact commons-codec:commons-codec:pom:1.15-SNAPSHOT from/to 
>>>>> maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for 
>>>>> repositories: [apache.snapshots (http://repository.apache.org/snapshots, 
>>>>> default, snapshots)] -> [Help 1]
>>>>> 
>>>>> Updating to latest spark-core_2.11 maintenance version (2.3.0 -> 2.3.4) 
>>>>> did the job.
>>>>> 
>>>>> 
>>>>> 2. Broken plugins configuration
>>>>> 
>>>>> Currently ignite-parent uses org.apache:apache:16 as parent. Up to 18 
>>>>> release apache used http schema in different places of its configuration 
>>>>> (e.g. snapshot repository). So i guess its a good reason to update apache 
>>>>> parent at least to 18 release or maybe even to latest 23. This upgrade 
>>>>> will break builds for several modules:
>>>>> 
>>>>> 2.1) maven-jar-plugin */useDefaultManifestFile/* option was removed, so 
>>>>> usage of this option (true for ignite) will break the build. I guess we 
>>>>> can safely remove it from parent pom.
>>>>> 
>>>>> 2.2) Classifiers in ignite-exdata-uri. Building ignite-exdata-uri with 
>>>>> latest jar plugin produces errors like:
>>>>> 
>>>>>   ignite-extdata-uri: You have to use a classifier to attach supplemental 
>>>>> artifacts to the project instead of replacing them
>>>>> 
>>>>> Seems that jar plugin doesn't like when build produces multiple jars even 
>>>>> if they finalName's are different. Reworking build configuration with 
>>>>> classifiers fixed the problem.
>>>>> 
>>>>> 
>>>>> I've created a PR with proposed changes: 
>>>>> https://github.com/apache/ignite/pull/9116, comments are welcome
>>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Sincerely yours, Ivan Daschinskiy
>> 
> 
> 
> -- 
> Sincerely yours, Ivan Daschinskiy

Re: Building with maven 3.8.1

[Petr Ivanov]

Our TeamCity currently does not support 3.8.1 maven build runner.
I think it will be available with 2021.1 version that is going to be delivered 
soon.


> On 21 May 2021, at 12:28, Ivan Daschinsky  wrote:
> 
> Hi. But where is TC run? And I suppose, that
> https://travis-ci.com/github/apache/ignite/jobs/506675544 should be at
> least fixed
> 
> пт, 21 мая 2021 г. в 10:22, Petr Ivanov :
>> 
>> Hi, Ilya.
>> 
>> 
>> Left small comment on formatting issue.
>> Otherwise looks good!
>> 
>> 
>> Considering 3.8.1 maven support — we will be migrating builds there after TC 
>> 2021.1 will be delivered.
>> 
>> 
>>> On 20 May 2021, at 19:22, Ilya Korol  wrote:
>>> 
>>> Hi, all.
>>> 
>>> Maybe someone has already faced the issue with Ignite and latest Maven 
>>> release 3.8.1?
>>> 
>>> https://issues.apache.org/jira/browse/IGNITE-14753
>>> 
>>> From 3.8.1 maven supplied with config that will block any http 
>>> repository/mirror. (See details here 
>>> https://maven.apache.org/docs/3.8.1/release-notes.html#cve-2021-26291)
>>> 
>>> Attempt to perform a build produces several errors:
>>> 
>>> 
>>> 1. Third party dependencies
>>> 
>>> 1.1) jta, hibernate-4.2, hibernate-5.1, hibernate-5.3 (btw hibernate-* 
>>> modules aren't built during mvn install)
>>> 
>>> org.ow2.jotm:jotm-core:jar:2.2.3
>>> -> org.ow2.carol:carol:jar:3.0.8
>>> -> org.jacorb:jacorb:jar:2.2.3-jonas-patch-20071018
>>> 
>>> jotm is a test dependency. Switch to latest available version 2.3.1-M1 did 
>>> the trick. I didn't find any changelog for latest jotm release (their site 
>>> jotm.ow2.org seems a bit abandoned). I checked a little the diff between 
>>> 2.2.3 and 2.3.1-M1 source jars. Seems that there was some changes in RMI 
>>> related facilities, but i don't have enough expertise make a conclusion 
>>> that switch to 2.3.1-M1 would be safe (even if tests would be green). Due 
>>> to state of JOTM project maybe we should consider using another JTA 
>>> implementation with ongoing support like Atomicos or Narayana (this 
>>> implementation is also from the JBoss family like Hibernate)?
>>> 
>>> 1.2) spark
>>> 
>>> [ERROR] Failed to execute goal on project ignite-spark: Could not resolve 
>>> dependencies for project 
>>> org.apache.ignite:ignite-spark:jar:2.11.0-SNAPSHOT: Failed to collect 
>>> dependencies at org.apache.spark:spark-core_2.11:jar:2.3.0 -> 
>>> net.java.dev.jets3t:jets3t:jar:0.9.4 -> 
>>> commons-codec:commons-codec:jar:1.15-SNAPSHOT: Failed to read artifact 
>>> descriptor for commons-codec:commons-codec:jar:1.15-SNAPSHOT: Could not 
>>> transfer artifact commons-codec:commons-codec:pom:1.15-SNAPSHOT from/to 
>>> maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for 
>>> repositories: [apache.snapshots (http://repository.apache.org/snapshots, 
>>> default, snapshots)] -> [Help 1]
>>> 
>>> Updating to latest spark-core_2.11 maintenance version (2.3.0 -> 2.3.4) did 
>>> the job.
>>> 
>>> 
>>> 2. Broken plugins configuration
>>> 
>>> Currently ignite-parent uses org.apache:apache:16 as parent. Up to 18 
>>> release apache used http schema in different places of its configuration 
>>> (e.g. snapshot repository). So i guess its a good reason to update apache 
>>> parent at least to 18 release or maybe even to latest 23. This upgrade will 
>>> break builds for several modules:
>>> 
>>> 2.1) maven-jar-plugin */useDefaultManifestFile/* option was removed, so 
>>> usage of this option (true for ignite) will break the build. I guess we can 
>>> safely remove it from parent pom.
>>> 
>>> 2.2) Classifiers in ignite-exdata-uri. Building ignite-exdata-uri with 
>>> latest jar plugin produces errors like:
>>> 
>>>ignite-extdata-uri: You have to use a classifier to attach supplemental 
>>> artifacts to the project instead of replacing them
>>> 
>>> Seems that jar plugin doesn't like when build produces multiple jars even 
>>> if they finalName's are different. Reworking build configuration with 
>>> classifiers fixed the problem.
>>> 
>>> 
>>> I've created a PR with proposed changes: 
>>> https://github.com/apache/ignite/pull/9116, comments are welcome
>>> 
>> 
> 
> 
> -- 
> Sincerely yours, Ivan Daschinskiy

Re: Building with maven 3.8.1

[Petr Ivanov]

Hi, Ilya.


Left small comment on formatting issue.
Otherwise looks good!


Considering 3.8.1 maven support — we will be migrating builds there after TC 
2021.1 will be delivered.


> On 20 May 2021, at 19:22, Ilya Korol  wrote:
> 
> Hi, all.
> 
> Maybe someone has already faced the issue with Ignite and latest Maven 
> release 3.8.1?
> 
> https://issues.apache.org/jira/browse/IGNITE-14753
> 
> From 3.8.1 maven supplied with config that will block any http 
> repository/mirror. (See details here 
> https://maven.apache.org/docs/3.8.1/release-notes.html#cve-2021-26291)
> 
> Attempt to perform a build produces several errors:
> 
> 
> 1. Third party dependencies
> 
> 1.1) jta, hibernate-4.2, hibernate-5.1, hibernate-5.3 (btw hibernate-* 
> modules aren't built during mvn install)
> 
> org.ow2.jotm:jotm-core:jar:2.2.3
> -> org.ow2.carol:carol:jar:3.0.8
> -> org.jacorb:jacorb:jar:2.2.3-jonas-patch-20071018
> 
> jotm is a test dependency. Switch to latest available version 2.3.1-M1 did 
> the trick. I didn't find any changelog for latest jotm release (their site 
> jotm.ow2.org seems a bit abandoned). I checked a little the diff between 
> 2.2.3 and 2.3.1-M1 source jars. Seems that there was some changes in RMI 
> related facilities, but i don't have enough expertise make a conclusion that 
> switch to 2.3.1-M1 would be safe (even if tests would be green). Due to state 
> of JOTM project maybe we should consider using another JTA implementation 
> with ongoing support like Atomicos or Narayana (this implementation is also 
> from the JBoss family like Hibernate)?
> 
> 1.2) spark
> 
> [ERROR] Failed to execute goal on project ignite-spark: Could not resolve 
> dependencies for project org.apache.ignite:ignite-spark:jar:2.11.0-SNAPSHOT: 
> Failed to collect dependencies at org.apache.spark:spark-core_2.11:jar:2.3.0 
> -> net.java.dev.jets3t:jets3t:jar:0.9.4 -> 
> commons-codec:commons-codec:jar:1.15-SNAPSHOT: Failed to read artifact 
> descriptor for commons-codec:commons-codec:jar:1.15-SNAPSHOT: Could not 
> transfer artifact commons-codec:commons-codec:pom:1.15-SNAPSHOT from/to 
> maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for 
> repositories: [apache.snapshots (http://repository.apache.org/snapshots, 
> default, snapshots)] -> [Help 1]
> 
> Updating to latest spark-core_2.11 maintenance version (2.3.0 -> 2.3.4) did 
> the job.
> 
> 
> 2. Broken plugins configuration
> 
> Currently ignite-parent uses org.apache:apache:16 as parent. Up to 18 release 
> apache used http schema in different places of its configuration (e.g. 
> snapshot repository). So i guess its a good reason to update apache parent at 
> least to 18 release or maybe even to latest 23. This upgrade will break 
> builds for several modules:
> 
> 2.1) maven-jar-plugin */useDefaultManifestFile/* option was removed, so usage 
> of this option (true for ignite) will break the build. I guess we can safely 
> remove it from parent pom.
> 
> 2.2) Classifiers in ignite-exdata-uri. Building ignite-exdata-uri with latest 
> jar plugin produces errors like:
> 
> ignite-extdata-uri: You have to use a classifier to attach supplemental 
> artifacts to the project instead of replacing them
> 
> Seems that jar plugin doesn't like when build produces multiple jars even if 
> they finalName's are different. Reworking build configuration with 
> classifiers fixed the problem.
> 
> 
> I've created a PR with proposed changes: 
> https://github.com/apache/ignite/pull/9116, comments are welcome
> 

Re: Let's remove mutes on the TC

[Petr Ivanov]

Mutes remove themselves when test is successful again.

Or you are referring to overall list of mutes on test project?





> On 20 May 2021, at 11:27, aonikolaev  wrote:
> 
> Hi Igniters,
> I want to start dealing with muted and ignored tests on the TC bot that have
> lost relevance or require small fixes. Does the community have any
> suggestions for this?
> 
> 
> 
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: [VOTE][EXTENSION] Release Apache Ignite performance-statistics-ext, spring-data-all-ext and spring-tx-ext extensions 1.0.0 RC1

[Petr Ivanov]

Thats old suite, I've paused it.
We should test with [1] which is already set properly due to relying on module 
dir name.


[1] 
https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_RunAllTests

> On 23 Apr 2021, at 11:13, Nikita Amelchev  wrote:
> 
> Petr,
> 
> Module names in settings of the suite [1] should be changed.
> 
> [1] 
> https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_OldRunAllTests?mode=builds#all-projects
> 
> чт, 22 апр. 2021 г. в 11:49, Petr Ivanov :
> 
>> 
>> Looks good.
>> 
>> 
>> What suites are in question, these ones [1]?
>> 
>> 
>> 
>> [1] https://ci.ignite.apache.org/project/IgniteExtensions_Tests
>>> On 22 Apr 2021, at 10:42, Nikita Amelchev  wrote:
>>> 
>>> Hi, guys.
>>> 
>>> I have prepared PR to fix module names [1, 2]. Could you take a look
>>> and recheck TC integration, please?
>>> 
>>> Note that module names in TC suites should be changed as well.
>>> 
>>> [1] https://github.com/apache/ignite-extensions/pull/58
>>> [2] https://issues.apache.org/jira/browse/IGNITE-14621
>>> 
>>> чт, 22 апр. 2021 г. в 00:08, Nikita Amelchev :
>>> 
>>>> 
>>>> I have created the issue to fix modules names:
>>>> 
>>>> https://issues.apache.org/jira/browse/IGNITE-14621
>>>> 
>>>> ср, 21 апр. 2021 г. в 11:46, Nikita Amelchev :
>>>>> 
>>>>> +1 to formalize extension modules names:
>>>>> ignite-{directory-name}
>>>>> 
>>>>> The release script has this issue too. It will work fine with that name.
>>>>> 
>>>>> ср, 21 апр. 2021 г. в 10:37, Petr Ivanov :
>>>>>> 
>>>>>> I checked the modules and there is misnaming issue which I think is 
>>>>>> critical to test integration automation on TC.
>>>>>> Can we change maven module names sping-data-2.x-ext to align with 
>>>>>> directory name? Currently there is underscore in maven module name, 
>>>>>> which is hyphen in directory name.
>>>>>> 
>>>>>> 
>>>>>>> On 21 Apr 2021, at 10:22, Nikita Amelchev  wrote:
>>>>>>> 
>>>>>>> +1 to postpone the spring-tx-ext extension release.
>>>>>>> 
>>>>>>> So, the following extensions will be released now:
>>>>>>> 
>>>>>>> spring-data-ext
>>>>>>> spring-data-2.0-ext
>>>>>>> spring-data-2.2-ext
>>>>>>> spring-data-commons
>>>>>>> performance-statistics-ext
>>>>>>> 
>>>>>>> вт, 20 апр. 2021 г. в 14:49, Mikhail Petrov :
>>>>>>>> 
>>>>>>>> Igniters,
>>>>>>>> 
>>>>>>>> Changing the scope of Spring dependencies to "provided" in Ignite 
>>>>>>>> Spring
>>>>>>>> extensions does not currently work as expected:
>>>>>>>> some versions of Spring that a user can specify via maven configuration
>>>>>>>> for Spring extensions may conflict with the hard-coded version of 
>>>>>>>> Spring
>>>>>>>> dependencies that the ignite-spring module relies on.
>>>>>>>> 
>>>>>>>> The issue mentioned above affects the Ignite Spring Transactions
>>>>>>>> integration. And since this integration is included in the Ignite 2.10
>>>>>>>> release, I suggest postponing the release of the Ignite Spring
>>>>>>>> Transactions integration until the above issue is properly fixed.
>>>>>>>> 
>>>>>>>> Any objections?
>>>>>>>> 
>>>>>>>> On 16.04.2021 09:15, Ivan Daschinsky wrote:
>>>>>>>>> -1 From me. There is an absence of NOTICE and LICENSE files in binary
>>>>>>>>> package. Also, there is no source package. These is a violation of 
>>>>>>>>> apache
>>>>>>>>> release policy [1]
>>>>>>>>> [1] https://www.apache.org/legal/release-policy.html
>>>>>>>>> 
>>>>>>>>> чт, 15 апр. 2021 г. в 23:23, Nikita Amelchev :
>>>>>>>>> 
>>>>>>>>>&

Re: Apache Ignite 3 / RPM

[Petr Ivanov]

Unfortunately, no.


However, I think I'll update the package to better resemble with current binary 
archive prepared for alpha2 and update release task.
Due to Bintray closure, I think we can deliver packages as standalone RPM with 
install instructions.

I will update release build anyway, but community will decide whether to 
release package or not.
Nightly builds will be available for enthusiasts with all deliveries possible.


> On 21 Apr 2021, at 17:22, Ilya Kasnacheev  wrote:
> 
> Hello!
> 
> Were you able to get any traction here?
> 
> Apache Ignite 3.0 seems to be in too early stage for packaging, IMHO.
> We see very few interest in improving Apache Ignite 2.x packages, anyway.
> 
> Regards,
> -- 
> Ilya Kasnacheev
> 
> 
> ср, 24 февр. 2021 г. в 19:01, Petr Ivanov :
> 
>> Hi, Igniters.
>> 
>> 
>> Sincerely asking you to help me with testing new RPM package for apache
>> ignite 3.x [1]
>> Currently what is needed to be tested — successful installation and binary
>> run under most of RHEL based distributions: Red Hat, CentOS, Oracle Linux,
>> Fedora, etc.
>> 
>> Any other thoughts and suggestions are more than welcome too.
>> RPM assembly code can be found here [2]
>> 
>> 
>> Thanks in advance!
>> 
>> 
>> 
>> [1]
>> https://issues.apache.org/jira/secure/attachment/13021121/apache-ignite-3.0.0-1.noarch.rpm
>> [2] https://github.com/apache/ignite-3/pull/29/files
>> 
>> 

Re: [VOTE][EXTENSION] Release Apache Ignite performance-statistics-ext, spring-data-all-ext and spring-tx-ext extensions 1.0.0 RC1

[Petr Ivanov]

Looks good.


What suites are in question, these ones [1]?



[1] https://ci.ignite.apache.org/project/IgniteExtensions_Tests
> On 22 Apr 2021, at 10:42, Nikita Amelchev  wrote:
> 
> Hi, guys.
> 
> I have prepared PR to fix module names [1, 2]. Could you take a look
> and recheck TC integration, please?
> 
> Note that module names in TC suites should be changed as well.
> 
> [1] https://github.com/apache/ignite-extensions/pull/58
> [2] https://issues.apache.org/jira/browse/IGNITE-14621
> 
> чт, 22 апр. 2021 г. в 00:08, Nikita Amelchev :
> 
>> 
>> I have created the issue to fix modules names:
>> 
>> https://issues.apache.org/jira/browse/IGNITE-14621
>> 
>> ср, 21 апр. 2021 г. в 11:46, Nikita Amelchev :
>>> 
>>> +1 to formalize extension modules names:
>>> ignite-{directory-name}
>>> 
>>> The release script has this issue too. It will work fine with that name.
>>> 
>>> ср, 21 апр. 2021 г. в 10:37, Petr Ivanov :
>>>> 
>>>> I checked the modules and there is misnaming issue which I think is 
>>>> critical to test integration automation on TC.
>>>> Can we change maven module names sping-data-2.x-ext to align with 
>>>> directory name? Currently there is underscore in maven module name, which 
>>>> is hyphen in directory name.
>>>> 
>>>> 
>>>>> On 21 Apr 2021, at 10:22, Nikita Amelchev  wrote:
>>>>> 
>>>>> +1 to postpone the spring-tx-ext extension release.
>>>>> 
>>>>> So, the following extensions will be released now:
>>>>> 
>>>>> spring-data-ext
>>>>> spring-data-2.0-ext
>>>>> spring-data-2.2-ext
>>>>> spring-data-commons
>>>>> performance-statistics-ext
>>>>> 
>>>>> вт, 20 апр. 2021 г. в 14:49, Mikhail Petrov :
>>>>>> 
>>>>>> Igniters,
>>>>>> 
>>>>>> Changing the scope of Spring dependencies to "provided" in Ignite Spring
>>>>>> extensions does not currently work as expected:
>>>>>> some versions of Spring that a user can specify via maven configuration
>>>>>> for Spring extensions may conflict with the hard-coded version of Spring
>>>>>> dependencies that the ignite-spring module relies on.
>>>>>> 
>>>>>> The issue mentioned above affects the Ignite Spring Transactions
>>>>>> integration. And since this integration is included in the Ignite 2.10
>>>>>> release, I suggest postponing the release of the Ignite Spring
>>>>>> Transactions integration until the above issue is properly fixed.
>>>>>> 
>>>>>> Any objections?
>>>>>> 
>>>>>> On 16.04.2021 09:15, Ivan Daschinsky wrote:
>>>>>>> -1 From me. There is an absence of NOTICE and LICENSE files in binary
>>>>>>> package. Also, there is no source package. These is a violation of 
>>>>>>> apache
>>>>>>> release policy [1]
>>>>>>> [1] https://www.apache.org/legal/release-policy.html
>>>>>>> 
>>>>>>> чт, 15 апр. 2021 г. в 23:23, Nikita Amelchev :
>>>>>>> 
>>>>>>>> According to ASF release policy [1] non-PMC committers can sign 
>>>>>>>> artifacts:
>>>>>>>> 
>>>>>>>>> all artifacts placed in their directory must be signed by a committer,
>>>>>>>> preferably by a PMC member.
>>>>>>>> 
>>>>>>>> [1] https://www.apache.org/legal/release-policy.html
>>>>>>>> 
>>>>>>>> чт, 15 апр. 2021 г. в 23:05, Dmitriy Pavlov :
>>>>>>>>> My best guess that since PMCs have a binding vote in voting in 
>>>>>>>>> release, a
>>>>>>>>> PMC member should sign binaries as well. And I suppose that in the 
>>>>>>>>> past
>>>>>>>>> only PMC members were signing the release.
>>>>>>>>> 
>>>>>>>>> Meanwhile, https://infra.apache.org/release-signing.html does not
>>>>>>>> contain
>>>>>>>>> any mention of PMC role and only committers are mentioned there. It
>>>>>>>>> might be not an answer, since a lot of projects have PMC

Re: [VOTE][EXTENSION] Release Apache Ignite performance-statistics-ext, spring-data-all-ext and spring-tx-ext extensions 1.0.0 RC1

[Petr Ivanov]

I checked the modules and there is misnaming issue which I think is critical to 
test integration automation on TC.
Can we change maven module names sping-data-2.x-ext to align with directory 
name? Currently there is underscore in maven module name, which is hyphen in 
directory name.


> On 21 Apr 2021, at 10:22, Nikita Amelchev  wrote:
> 
> +1 to postpone the spring-tx-ext extension release.
> 
> So, the following extensions will be released now:
> 
> spring-data-ext
> spring-data-2.0-ext
> spring-data-2.2-ext
> spring-data-commons
> performance-statistics-ext
> 
> вт, 20 апр. 2021 г. в 14:49, Mikhail Petrov :
>> 
>> Igniters,
>> 
>> Changing the scope of Spring dependencies to "provided" in Ignite Spring
>> extensions does not currently work as expected:
>> some versions of Spring that a user can specify via maven configuration
>> for Spring extensions may conflict with the hard-coded version of Spring
>> dependencies that the ignite-spring module relies on.
>> 
>> The issue mentioned above affects the Ignite Spring Transactions
>> integration. And since this integration is included in the Ignite 2.10
>> release, I suggest postponing the release of the Ignite Spring
>> Transactions integration until the above issue is properly fixed.
>> 
>> Any objections?
>> 
>> On 16.04.2021 09:15, Ivan Daschinsky wrote:
>>> -1 From me. There is an absence of NOTICE and LICENSE files in binary
>>> package. Also, there is no source package. These is a violation of apache
>>> release policy [1]
>>> [1] https://www.apache.org/legal/release-policy.html
>>> 
>>> чт, 15 апр. 2021 г. в 23:23, Nikita Amelchev :
>>> 
 According to ASF release policy [1] non-PMC committers can sign artifacts:
 
> all artifacts placed in their directory must be signed by a committer,
 preferably by a PMC member.
 
 [1] https://www.apache.org/legal/release-policy.html
 
 чт, 15 апр. 2021 г. в 23:05, Dmitriy Pavlov :
> My best guess that since PMCs have a binding vote in voting in release, a
> PMC member should sign binaries as well. And I suppose that in the past
> only PMC members were signing the release.
> 
> Meanwhile, https://infra.apache.org/release-signing.html does not
 contain
> any mention of PMC role and only committers are mentioned there. It
> might be not an answer, since a lot of projects have PMC=Committer and
 just
> one election.
> 
> Sincerely,
> Dmitriy Pavlov
> 
> чт, 15 апр. 2021 г. в 22:05, Ivan Daschinsky :
> 
>> I'm sorry, but is it OK, that artifacts are signed with signature of
>> non-PMC?
>> 
>> чт, 15 апр. 2021 г. в 19:26, Nikita Amelchev :
>> 
>>> Dear Ignite Community,
>>> 
>>> I have uploaded a release candidate of the following extension
 modules:
>>> performance-statistics-ext
>>> spring-data-ext
>>> spring-data-2.0-ext
>>> spring-data-2.2-ext
>>> spring-data-commons
>>> spring-tx-ext
>>> 
>>> The release candidate of the performance-statistics-ext extension:
>>> 
>>> 
 https://dist.apache.org/repos/dist/dev/ignite/ignite-performance-statistics-ext/1.0.0-rc1/
>>> The following staging can be used for testing:
>>> 
 https://repository.apache.org/content/repositories/orgapacheignite-1509
>>> Tags were created:
>>> 
>>> ignite-performance-statistics-ext-1.0.0-rc1
>>> 
>>> 
 https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=commit;h=b992d9758278c38e93b375b08e4052954744a436
>>> ignite-spring-data-ext-1.0.0-rc1
>>> ignite-spring-data-2.2-ext-1.0.0-rc1
>>> ignite-spring-data-2.0-ext-1.0.0-rc1
>>> ignite-spring-data-commons-1.0.0-rc1
>>> ignite-spring-data-all-ext-1.0.0-rc1
>>> 
>>> 
 https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=commit;h=277ca95f6472d8bd46d906e70ba1a312d36dadb0
>>> ignite-spring-tx-ext-1.0.0-rc1
>>> 
>>> 
 https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=commit;h=55a3ae9e011ba48796847a33481842f154f0febb
>>> RELEASE NOTES:
>>> 
>>> 
 https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=blob;f=RELEASE_NOTES.txt;h=22f8d665c194ba2dfa6167354d97ad53d5ef206f;hb=c8de80ee14d1fb76d6cbb0b18513bb70b499c3cb
>>> DOCUMENTATION:
>>> Documentation of listed extensions was updated in the following
 issues:
>>> 
 https://issues.apache.org/jira/issues/?filter=-1=key%20in%20(IGNITE-14417%2CIGNITE-14398%2CIGNITE-14397%2CIGNITE-14493)
>>> The vote is formal, see voting guidelines
>>> https://www.apache.org/foundation/voting.html
>>> 
>>> +1 - to accept all the Apache Ignite performance-statistics-ext,
>>> spring-data-all-ext and spring-tx-ext extensions 1.0.0-rc1 listed in
>>> the thread
>>> 0 - don't care either way
>>> -1 - DO NOT accept either of the Apache Ignite
>>> performance-statistics-ext, spring-data-all-ext and spring-tx-ext
>>> 

Re: [DISCUSSION] IEP-69 The evolutionary release process

[Petr Ivanov]

Maksim,


Great summary!
+1 for versioning scheme.


However, deprecation rules can be possibly misleading.
I think that we should use 'since' as a mandatory annotation, that will mark 
the release where the API can (not should) be changed, regardless of our 
intention to modify it.
And add some kind of a tag or alike to that APIs only that we need to 
update/remove since mentioned release.
Otherwise, I think, simple deprecation annotation will raise questions 'when it 
was deprecated' or 'is it already time to update/remove deprecated API'.

Also, if agreed on 'since' annotation usage, we possibly should create the 
issue to tag all current deprecated APIs with since where applicable.

> On 16 Mar 2021, at 21:05, Maxim Muzafarov  wrote:
> 
> Folks,
> 
> 
> Thanks to everyone for participating in the call. Here is the list of
> points we've agreed on and the list of actions which should be
> discussed in more details.
> 
> 
> = AGREED =
> 
> == Versioning ==
> 
> grand.major.bugfix[-rc_number]
> 
> The 'grand' version is fixed while both Ignite architectures (current
> version 2.x and 3.x) are in a state of active development/maintained
> or until otherwise is discussed further. This means:
> - the master branch of the ignite repository [2] always release under
> the '2.x.x' version
> - the main branch of the ignite-3 repository [1] always release under
> the '3.x.x' version
> 
> The 'major' versions for each architecture may contain breaking
> backwards compatibility changes compared to the previous one if the
> following criteria are met:
> - users should be warned about breaking release changes (the ways of
> notification should be additionally discussed and agreed upon)
> - the deprecation rules may be applied for the current 'major' release
> (the ways of deprecation must be additionally discussed and agreed
> upon)
> - current @deprecated already have enough time live and some of them
> can be removed using common sense
> 
> The 'bugfix' version is used for emergency releases and can't contain
> any breaking backwards compatibility changes.
> 
> == Commitments ==
> 
> Any commitment to support previous releases (e.g. 1 year, 1 quarter)
> have no sense to the open-source Ignite community in the case of
> observed backward compatibility violations, however, in any of such
> cases, an emergency release can be performed according to the accepted
> release procedure.
> 
> 
> = DISCUSSION & SUGGESTIONS =
> 
> 
> == Deprecation rules ==
> 
> The API deprecation rules must be discussed and agreed upon in more
> details. The list of options we have:
> - deprecate and remove API allowed in the next release
> - deprecate and remove API allowed through the one release
> - deprecation may contain comments - the release version then the API
> will be changed
> - deprecation may contain comments - the date from which the API changes 
> allowed
> 
> I've checked the `JEP 277 Enhanced Deprecation` [3] proposal which
> adds the `forRemoval` and `since` optional elements to the deprecated
> annotation and I think we can use a similar approach here with some
> additions. For instance, if the last released version is 2.10 my
> suggestions would be the following:
> - [case: change API as quickly as possible] mark some API as
> deprecated, set 'since' version 2.12, change it in the 2.12 release
> major version.
> - [case: deprecate API without intention to change] mark API as
> deprecated without 'since' options, change it without notifications
> since 2.13 releases and so on.
> 
> 
> == User notification rules ==
> 
> Uses must be well-notified about the planned backward compatibility
> violations. The options we have:
> - the notification thought the source code with well-described JavaDocs
> - add labels to the JIRA issue if some deprecations occur in the related patch
> - add deprecation and backward compatibility paragraph to the RELEASE_NOTES
> - add a page to the Apache Ignite website with a backwards
> compatibility description between the closest versions
> 
> All of the above must be done.
> 
> 
> == Experimental and unstable APIs ==
> 
> The options we have:
> - only the new API can be marked as unstable and/or experimental
> - such APIs can be changed without any notifications
> 
> 
> Please, share your thoughts.
> 
> 
> [1] https://github.com/apache/ignite-3
> [2] https://github.com/apache/ignite
> [3] https://openjdk.java.net/jeps/277
> 
> On Mon, 15 Mar 2021 at 19:41, Dmitriy Pavlov  wrote:
>> 
>> Folks,
>> 
>> let me add my 50 cents. I don't see major issues with this IEP, for now.
>> And I really looking forward to talking about it. I can't get what causes
>> misunderstanding.
>> 
>> The only thing that concerns me here is that IEP requires the community to
>> support solutions for 1 year, 1 quarter, etc.
>> 
>> Apache community is not a commercial company that provides support of any
>> kind, and I would be reluctant to add these or similar statements to any
>> public documents. At any point in time, the 

Re: [DISCUSS] Missed (non-suited) tests

[Petr Ivanov]

Yeap!


I'll start implementing it next week.
I think I'll create new jobs and when everything is OK — will switch settings 
in template to new chain.

It will take some time to do everything right though.

> On 5 Mar 2021, at 09:28, Maksim Timonin  wrote:
> 
> Hi, Petr!
> 
> I've created a ticket [1] for that and assigned it on you. Could you please
> catch it when you have time?
> 
> [1] https://issues.apache.org/jira/browse/IGNITE-14283
> 
> On Wed, Mar 3, 2021 at 11:06 PM Maxim Muzafarov  wrote:
> 
>> Max,
>> 
>>> There is an overhead for running git + mvn test twice, but it is a cost
>> for the flexibility.
>> 
>> Yes, I mean this issue. I have no objections, the build queue seems to
>> be empty most of the time.
>> 
>> On Wed, 3 Mar 2021 at 21:01, Max Timonin  wrote:
>>> 
>>> Yes, they can be performed as parallel, as doesn't depend on each other.
>>> There is an overhead for running git + mvn test twice, but it is a cost
>> for
>>> the flexibility.
>>> 
>>> On Wed, Mar 3, 2021 at 8:55 PM Max Timonin 
>> wrote:
>>> 
>>>> I mean that any TC job with tests depends on both [Build], [Sanity
>>>> Checks]. No tests run if any of those jobs failed.
>>>> 
>>>> [Build] prepares ignite.zip for distribution between TC agents (mvn
>>>> install).
>>>> [Sanity Checks] checks that code is correct in terms of our static
>> checks
>>>> (mvn test).
>>>> 
>>>> Indeed it can be run as a single job, but in favor of flexibility in
>>>> configuration (enable / disable checks) it is OK to separate it in 2
>> steps.
>>>> 
>>>> Do you have some objections to do it that way?
>>>> 
>>>> On Wed, Mar 3, 2021 at 8:45 PM Maxim Muzafarov 
>> wrote:
>>>> 
>>>>> Maxim,
>>>>> 
>>>>> Can you clarify what means '[Sanity Checks] runs in parallel with
>>>>> [Build]'? AFAIK the checks need the build results to run themselves.
>>>>> 
>>>>> On Wed, 3 Mar 2021 at 18:48, Max Timonin 
>> wrote:
>>>>>> 
>>>>>> Discussed with Petr privately. Proposal is:
>>>>>> 
>>>>>> 1. The [Build] job runs without any checks.
>>>>>> 2. There will be a new job [Sanity Checks], that runs all checks -
>>>>>> checkstyle, licenses, javadoc, check-suites.
>>>>>> 3. [Sanity Checks] runs in parallel with [Build].
>>>>>> 4. All TC jobs with tests depend on a result of the [Sanity Checks]
>>>>> job. If
>>>>>> the check job fails then a test job won't be started.
>>>>>> 5. Users can disable the [Sanity Checks] job with a selector on the
>>>>>> Parameters tab of custom TC build.
>>>>>> 
>>>>>> If no one has objections I will create a JIRA ticket for that.
>>>>>> 
>>>>>> 
>>>>>> On Wed, Mar 3, 2021 at 5:11 PM Max Timonin >> 
>>>>> wrote:
>>>>>> 
>>>>>>> Hi Petr! My proposal is:
>>>>>>> 
>>>>>>> 1. Create a parameter in [Build] TC suite - MAVEN_CHECKS, default
>>>>> value is
>>>>>>> "-Plicenses,checkstyle,check-licenses,check-test-suites".
>>>>>>> 2. Use it in a command along with MAVEN_MODULES_STRING.
>>>>>>> -U -Pall-java,all-scala,scala,lgpl,examples %MAVEN_CHECKS%
>>>>>>> %MAVEN_MODULES_STRING%
>>>>>>> 
>>>>>>> 3. Provide a global param for test suites
>> "reverse.dep.MAVEN_CHECKS"
>>>>> that
>>>>>>> is possible to override in a custom build. If I understand it
>>>>> correctly is
>>>>>>> possible to do by editing the job [1].
>>>>>>> 4. This param should be represented to a user as a selector with 2
>>>>>>> options:
>>>>>>> - default (see point 1.)
>>>>>>> - "-DskipTests=true" - that ignores all checks, skip tests and
>> just
>>>>> build
>>>>>>> a .zip of Ignite.
>>>>>>> 
>>>>>>> Could you please review this solution? Is it OK for you?
>>>>>>> 
>>>>>>> [1]
>>>>>>> 
>>>>> 
>> https://ci.ignite.apache.org/admin/editBuildParams.h

Re: [DISCUSS] Missed (non-suited) tests

[Petr Ivanov]

If profile can handle this — its ok.

For choosing build type — we can introduce select, that will choose between -p 
 and -DskipTests=true (defaulting to profile).
Thus [Build] will pass either way.


Regards,
Petr Ivanov
Head of IT
IT & Development Solutions | GRIDGAIN SYSTEMS
+7 (911) 945-00-59

> On 25 Feb 2021, at 13:23, Max Timonin  wrote:
> 
> Yes, it's correct that "mvn install" runs also the "mvn test" command, and
> this is OK as the check-test-suites profile handles all tests
> without running them. If the skipTests flag is triggered then this check is
> useless. It will take only about 2 min to run "mvn test" with this profile.
> Travis does that as one of steps.
> 
> So, there are no issues with tests. Should I provide more info how this
> check works?
> 
> Also, discussed with Anton Vinogradov, Alex Plekhanov. There can be an
> issue, that sometimes it's required to run custom test suites to debug
> flaky tests. Sequence of steps is the following:
> 1. Find a test suite with flaky tests (that reproducible only on an
> TeamCity agent);
> 2. Comment some tests in the suite to isolate;
> 3. Push it, and run related TC suite;
> 4. TC suite depends on [Build] job, run the job - it will fail on the check
> "check-test-suites".
> 
> So it is needed to provide a configuration to disable this check such runs.
> I'll have a look on next week how to implement this.
> 
> On Thu, Feb 25, 2021 at 11:02 AM Petr Ivanov  wrote:
> 
>> I am telling that INSTALL goal for maven will trigger TEST goal for the
>> whole project and it cannot be prevented until the flag is specified either
>> as command line parameter, or in profile somehow to be inherited by other
>> modules.
>> Thats why I am suggesting this as separate suite.
>> 
>> 
>> Regards,
>> *Petr Ivanov*
>> Head of IT
>> IT & Development Solutions |
>> *GRIDGAIN SYSTEMS*+7 (911) 945-00-59
>> 
>> On 25 Feb 2021, at 10:44, Max Timonin  wrote:
>> 
>> Hi, Petr!
>> 
>> Profile "check-test-suites" handles all tests in another way, it just
>> verifies that all tests are suited. No tests run then.
>> As I understand the [BUILD] job goal is preparing a .zip archive to
>> distribute it for other jobs. I think it is a valid place to put sanity
>> checks. If a check fails then no archive is prepared. WDYT?
>> 
>> Also I see that there is a flag -Dmaven.javadoc.skip=true. I'd propose to
>> change it to the profile "skip-docs", that was introduced in ticket [1]
>> IGNITE-13623. As the setting "maven.javadoc.skip" does not
>> affect scaladocs.
>> 
>> [1] https://issues.apache.org/jira/browse/IGNITE-13623
>> 
>> On Thu, Feb 25, 2021 at 7:34 AM Petr Ivanov  wrote:
>> 
>>> Won't the absence of -DskipTests flag trigger ALL the tests for all
>>> modules?
>>> This flag was added intentionally.
>>> 
>>> Instead, I'd put Non-Suited tests into some kind of sanity check, group
>>> all sanity checks in single Run All, and make tests depend on it's
>>> successful pass.
>>> 
>>> 
>>> Regards,
>>> *Petr Ivanov*
>>> Head of IT
>>> IT & Development Solutions |
>>> *GRIDGAIN SYSTEMS*+7 (911) 945-00-59
>>> 
>>> On 24 Feb 2021, at 19:58, Max Timonin  wrote:
>>> 
>>> Hi, all!
>>> 
>>> What do you think if we add the check in the TC [Build] job. Currently
>>> [Build] runs also check for licences, checkstyle [1]:
>>> 
>>> mvn *install* -Pall-java,all-scala,scala,*licenses*,lgpl,examples,
>>> *checkstyle* -DskipTests -Dmaven.javadoc.skip=true
>>> %MAVEN_MODULES_STRING%.
>>> 
>>> So let's add the check too to block other jobs. As if there missed tests
>>> then TC run may be invalid - missed tests may be broken and then the MTCGA
>>> visa too. To made this we should change command line parameters:
>>> 1. Add profile check-test-suites;
>>> 2. Remove -Dskiptests flag.
>>> 
>>> -Pall-java,all-scala,scala,licenses,lgpl,examples,checkstyle,
>>> *check-test-suites *-DskipTests -Dmaven.javadoc.skip=true
>>> %MAVEN_MODULES_STRING%
>>> 
>>> WDYT?
>>> 
>>> [1]
>>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite=buildTypeSettings_IgniteTests24Java8=%3Cdefault
>>> 
>>> On Tue, Feb 9, 2021 at 4:48 PM Ilya Kasnacheev 
>>> wrote:
>>> 
>>>> Hello again!
>>>> 
>>>> Of course it's 20 minutes, n

Re: [DISCUSS] Missed (non-suited) tests

[Petr Ivanov]

I am telling that INSTALL goal for maven will trigger TEST goal for the whole 
project and it cannot be prevented until the flag is specified either as 
command line parameter, or in profile somehow to be inherited by other modules.
Thats why I am suggesting this as separate suite.


Regards,
Petr Ivanov
Head of IT
IT & Development Solutions | GRIDGAIN SYSTEMS
+7 (911) 945-00-59

> On 25 Feb 2021, at 10:44, Max Timonin  wrote:
> 
> Hi, Petr!
> 
> Profile "check-test-suites" handles all tests in another way, it just 
> verifies that all tests are suited. No tests run then. 
> As I understand the [BUILD] job goal is preparing a .zip archive to 
> distribute it for other jobs. I think it is a valid place to put sanity 
> checks. If a check fails then no archive is prepared. WDYT?
> 
> Also I see that there is a flag -Dmaven.javadoc.skip=true. I'd propose to 
> change it to the profile "skip-docs", that was introduced in ticket [1] 
> IGNITE-13623. As the setting "maven.javadoc.skip" does not affect scaladocs. 
> 
> [1] https://issues.apache.org/jira/browse/IGNITE-13623 
> <https://issues.apache.org/jira/browse/IGNITE-13623>
> On Thu, Feb 25, 2021 at 7:34 AM Petr Ivanov  <mailto:piva...@gridgain.com>> wrote:
> Won't the absence of -DskipTests flag trigger ALL the tests for all modules?
> This flag was added intentionally.
> 
> Instead, I'd put Non-Suited tests into some kind of sanity check, group all 
> sanity checks in single Run All, and make tests depend on it's successful 
> pass.
> 
> 
> Regards,
> Petr Ivanov
> Head of IT
> IT & Development Solutions | GRIDGAIN SYSTEMS
> +7 (911) 945-00-59
> 
>> On 24 Feb 2021, at 19:58, Max Timonin > <mailto:timonin.ma...@gmail.com>> wrote:
>> 
>> Hi, all!
>> 
>> What do you think if we add the check in the TC [Build] job. Currently 
>> [Build] runs also check for licences, checkstyle [1]:
>> 
>> mvn install -Pall-java,all-scala,scala,licenses,lgpl,examples,checkstyle 
>> -DskipTests -Dmaven.javadoc.skip=true %MAVEN_MODULES_STRING%.
>> 
>> So let's add the check too to block other jobs. As if there missed tests 
>> then TC run may be invalid - missed tests may be broken and then the MTCGA 
>> visa too. To made this we should change command line parameters:
>> 1. Add profile check-test-suites;
>> 2. Remove -Dskiptests flag.
>> 
>> -Pall-java,all-scala,scala,licenses,lgpl,examples,checkstyle,check-test-suites
>>  -DskipTests -Dmaven.javadoc.skip=true %MAVEN_MODULES_STRING%
>> 
>> WDYT?
>> 
>> [1] 
>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite=buildTypeSettings_IgniteTests24Java8=%3Cdefault
>>  
>> <https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite=buildTypeSettings_IgniteTests24Java8=%3Cdefault>
>> On Tue, Feb 9, 2021 at 4:48 PM Ilya Kasnacheev > <mailto:ilya.kasnach...@gmail.com>> wrote:
>> Hello again!
>> 
>> Of course it's 20 minutes, not 20 seconds.
>> 
>> Regards,
>> -- 
>> Ilya Kasnacheev
>> 
>> 
>> вт, 9 февр. 2021 г. в 16:45, Ilya Kasnacheev > <mailto:ilya.kasnach...@gmail.com>>:
>> 
>> > Hello!
>> >
>> > Java part kicks in if the target not found in pom.xml. Ideally we should
>> > skip this build if target check-test-suites is not in pom.xml
>> >
>> > I have changed its timeout to 20 second which should terminate its
>> > progression on older builds. Maybe that would be sufficient for now.
>> >
>> > Regards,
>> > --
>> > Ilya Kasnacheev
>> >
>> >
>> > вт, 9 февр. 2021 г. в 14:09, Petr Ivanov > > <mailto:piva...@gridgain.com>>:
>> >
>> >> As much as I understood — we execute internal class as plugin, where all
>> >> the magic is done.
>> >> Seems pretty solid in Maven part. Java part, unfortunately, cannot check.
>> >>
>> >>
>> >>
>> >> Regards,
>> >> *Petr Ivanov*
>> >> Head of IT
>> >> IT & Development Solutions |
>> >> *GRIDGAIN SYSTEMS*+7 (911) 945-00-59
>> >>
>> >> On 9 Feb 2021, at 12:32, Ilya Kasnacheev > >> <mailto:ilya.kasnach...@gmail.com>>
>> >> wrote:
>> >>
>> >> Hello Peter,
>> >>
>> >> Thanks for chiming in. The code is under
>> >> https://github.com/apache/ignite/pull/8367 
>> >> <https://github.com/apache/ignite/pull/8367>
>>

Re: [DISCUSS] Missed (non-suited) tests

[Petr Ivanov]

Won't the absence of -DskipTests flag trigger ALL the tests for all modules?
This flag was added intentionally.

Instead, I'd put Non-Suited tests into some kind of sanity check, group all 
sanity checks in single Run All, and make tests depend on it's successful pass.


Regards,
Petr Ivanov
Head of IT
IT & Development Solutions | GRIDGAIN SYSTEMS
+7 (911) 945-00-59

> On 24 Feb 2021, at 19:58, Max Timonin  wrote:
> 
> Hi, all!
> 
> What do you think if we add the check in the TC [Build] job. Currently 
> [Build] runs also check for licences, checkstyle [1]:
> 
> mvn install -Pall-java,all-scala,scala,licenses,lgpl,examples,checkstyle 
> -DskipTests -Dmaven.javadoc.skip=true %MAVEN_MODULES_STRING%.
> 
> So let's add the check too to block other jobs. As if there missed tests then 
> TC run may be invalid - missed tests may be broken and then the MTCGA visa 
> too. To made this we should change command line parameters:
> 1. Add profile check-test-suites;
> 2. Remove -Dskiptests flag.
> 
> -Pall-java,all-scala,scala,licenses,lgpl,examples,checkstyle,check-test-suites
>  -DskipTests -Dmaven.javadoc.skip=true %MAVEN_MODULES_STRING%
> 
> WDYT?
> 
> [1] 
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite=buildTypeSettings_IgniteTests24Java8=%3Cdefault
>  
> <https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite=buildTypeSettings_IgniteTests24Java8=%3Cdefault>
> On Tue, Feb 9, 2021 at 4:48 PM Ilya Kasnacheev  <mailto:ilya.kasnach...@gmail.com>> wrote:
> Hello again!
> 
> Of course it's 20 minutes, not 20 seconds.
> 
> Regards,
> -- 
> Ilya Kasnacheev
> 
> 
> вт, 9 февр. 2021 г. в 16:45, Ilya Kasnacheev  <mailto:ilya.kasnach...@gmail.com>>:
> 
> > Hello!
> >
> > Java part kicks in if the target not found in pom.xml. Ideally we should
> > skip this build if target check-test-suites is not in pom.xml
> >
> > I have changed its timeout to 20 second which should terminate its
> > progression on older builds. Maybe that would be sufficient for now.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > вт, 9 февр. 2021 г. в 14:09, Petr Ivanov  > <mailto:piva...@gridgain.com>>:
> >
> >> As much as I understood — we execute internal class as plugin, where all
> >> the magic is done.
> >> Seems pretty solid in Maven part. Java part, unfortunately, cannot check.
> >>
> >>
> >>
> >> Regards,
> >> *Petr Ivanov*
> >> Head of IT
> >> IT & Development Solutions |
> >> *GRIDGAIN SYSTEMS*+7 (911) 945-00-59
> >>
> >> On 9 Feb 2021, at 12:32, Ilya Kasnacheev  >> <mailto:ilya.kasnach...@gmail.com>>
> >> wrote:
> >>
> >> Hello Peter,
> >>
> >> Thanks for chiming in. The code is under
> >> https://github.com/apache/ignite/pull/8367 
> >> <https://github.com/apache/ignite/pull/8367>
> >>
> >> Regards,
> >> --
> >> Ilya Kasnacheev
> >>
> >>
> >> вт, 9 февр. 2021 г. в 12:20, Petr Ivanov  >> <mailto:piva...@gridgain.com>>:
> >>
> >>> Hi, Ilya.
> >>>
> >>>
> >>> I've added Inspections to Run All.
> >>> Checkstyle is currently integrated to Build and can be deleted.
> >>>
> >>>
> >>> Where can I find the code for check-test-suites profile?
> >>>
> >>>
> >>> Regards,
> >>> *Petr Ivanov*
> >>> Head of IT
> >>> IT & Development Solutions |
> >>> *GRIDGAIN SYSTEMS*+7 (911) 945-00-59
> >>>
> >>> On 9 Feb 2021, at 12:16, Ilya Kasnacheev  >>> <mailto:ilya.kasnach...@gmail.com>>
> >>> wrote:
> >>>
> >>> Hello!
> >>>
> >>> I have found one issue where it would cause tests to be run if the
> >>> change is not present in the target branch.
> >>>
> >>> This includes e.g. 2.10 nightlies.
> >>>
> >>> What can we do to avoid that? Is specifying -DskipTests sufficient? Any
> >>> chance that it will break the missed tests check?
> >>>
> >>> Regards,
> >>> --
> >>> Ilya Kasnacheev
> >>>
> >>>
> >>> пн, 8 февр. 2021 г. в 14:13, Ilya Kasnacheev  >>> <mailto:ilya.kasnach...@gmail.com>
> >>> >:
> >>>
> >>>> Hello!
> >>>>
> >>>> I have

Re: TeamCity agent aitc-lin07_04 fails to run Build

[Petr Ivanov]

I'm sorry, I forgot to write on dev-list about this agent.
Indeed the target files were removed manually.



> On 24 Feb 2021, at 19:32, Max Timonin  wrote:
> 
> Looks like somebody fixed that. An hour ago Build succeeded at last [1]. It
> was the first successful job for a long time. Thanks!
> 
> removed directory '/opt/buildagent/.m2/repository/org/apache/ignite'
> Process exited with code 0
> 
> [1]
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_BuildApacheIgnite/5890154
> 
> On Wed, Feb 24, 2021 at 10:10 AM Max Timonin 
> wrote:
> 
>> Hi!
>> 
>> My "Build" runs on TC fail with on 1 (Step: Cleanup local maven
>> repository (Command Line))
>> 
>> Error is related to AI 3.0.0:
>> 
>> + rm -rfv /opt/buildagent/.m2/repository/org/apache/ignite
>> 
>> rm: cannot remove
>> '/opt/buildagent/.m2/repository/org/apache/ignite/ignite-configuration/
>> *3.0.0-SNAPSHOT*/_remote.repositories': *Permission denied*
>> 
>> As I can see this error is only on aitc-lin07_04 agent. The first time it
>> appeared 16th of February [1]
>> 
>> [1]
>> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_BuildApacheIgnite/5876992
>> 
>> How can we fix this?
>> 

Apache Ignite 3 / RPM

[Petr Ivanov]

Hi, Igniters.


Sincerely asking you to help me with testing new RPM package for apache ignite 
3.x [1]
Currently what is needed to be tested — successful installation and binary run 
under most of RHEL based distributions: Red Hat, CentOS, Oracle Linux, Fedora, 
etc.

Any other thoughts and suggestions are more than welcome too.
RPM assembly code can be found here [2]


Thanks in advance!



[1] 
https://issues.apache.org/jira/secure/attachment/13021121/apache-ignite-3.0.0-1.noarch.rpm
[2] https://github.com/apache/ignite-3/pull/29/files

Re: Apache Ignite 3.x: order in repository

[Petr Ivanov]

I'd guess that one of the main problem with inactive PRs is in creation of PR 
for reviewing but merging it from command line (not via GitHub interface).
Also, of course, there are lots of efforts which are abandoned after first 
review, or even do not have a chance to be reviewed at all.


> On 22 Feb 2021, at 11:51, Stephen Darlington 
>  wrote:
> 
> I think we need to be able answer the question “Why are there so many 
> inactive PRs?" before we automate their removal. If perfectly good changes 
> are being ignored, we have a problem.
> 
> Removing branches of merged PRs and protecting the main branch make sense.
> 
>> On 20 Feb 2021, at 18:30, Pavel Tupitsyn  wrote:
>> 
>> +1
>> 
>> - Close inactive PRs (1 month or so?)
>> - Enable main branch protection (no force pushes, require linear history,
>> require status checks)
>> 
>> On Sat, Feb 20, 2021 at 2:31 PM Petr Ivanov  wrote:
>> 
>>> Hi, Igniters!
>>> 
>>> 
>>> When we started Ignite 3.x in new repository, not only we have received a
>>> chance to cleanup codebase, but to maintain some order in development
>>> tools, like GitHub.
>>> Currently in 2.x repository we have lots of stalled PRs and branches,
>>> which not only clog the repository, but also indirectly influence TC
>>> performance (due to necessity to check for updates every ref: branches and
>>> PRs).
>>> 
>>> Could I suggest we devise some recommendations for using PR's and branches
>>> in new repo and add some rules about stalled PRs at least, like closing
>>> them if inactive for some time.
>>> Also we can activate some settings in repo's configuration, like auto
>>> delete branch after PR is merged.
>>> 
>>> 
>>> WDYT?
> 
> 

Apache Ignite 3.x: order in repository

[Petr Ivanov]

Hi, Igniters!


When we started Ignite 3.x in new repository, not only we have received a 
chance to cleanup codebase, but to maintain some order in development tools, 
like GitHub.
Currently in 2.x repository we have lots of stalled PRs and branches, which not 
only clog the repository, but also indirectly influence TC performance (due to 
necessity to check for updates every ref: branches and PRs).

Could I suggest we devise some recommendations for using PR's and branches in 
new repo and add some rules about stalled PRs at least, like closing them if 
inactive for some time.
Also we can activate some settings in repo's configuration, like auto delete 
branch after PR is merged.


WDYT?

Re: Ignite Extensions tests

[Petr Ivanov]

Can you pinpoint exact string in log where another Ignite node is interfering, 
please?


> On 10 Feb 2021, at 11:50, Mikhail Petrov  wrote:
> 
> Here is an example - [1].
> 
> [1] - 
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteExtensions_Tests_SpringTransactions_IgniteExtensions_Tests=%3Cdefault%3E=buildTypeStatusDiv
>  
> On 10.02.2021 11:39, Petr Ivanov wrote:
>> Very good, thanks!
>> I will prepare build shortly.
>> 
>> About flakiness — send me link to build where problem is, I will try to 
>> investigate.
>> 
>>> On 10 Feb 2021, at 11:17, Mikhail Petrov  wrote:
>>> 
>>> Petr, ticket [1] was merged to the master branch. TC build is ok now - [2]. 
>>> Sometimes i faced that some tests can be flaky because test nodes were 
>>> trying to join extra incompatible node that does not belong to the test. 
>>> But I think we could investigate it in a separate ticket.
>>> 
>>> Could I ask you to create separate test suite for the Spring Cache 
>>> extension similar to Spring Transactions for the following PR:  
>>> https://github.com/apache/ignite-extensions/pull/42
>>> 
>>> [1] - https://issues.apache.org/jira/browse/IGNITE-14150
>>> 
>>> [2] - 
>>> https://ci.ignite.apache.org/project.html?projectId=IgniteExtensions_Tests_IgniteExtensions_Tests=%3Cdefault%3E
>>> 
>>> On 10.02.2021 10:40, Petr Ivanov wrote:
>>>> I've updated Extensions template to use only Linux agents.
>>>> 
>>>> Will wait for ticket in master, thanks!
>>>> 
>>>> 
>>>> 
>>>>> On 10 Feb 2021, at 01:05, Mikhail Petrov  wrote:
>>>>> 
>>>>> Hi, Petr.
>>>>> 
>>>>> It seems that the problem is in an outdated version of the maven surefire 
>>>>> plugin that is used in ignite-extensions.
>>>>> 
>>>>> I created the corresponding ticket [1].
>>>>> 
>>>>> I also faced that current ignite-extensions build is broken on windows 
>>>>> agents - [2]. It fails with the following error:
>>>>> 
>>>>> /[22:47:43]'#!' is not recognized as an internal or external command,
>>>>> [22:47:43]operable program or batch file.
>>>>> [22:47:43]Environment variable -o nounset; set -o errexit; set -o 
>>>>> pipefail; set -o errtrace; set -o functrace not defined
>>>>> [22:47:43]Environment variable -x not defined
>>>>> [22:47:43]'rm' is not recognized as an internal or external command,
>>>>> [22:47:43]operable program or batch file.
>>>>> [22:47:43]The syntax of the command is incorrect.
>>>>> [22:47:43]'cp' is not recognized as an internal or external command,
>>>>> [22:47:43]operable program or batch file.
>>>>> [22:47:43]Process exited with code 1/
>>>>> 
>>>>> 
>>>>> Could you check it, please?
>>>>> 
>>>>> 
>>>>> [1] - https://issues.apache.org/jira/browse/IGNITE-14150
>>>>> 
>>>>> [2] - 
>>>>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteExtensions_Tests_Flink_IgniteExtensions_Tests=%3Cdefault%3E=buildTypeStatusDiv
>>>>> 
>>>>> On 09.02.2021 13:36, Petr Ivanov wrote:
>>>>>> Hi, Nikolay.
>>>>>> 
>>>>>> 
>>>>>> I've created a set of tests for extensions, and part of them are failing 
>>>>>> with:
>>>>>> 
>>>>>> JUnit4Provider.invoke:159->executeTestSet:238->executeWithRerun:273->execute:365
>>>>>>  » NoSuchMethod
>>>>>> java.lang.NoSuchMethodError: 
>>>>>> org.apache.maven.surefire.report.SimpleReportEntry.withException(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Lorg/apache/maven/surefire/report/StackTraceWriter;)Lorg/apache/maven/surefire/report/SimpleReportEntry;
>>>>>> at 
>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>>>>>> at 
>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
>>>>>> at 
>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
>>>>>> at 
>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
>>>>>> 
>>>>>> 
>>>>>> Could you check [1] please?
>>>>>> 
>>>>>> 
>>>>>> [1] 
>>>>>> https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_RunAllTests/5864907?buildTab=dependencies=list
>>>>>> 

Re: Ignite Extensions tests

[Petr Ivanov]

Very good, thanks!
I will prepare build shortly.

About flakiness — send me link to build where problem is, I will try to 
investigate.

> On 10 Feb 2021, at 11:17, Mikhail Petrov  wrote:
> 
> Petr, ticket [1] was merged to the master branch. TC build is ok now - [2]. 
> Sometimes i faced that some tests can be flaky because test nodes were trying 
> to join extra incompatible node that does not belong to the test. But I think 
> we could investigate it in a separate ticket.
> 
> Could I ask you to create separate test suite for the Spring Cache extension 
> similar to Spring Transactions for the following PR:  
> https://github.com/apache/ignite-extensions/pull/42
> 
> [1] - https://issues.apache.org/jira/browse/IGNITE-14150
> 
> [2] - 
> https://ci.ignite.apache.org/project.html?projectId=IgniteExtensions_Tests_IgniteExtensions_Tests=%3Cdefault%3E
> 
> On 10.02.2021 10:40, Petr Ivanov wrote:
>> I've updated Extensions template to use only Linux agents.
>> 
>> Will wait for ticket in master, thanks!
>> 
>> 
>> 
>>> On 10 Feb 2021, at 01:05, Mikhail Petrov  wrote:
>>> 
>>> Hi, Petr.
>>> 
>>> It seems that the problem is in an outdated version of the maven surefire 
>>> plugin that is used in ignite-extensions.
>>> 
>>> I created the corresponding ticket [1].
>>> 
>>> I also faced that current ignite-extensions build is broken on windows 
>>> agents - [2]. It fails with the following error:
>>> 
>>> /[22:47:43]'#!' is not recognized as an internal or external command,
>>> [22:47:43]operable program or batch file.
>>> [22:47:43]Environment variable -o nounset; set -o errexit; set -o pipefail; 
>>> set -o errtrace; set -o functrace not defined
>>> [22:47:43]Environment variable -x not defined
>>> [22:47:43]'rm' is not recognized as an internal or external command,
>>> [22:47:43]operable program or batch file.
>>> [22:47:43]The syntax of the command is incorrect.
>>> [22:47:43]'cp' is not recognized as an internal or external command,
>>> [22:47:43]operable program or batch file.
>>> [22:47:43]Process exited with code 1/
>>> 
>>> 
>>> Could you check it, please?
>>> 
>>> 
>>> [1] - https://issues.apache.org/jira/browse/IGNITE-14150
>>> 
>>> [2] - 
>>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteExtensions_Tests_Flink_IgniteExtensions_Tests=%3Cdefault%3E=buildTypeStatusDiv
>>> 
>>> On 09.02.2021 13:36, Petr Ivanov wrote:
>>>> Hi, Nikolay.
>>>> 
>>>> 
>>>> I've created a set of tests for extensions, and part of them are failing 
>>>> with:
>>>> 
>>>> JUnit4Provider.invoke:159->executeTestSet:238->executeWithRerun:273->execute:365
>>>>  » NoSuchMethod
>>>> java.lang.NoSuchMethodError: 
>>>> org.apache.maven.surefire.report.SimpleReportEntry.withException(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Lorg/apache/maven/surefire/report/StackTraceWriter;)Lorg/apache/maven/surefire/report/SimpleReportEntry;
>>>> at 
>>>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>>>> at 
>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
>>>> at 
>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
>>>> at 
>>>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
>>>> 
>>>> 
>>>> Could you check [1] please?
>>>> 
>>>> 
>>>> [1] 
>>>> https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_RunAllTests/5864907?buildTab=dependencies=list
>>>> 

Re: Ignite Extensions tests

[Petr Ivanov]

I've updated Extensions template to use only Linux agents.

Will wait for ticket in master, thanks!



> On 10 Feb 2021, at 01:05, Mikhail Petrov  wrote:
> 
> Hi, Petr.
> 
> It seems that the problem is in an outdated version of the maven surefire 
> plugin that is used in ignite-extensions.
> 
> I created the corresponding ticket [1].
> 
> I also faced that current ignite-extensions build is broken on windows agents 
> - [2]. It fails with the following error:
> 
> /[22:47:43]'#!' is not recognized as an internal or external command,
> [22:47:43]operable program or batch file.
> [22:47:43]Environment variable -o nounset; set -o errexit; set -o pipefail; 
> set -o errtrace; set -o functrace not defined
> [22:47:43]Environment variable -x not defined
> [22:47:43]'rm' is not recognized as an internal or external command,
> [22:47:43]operable program or batch file.
> [22:47:43]The syntax of the command is incorrect.
> [22:47:43]'cp' is not recognized as an internal or external command,
> [22:47:43]operable program or batch file.
> [22:47:43]Process exited with code 1/
> 
> 
> Could you check it, please?
> 
> 
> [1] - https://issues.apache.org/jira/browse/IGNITE-14150
> 
> [2] - 
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteExtensions_Tests_Flink_IgniteExtensions_Tests=%3Cdefault%3E=buildTypeStatusDiv
> 
> On 09.02.2021 13:36, Petr Ivanov wrote:
>> Hi, Nikolay.
>> 
>> 
>> I've created a set of tests for extensions, and part of them are failing 
>> with:
>> 
>> JUnit4Provider.invoke:159->executeTestSet:238->executeWithRerun:273->execute:365
>>  » NoSuchMethod
>> java.lang.NoSuchMethodError: 
>> org.apache.maven.surefire.report.SimpleReportEntry.withException(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Lorg/apache/maven/surefire/report/StackTraceWriter;)Lorg/apache/maven/surefire/report/SimpleReportEntry;
>> at 
>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>> at 
>> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
>> at 
>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
>> at 
>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
>> 
>> 
>> Could you check [1] please?
>> 
>> 
>> [1] 
>> https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_RunAllTests/5864907?buildTab=dependencies=list
>> 

Re: [DISCUSS] Missed (non-suited) tests

[Petr Ivanov]

As much as I understood — we execute internal class as plugin, where all the 
magic is done.
Seems pretty solid in Maven part. Java part, unfortunately, cannot check.



Regards,
Petr Ivanov
Head of IT
IT & Development Solutions | GRIDGAIN SYSTEMS
+7 (911) 945-00-59

> On 9 Feb 2021, at 12:32, Ilya Kasnacheev  wrote:
> 
> Hello Peter,
> 
> Thanks for chiming in. The code is under 
> https://github.com/apache/ignite/pull/8367 
> <https://github.com/apache/ignite/pull/8367>
> 
> Regards,
> -- 
> Ilya Kasnacheev
> 
> 
> вт, 9 февр. 2021 г. в 12:20, Petr Ivanov  <mailto:piva...@gridgain.com>>:
> Hi, Ilya.
> 
> 
> I've added Inspections to Run All.
> Checkstyle is currently integrated to Build and can be deleted.
> 
> 
> Where can I find the code for check-test-suites profile?
> 
> 
> Regards,
> Petr Ivanov
> Head of IT
> IT & Development Solutions | GRIDGAIN SYSTEMS
> +7 (911) 945-00-59
> 
>> On 9 Feb 2021, at 12:16, Ilya Kasnacheev > <mailto:ilya.kasnach...@gmail.com>> wrote:
>> 
>> Hello!
>> 
>> I have found one issue where it would cause tests to be run if the change is 
>> not present in the target branch.
>> 
>> This includes e.g. 2.10 nightlies.
>> 
>> What can we do to avoid that? Is specifying -DskipTests sufficient? Any 
>> chance that it will break the missed tests check?
>> 
>> Regards,
>> -- 
>> Ilya Kasnacheev
>> 
>> 
>> пн, 8 февр. 2021 г. в 14:13, Ilya Kasnacheev > <mailto:ilya.kasnach...@gmail.com>>:
>> Hello!
>> 
>> I have created a TC suite:
>> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_MissingTests?mode=builds
>>  
>> <https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_MissingTests?mode=builds>
>> 
>> + Peter Ivanov
>> 
>> Can you please check if everything is alright?
>> 
>> BTW, it seems that Inspections [Core] is only in Run All Basic (but not in 
>> Run All), and Check Code Style is not triggered by either one. Is it correct?
>> 
>> Regards,
>> -- 
>> Ilya Kasnacheev
>> 
>> 
>> пн, 8 февр. 2021 г. в 10:22, Max Timonin > <mailto:timonin.ma...@gmail.com>>:
>> Hi!
>> 
>> Yes, now it's a part of the Travis check, and there is already a first
>> successful build [1]. But I think it's also required to run the check on TC
>> too, along with jobs for checking licenses, code style, and core
>> inspections.
>> 
>> 
>> [1] https://travis-ci.com/github/apache/ignite/builds/216363067 
>> <https://travis-ci.com/github/apache/ignite/builds/216363067>
>> 
>> On Fri, Feb 5, 2021 at 7:13 PM Ilya Kasnacheev > <mailto:ilya.kasnach...@gmail.com>>
>> wrote:
>> 
>> > Hello!
>> >
>> > I have merged it to master!
>> >
>> > I wonder what happens next. It will run as a part of travis check? Do we
>> > also need to add it as a TC suite?
>> >
>> > Regards,
>> > --
>> > Ilya Kasnacheev
>> >
>> >
>> > ср, 3 февр. 2021 г. в 18:50, Ilya Kasnacheev > > <mailto:ilya.kasnach...@gmail.com>>:
>> >
>> > > Hello!
>> > >
>> > > Code mostly looks good, I have added a minor request. I will check how it
>> > > works and then we may commit.
>> > >
>> > > + zaleslaw@gmail.com <mailto:zaleslaw@gmail.com>
>> > >
>> > > Can you please check whether the new ML suites make sense?
>> > > math/distances/DistancesTestSuite.java
>> > > naivebayes/NaiveBayesTestSuite.java
>> > >
>> > > Would we need to add them to some TC runs?
>> > >
>> > > Regards,
>> > > --
>> > > Ilya Kasnacheev
>> > >
>> > >
>> > > пн, 25 янв. 2021 г. в 22:07, Max Timonin > > > <mailto:timonin.ma...@gmail.com>>:
>> > >
>> > >> Hi, Ilya!
>> > >>
>> > >> I made a fix to the check. Now it aggregates info about tests and suites
>> > >> from all modules and then validates it. Could you please review the PR
>> > >> [1]?
>> > >>
>> > >> I tried to move some tests between modules, but unfortunately it still
>> > >> looks like spaghetti. So I reverted all changes to testsuites (new and
>> > >> splitted suites) and reworked the check.
>> > >>
>> > >> [1] https://github.com/apache/ignite/pull/83

Re: [DISCUSS] Missed (non-suited) tests

[Petr Ivanov]

Hi, Ilya.


I've added Inspections to Run All.
Checkstyle is currently integrated to Build and can be deleted.


Where can I find the code for check-test-suites profile?


Regards,
Petr Ivanov
Head of IT
IT & Development Solutions | GRIDGAIN SYSTEMS
+7 (911) 945-00-59

> On 9 Feb 2021, at 12:16, Ilya Kasnacheev  wrote:
> 
> Hello!
> 
> I have found one issue where it would cause tests to be run if the change is 
> not present in the target branch.
> 
> This includes e.g. 2.10 nightlies.
> 
> What can we do to avoid that? Is specifying -DskipTests sufficient? Any 
> chance that it will break the missed tests check?
> 
> Regards,
> -- 
> Ilya Kasnacheev
> 
> 
> пн, 8 февр. 2021 г. в 14:13, Ilya Kasnacheev  <mailto:ilya.kasnach...@gmail.com>>:
> Hello!
> 
> I have created a TC suite:
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_MissingTests?mode=builds
>  
> <https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_MissingTests?mode=builds>
> 
> + Peter Ivanov
> 
> Can you please check if everything is alright?
> 
> BTW, it seems that Inspections [Core] is only in Run All Basic (but not in 
> Run All), and Check Code Style is not triggered by either one. Is it correct?
> 
> Regards,
> -- 
> Ilya Kasnacheev
> 
> 
> пн, 8 февр. 2021 г. в 10:22, Max Timonin  <mailto:timonin.ma...@gmail.com>>:
> Hi!
> 
> Yes, now it's a part of the Travis check, and there is already a first
> successful build [1]. But I think it's also required to run the check on TC
> too, along with jobs for checking licenses, code style, and core
> inspections.
> 
> 
> [1] https://travis-ci.com/github/apache/ignite/builds/216363067 
> <https://travis-ci.com/github/apache/ignite/builds/216363067>
> 
> On Fri, Feb 5, 2021 at 7:13 PM Ilya Kasnacheev  <mailto:ilya.kasnach...@gmail.com>>
> wrote:
> 
> > Hello!
> >
> > I have merged it to master!
> >
> > I wonder what happens next. It will run as a part of travis check? Do we
> > also need to add it as a TC suite?
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > ср, 3 февр. 2021 г. в 18:50, Ilya Kasnacheev  > <mailto:ilya.kasnach...@gmail.com>>:
> >
> > > Hello!
> > >
> > > Code mostly looks good, I have added a minor request. I will check how it
> > > works and then we may commit.
> > >
> > > + zaleslaw@gmail.com <mailto:zaleslaw@gmail.com>
> > >
> > > Can you please check whether the new ML suites make sense?
> > > math/distances/DistancesTestSuite.java
> > > naivebayes/NaiveBayesTestSuite.java
> > >
> > > Would we need to add them to some TC runs?
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > пн, 25 янв. 2021 г. в 22:07, Max Timonin  > > <mailto:timonin.ma...@gmail.com>>:
> > >
> > >> Hi, Ilya!
> > >>
> > >> I made a fix to the check. Now it aggregates info about tests and suites
> > >> from all modules and then validates it. Could you please review the PR
> > >> [1]?
> > >>
> > >> I tried to move some tests between modules, but unfortunately it still
> > >> looks like spaghetti. So I reverted all changes to testsuites (new and
> > >> splitted suites) and reworked the check.
> > >>
> > >> [1] https://github.com/apache/ignite/pull/8367 
> > >> <https://github.com/apache/ignite/pull/8367>
> > >>
> > >> On Mon, Dec 28, 2020 at 2:03 PM Ilya Kasnacheev <
> > >> ilya.kasnach...@gmail.com <mailto:ilya.kasnach...@gmail.com>>
> > >> wrote:
> > >>
> > >> > Hello!
> > >> >
> > >> > You could try to move these tests as .java files between modules in a
> > >> > separate commit. I think I could review it.
> > >> >
> > >> > Regards,
> > >> > --
> > >> > Ilya Kasnacheev
> > >> >
> > >> >
> > >> > пт, 25 дек. 2020 г. в 17:19, Max Timonin  > >> > <mailto:timonin.ma...@gmail.com>>:
> > >> >
> > >> > > Hi!
> > >> > >
> > >> > > Ilya thanks for the reply! I agree that it's a valid case when a
> > test
> > >> is
> > >> > > part of multiple suites in different modules. But it is definitely a
> > >> bug
> > >> > > that the te

Ignite Extensions tests

[Petr Ivanov]

Hi, Nikolay.


I've created a set of tests for extensions, and part of them are failing with:

JUnit4Provider.invoke:159->executeTestSet:238->executeWithRerun:273->execute:365
 » NoSuchMethod
java.lang.NoSuchMethodError: 
org.apache.maven.surefire.report.SimpleReportEntry.withException(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Lorg/apache/maven/surefire/report/StackTraceWriter;)Lorg/apache/maven/surefire/report/SimpleReportEntry;
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)


Could you check [1] please?


[1] 
https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_RunAllTests/5864907?buildTab=dependencies=list

Re: Request of TC permissions

[Petr Ivanov]

Thanks for checking this out, Mikhail.


I will add other suites with the same setup later this week.

> On 8 Feb 2021, at 11:42, Mikhail Petrov  wrote:
> 
> Petr,
> 
> 
> It works. Thank you very much.
> 
> On 05.02.2021 14:49, Petr Ivanov wrote:
>> Mikhail,
>> 
>> 
>> Check this build, please [1]
>> 
>> This configuration by default is run agains `master` branch of Apache 
>> Ignite, but can be overridden in params with any branch you like, including 
>> PRs in apache/ignite repository.
>> This is done for ability to test new features in extensions against 
>> non-published changes in main project.
>> 
>> 
>> 
>> [1] 
>> https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_SpringTransactions/5857868
>> 
>> 
>> 
>>> On 5 Feb 2021, at 12:51, Mikhail Petrov  wrote:
>>> 
>>> Hi, Petr.
>>> 
>>> PR with new extension - https://github.com/apache/ignite-extensions/pull/33
>>> 
>>> On 05.02.2021 12:35, Petr Ivanov wrote:
>>>> Hi, Mikhail.
>>>> 
>>>> Is there a PR with you extension, so I can test TC build configuration?
>>>> 
>>>> 
>>>>> On 28 Jan 2021, at 19:03, Petr Ivanov  wrote:
>>>>> 
>>>>> It seems that we need full set of tests for extensions.
>>>>> 
>>>>> I will refactor that project in couple of days and add suite for your 
>>>>> extension too.
>>>>> 
>>>>> 
>>>>>> On 28 Jan 2021, at 16:34, Mikhail Petrov  wrote:
>>>>>> 
>>>>>> Petr, I planned to copy the existing ignite-extensions build 
>>>>>> configuration and change its parameters [1] to add a new module and 
>>>>>> test-suite.
>>>>>> 
>>>>>> It turned out that build configuration parameters can be overridden for 
>>>>>> each particular build without additional permissions or copying 
>>>>>> something.
>>>>>> 
>>>>>> Sorry for bothering you.
>>>>>> 
>>>>>> On 28.01.2021 16:17, Petr Ivanov wrote:
>>>>>>> Hi, Mikhail.
>>>>>>> 
>>>>>>> 
>>>>>>> Can you please describe what exactly do you what to achieve with the 
>>>>>>> build — I will help with it.
>>>>>>> 
>>>>>>> Seems that currently we have no test suites for extensions at all [1]
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> https://ci.ignite.apache.org/project/IgniteExtensions_Tests?mode=builds
>>>>>>> 
>>>>>>>> On 28 Jan 2021, at 15:34, Mikhail Petrov  wrote:
>>>>>>>> 
>>>>>>>> Igniters,
>>>>>>>> 
>>>>>>>> I am currently working on the migration of the Spring Transactions 
>>>>>>>> integration to a separate ignite-extensions module - [1]. I need to 
>>>>>>>> create a debug ignite-extensions build on TC with the migrated test 
>>>>>>>> suite included, making sure the new tests are ok. Can anyone help me 
>>>>>>>> get the required TC permissions while I work on this issue?
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Mikhail.
>>>>>>>> 
>>>>>>>> [1] - https://issues.apache.org/jira/browse/IGNITE-13992
>>>>>>>> 

Re: Request of TC permissions

[Petr Ivanov]

Mikhail,


Check this build, please [1]

This configuration by default is run agains `master` branch of Apache Ignite, 
but can be overridden in params with any branch you like, including PRs in 
apache/ignite repository.
This is done for ability to test new features in extensions against 
non-published changes in main project.



[1] 
https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_SpringTransactions/5857868



> On 5 Feb 2021, at 12:51, Mikhail Petrov  wrote:
> 
> Hi, Petr.
> 
> PR with new extension - https://github.com/apache/ignite-extensions/pull/33
> 
> On 05.02.2021 12:35, Petr Ivanov wrote:
>> Hi, Mikhail.
>> 
>> Is there a PR with you extension, so I can test TC build configuration?
>> 
>> 
>>> On 28 Jan 2021, at 19:03, Petr Ivanov  wrote:
>>> 
>>> It seems that we need full set of tests for extensions.
>>> 
>>> I will refactor that project in couple of days and add suite for your 
>>> extension too.
>>> 
>>> 
>>>> On 28 Jan 2021, at 16:34, Mikhail Petrov  wrote:
>>>> 
>>>> Petr, I planned to copy the existing ignite-extensions build configuration 
>>>> and change its parameters [1] to add a new module and test-suite.
>>>> 
>>>> It turned out that build configuration parameters can be overridden for 
>>>> each particular build without additional permissions or copying something.
>>>> 
>>>> Sorry for bothering you.
>>>> 
>>>> On 28.01.2021 16:17, Petr Ivanov wrote:
>>>>> Hi, Mikhail.
>>>>> 
>>>>> 
>>>>> Can you please describe what exactly do you what to achieve with the 
>>>>> build — I will help with it.
>>>>> 
>>>>> Seems that currently we have no test suites for extensions at all [1]
>>>>> 
>>>>> 
>>>>> 
>>>>> https://ci.ignite.apache.org/project/IgniteExtensions_Tests?mode=builds
>>>>> 
>>>>>> On 28 Jan 2021, at 15:34, Mikhail Petrov  wrote:
>>>>>> 
>>>>>> Igniters,
>>>>>> 
>>>>>> I am currently working on the migration of the Spring Transactions 
>>>>>> integration to a separate ignite-extensions module - [1]. I need to 
>>>>>> create a debug ignite-extensions build on TC with the migrated test 
>>>>>> suite included, making sure the new tests are ok. Can anyone help me get 
>>>>>> the required TC permissions while I work on this issue?
>>>>>> 
>>>>>> Regards,
>>>>>> Mikhail.
>>>>>> 
>>>>>> [1] - https://issues.apache.org/jira/browse/IGNITE-13992
>>>>>> 

Re: Request of TC permissions

[Petr Ivanov]

Hi, Mikhail.

Is there a PR with you extension, so I can test TC build configuration?


> On 28 Jan 2021, at 19:03, Petr Ivanov  wrote:
> 
> It seems that we need full set of tests for extensions.
> 
> I will refactor that project in couple of days and add suite for your 
> extension too.
> 
> 
>> On 28 Jan 2021, at 16:34, Mikhail Petrov  wrote:
>> 
>> Petr, I planned to copy the existing ignite-extensions build configuration 
>> and change its parameters [1] to add a new module and test-suite.
>> 
>> It turned out that build configuration parameters can be overridden for each 
>> particular build without additional permissions or copying something.
>> 
>> Sorry for bothering you.
>> 
>> On 28.01.2021 16:17, Petr Ivanov wrote:
>>> Hi, Mikhail.
>>> 
>>> 
>>> Can you please describe what exactly do you what to achieve with the build 
>>> — I will help with it.
>>> 
>>> Seems that currently we have no test suites for extensions at all [1]
>>> 
>>> 
>>> 
>>> https://ci.ignite.apache.org/project/IgniteExtensions_Tests?mode=builds
>>> 
>>>> On 28 Jan 2021, at 15:34, Mikhail Petrov  wrote:
>>>> 
>>>> Igniters,
>>>> 
>>>> I am currently working on the migration of the Spring Transactions 
>>>> integration to a separate ignite-extensions module - [1]. I need to create 
>>>> a debug ignite-extensions build on TC with the migrated test suite 
>>>> included, making sure the new tests are ok. Can anyone help me get the 
>>>> required TC permissions while I work on this issue?
>>>> 
>>>> Regards,
>>>> Mikhail.
>>>> 
>>>> [1] - https://issues.apache.org/jira/browse/IGNITE-13992
>>>> 
> 

Re: Request of TC permissions

[Petr Ivanov]

It seems that we need full set of tests for extensions.

I will refactor that project in couple of days and add suite for your extension 
too.


> On 28 Jan 2021, at 16:34, Mikhail Petrov  wrote:
> 
> Petr, I planned to copy the existing ignite-extensions build configuration 
> and change its parameters [1] to add a new module and test-suite.
> 
> It turned out that build configuration parameters can be overridden for each 
> particular build without additional permissions or copying something.
> 
> Sorry for bothering you.
> 
> On 28.01.2021 16:17, Petr Ivanov wrote:
>> Hi, Mikhail.
>> 
>> 
>> Can you please describe what exactly do you what to achieve with the build — 
>> I will help with it.
>> 
>> Seems that currently we have no test suites for extensions at all [1]
>> 
>> 
>> 
>> https://ci.ignite.apache.org/project/IgniteExtensions_Tests?mode=builds
>> 
>>> On 28 Jan 2021, at 15:34, Mikhail Petrov  wrote:
>>> 
>>> Igniters,
>>> 
>>> I am currently working on the migration of the Spring Transactions 
>>> integration to a separate ignite-extensions module - [1]. I need to create 
>>> a debug ignite-extensions build on TC with the migrated test suite 
>>> included, making sure the new tests are ok. Can anyone help me get the 
>>> required TC permissions while I work on this issue?
>>> 
>>> Regards,
>>> Mikhail.
>>> 
>>> [1] - https://issues.apache.org/jira/browse/IGNITE-13992
>>>