[MTCGA]: new failures in builds [5986142] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *New test failure in master-nightly WalRecoveryWithPageCompressionAndTdeTest.testWalBigObjectNodeCancel https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3831614200248116444=%3Cdefault%3E=testDetails Changes may lead to failure were done by - mikhail petrov <32207922+ololo3...@users.noreply.github.com> https://ci.ignite.apache.org/viewModification.html?modId=924185 - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 22:55:19 29-04-2021
Re: Stop sending IGNITE Created e-mails to dev@
Hello! Pavel, Yurii, I have added you both to the role. Regards, -- Ilya Kasnacheev чт, 29 апр. 2021 г. в 15:36, Юрий : > Hi, > Ilya, could you please add me to "Contributors 1" too? > > пн, 26 апр. 2021 г. в 12:29, Ilya Kasnacheev : > > > Hello! > > > > I have added you to "Contributors 1" role. Everybody in this role will > > still get those "issue created" e-mail. > > > > Feel free in asking me to enlist. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > чт, 22 апр. 2021 г. в 18:16, Ivan Pavlukhin : > > > > > > All issues notifications are also sent to iss...@ignite.apache.org > so > > > one can subscribe to this list in order to track the created tickets. > > > > > > Does not sound as useful advice. Issues list [1] looks like real > > > scrapyard, I doubt that it can be usable for anyone in current flavor. > > > Can we send only "Created" notifications there? > > > > > > [1] https://lists.apache.org/list.html?iss...@ignite.apache.org > > > > > > 2021-04-21 18:30 GMT+03:00, Ilya Kasnacheev >: > > > > Hello! > > > > > > > > INFRA ticket created: > > https://issues.apache.org/jira/browse/INFRA-21762 > > > > > > > > I have asked to keep sending the created issue notifications for > > > > "Contributors 1" role, which is empty at present. So if you wish to > > keep > > > > getting those e-mails, please add yourself to this role or tell me to > > do > > > so > > > > for you. > > > > > > > > Regards, > > > > -- > > > > Ilya Kasnacheev > > > > > > > > > > > > ср, 21 апр. 2021 г. в 17:59, Alexey Goncharuk < > > > alexey.goncha...@gmail.com>: > > > > > > > >> I support the idea. All issues notifications are also sent to > > > >> iss...@ignite.apache.org so one can subscribe to this list in order > > to > > > >> track the created tickets. The notifications trash the devlist > archive > > > UI > > > >> and make it extremely difficult to navigate. > > > >> > > > >> вт, 20 апр. 2021 г. в 18:35, Ilya Kasnacheev < > > ilya.kasnach...@gmail.com > > > >: > > > >> > > > >> > Hello, Maxim! > > > >> > > > > >> > You are free to revert any commit which has led to any new stable > > test > > > >> > failure, or new flaky test that was non-flaky before. > > > >> > > > > >> > Just revert the change and reopen the ticket. > > > >> > > > > >> > The problem here is that it's very hard to detect on the spot, > most > > of > > > >> > MTCGA e-mails are false positives and even if they are not, it is > > not > > > >> > relevant for most of developers. > > > >> > > > > >> > WDYT? I'm also still waiting for more input. > > > >> > > > > >> > Regards, > > > >> > -- > > > >> > Ilya Kasnacheev > > > >> > > > > >> > > > > >> > ср, 14 апр. 2021 г. в 21:26, Maxim Muzafarov : > > > >> > > > > >> > > +1 for new JIRA issues > > > >> > > -1 for MTCGA notifications > > > >> > > > > > >> > > Why we should hide errors from the dev-list? Who should take > care > > of > > > >> > > issues reported by MTCGA.Bot in this case? > > > >> > > We must apply stricter rules for such issues: a commit leading > to > > an > > > >> > > error must be reverted. > > > >> > > > > > >> > > On Wed, 14 Apr 2021 at 20:00, Denis Mekhanikov > > > >> > > > > > >> > > wrote: > > > >> > > > > > > >> > > > Huge +1 to this. > > > >> > > > > > > >> > > > I've already brought up this topic in the past: > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Bots-on-dev-list-td34406.html > > > >> > > > I hope some day newcomers won't need to set up their email > > filters > > > >> when > > > >> > > > they come to the developers list. > > > >> > > > > > > >> > > > Denis > > > >> > > > > > > >> > > > ср, 14 апр. 2021 г. в 18:07, Atri Sharma : > > > >> > > > > > > >> > > > > +1 to move issues to the issues list. > > > >> > > > > > > > >> > > > > For MTCGA, maybe build@? > > > >> > > > > > > > >> > > > > On Wed, Apr 14, 2021 at 8:35 PM Ilya Kasnacheev > > > >> > > > > > > > >> > > wrote: > > > >> > > > > > > > > >> > > > > > Hello! > > > >> > > > > > > > > >> > > > > > We have a discussion on how to ensure best engagement in > > dev@ > > > >> > list, > > > >> > > and > > > >> > > > > it > > > >> > > > > > seems that Issue Created emails from IGNITE project > consume > > a > > > >> > > > > > lot > > > >> > of > > > >> > > > > screen > > > >> > > > > > space, it's hard to spot genuine discussions in > > > >> > > > > > https://lists.apache.org/list.html?dev@ignite.apache.org > > for > > > >> > > example. > > > >> > > > > > > > > >> > > > > > We already have issues@ mailing list. I propose that we > > stop > > > >> > > sending any > > > >> > > > > > JIRA emails to dev@. If anyone wishes to get just Created > > > >> emails, > > > >> > > they > > > >> > > > > can > > > >> > > > > > subscribe to these messages in their JIRA account > settings. > > I > > > >> > imagine > > > >> > > > > most > > > >> > > > > > of you already filter these messages out, so you may need > to > > > >> adjust > > > >> > > your > > > >> > > > > >
Re: IP Filtering in IPFinders
Thank you, Val. Ilya, please let me know if the PR looks ok. On Thu, 29 Apr 2021, 00:19 Valentin Kulichenko, < valentin.kuliche...@gmail.com> wrote: > I'm OK with the design. > > Ilya, please feel free to merge if the implementation and tests look good > to you. > > -Val > > On Wed, Apr 28, 2021 at 1:07 AM Atri Sharma wrote: > > > Hi Ilya and Val, > > > > Thank you for taking a look and providing insights. I have updated the > > PR and raised another iteration. > > > > Val, I have moved the configuration to TcpDiscoverySpi. > > > > Please see and let me know your thoughts and comments. > > > > Regards, > > > > Atri > > > > On Wed, Apr 28, 2021 at 2:11 AM Valentin Kulichenko > > wrote: > > > > > > Hi Atri, > > > > > > I've noticed that you added the property to the IgniteConfiguration, > but > > > it's applied only within the discovery. I feel like something is wrong > > here. > > > > > > If this feature only relates to the discovery, then we should have the > > > configuration property on the TcpDiscoverySpi instead. Otherwise, the > > > filtering should be applied to all network components (although I'm not > > > necessarily sure what that would imply). > > > > > > What do you think? > > > > > > -Val > > > > > > On Tue, Apr 27, 2021 at 2:00 AM Atri Sharma wrote: > > > > > > > Hi Val and Ilya, > > > > > > > > Thank you for taking the time to pursue this issue. > > > > > > > > I have raised a new PR for the discussed approach. Please see and let > > > > me know what you think: > > > > > > > > https://github.com/apache/ignite/pull/9048 > > > > > > > > Regards, > > > > > > > > Atri > > > > > > > > On Thu, Apr 22, 2021 at 3:34 PM Ilya Kasnacheev > > > > wrote: > > > > > > > > > > Hello! > > > > > > > > > > I'm still not fully convinced, but Val's approach sounds rational > to > > me. > > > > > > > > > > Regards, > > > > > -- > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > чт, 22 апр. 2021 г. в 12:45, Atri Sharma : > > > > > > > > > > > Hello! > > > > > > > > > > > > I actually saw the shared container scenario being tried by > > somebody > > > > > > who wanted an external script to monitor all IPs being used by > his > > > > > > clusters and hence thought of this idea. Another thing that came > in > > > > > > was the Firewall blocking a few IP addresses, hence the idea. > > > > > > > > > > > > I feel that the footprint of this change is small, and can be > > useful > > > > > > for esoteric use cases too without really interfering in any > > existing > > > > > > code path. Val's suggestion seems the right way to go since it > > gives > > > > > > the functionality without much change. > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > On Thu, Apr 22, 2021 at 2:47 PM Ilya Kasnacheev > > > > > > wrote: > > > > > > > > > > > > > > Hello! > > > > > > > > > > > > > > AFAIK, a S3 container, Azure blob container, etc, is a > relatively > > > > > > > lightweight entity, similar to a table in an SQL database. Why > > would > > > > > > > different clusters need to share the same discovery storage > > > > container? > > > > > > > When I tested Azure IP finder, it created several blob > containers > > > > for me > > > > > > on > > > > > > > demand, based on the parameter passed to IP finder. If I wanted > > to > > > > have > > > > > > > more than one cluster it should have been seamless already. > > > > > > > > > > > > > > I can theoretically see how address filtering may be useful to > > remove > > > > > > > public / private addresses or Docker gateway address, but it is > > > > usually > > > > > > > handled by setting localHost setting, although requiring tuning > > it > > > > for > > > > > > each > > > > > > > instance individually. Overall benefit seems to small. > > > > > > > > > > > > > > This is why I am asking, do you have any specific scenario in > > mind > > > > where > > > > > > > this feature is an enabler? How did you arrive at the > conclusion > > to > > > > go > > > > > > > forward with it? > > > > > > > > > > > > > > Regards, > > > > > > > -- > > > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > > > > > > > чт, 22 апр. 2021 г. в 07:51, Atri Sharma : > > > > > > > > > > > > > > > Hi Val, > > > > > > > > > > > > > > > > Consider a scenario where multiple Ignite clusters are > running > > and > > > > for > > > > > > > > operational ease (and also compliance, in some cases, e.g. to > > make > > > > > > > > auditing easier), people can configure cloud based IP finders > > to > > > > share > > > > > > > > the same container (blob container in Azure, S3 container in > > AWS > > > > etc). > > > > > > > > > > > > > > > > In such a case, IPs for all clusters will be in the same > > container. > > > > > > > > IPFinders of both the clusters will read the entire list. In > > this > > > > > > > > case, address filtering will help ignore the irrelevant IP > > > > addresses. > > > > > > > > > > > > > > > > Thank you for pointing me to the alternate direction. Let me > > > > research > > > > > >
[CANCEL] [VOTE] Release Apache Ignite performance-statistics-ext and spring-data-all-ext extensions 1.0.0 RC2
Folks, Canceling due to missing source packages of Spring data extensions. I'll prepare a new vote soon. -- Best wishes, Amelchev Nikita
Re: [VOTE][EXTENSION] Release Apache Ignite performance-statistics-ext and spring-data-all-ext extensions 1.0.0 RC2
Igniters, I have found that the ASF release policy [1] says that each released package must contain sources. The RC2 does not contain sources for Spring extensions and will be canceled. Sources for each extension module will be published to SVN. Also, I will create separate voting threads for the performance statistics and spring extensions. [1] https://www.apache.org/legal/release-policy.html#source-packages ср, 28 апр. 2021 г. в 23:54, Nikita Safonov : > > Hi Denis, > > Thanks for the info! > We've taken this into consideration. > > Regards, > Nikita > > ср, 28 апр. 2021 г. в 17:22, Denis Magda : > > > Folks, just want to confirm that the docs will be updated in a way showing > > the proper/new Maven libs. Is this taken into consideration? CC-ing @Nikita > > Safonov and @Igor Gusev > > - > > Denis > > > > > > On Mon, Apr 26, 2021 at 3:07 PM Nikita Amelchev > > wrote: > > > >> 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 > >> > >> The release candidate of the performance-statistics-ext extension: > >> > >> https://dist.apache.org/repos/dist/dev/ignite/ignite-performance-statistics-ext/1.0.0-rc2/ > >> > >> The following staging can be used for testing: > >> https://repository.apache.org/content/repositories/orgapacheignite-1513 > >> > >> Tags were created: > >> > >> ignite-performance-statistics-ext-1.0.0-rc2 > >> > >> https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=commit;h=26fedfad954852a59f15bbd8f5b65708901f8cfe > >> > >> ignite-spring-data-ext-1.0.0-rc2 > >> ignite-spring-data-2.2-ext-1.0.0-rc2 > >> ignite-spring-data-2.0-ext-1.0.0-rc2 > >> ignite-spring-data-commons-1.0.0-rc2 > >> ignite-spring-data-all-ext-1.0.0-rc2 > >> > >> https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=commit;h=471d7f388c7ad38fc651523f3d68f271235226bd > >> > >> 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-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 and > >> spring-data-all-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 and spring-data-all-ext extensions > >> 1.0.0-rc1 (explain why) > >> > >> The vote will hold for 3 days and will end on April 29 2021 20:00 UTC > >> > >> https://www.timeanddate.com/countdown/generic?iso=20210429T20=1440=cursive > >> > >> -- > >> Best wishes, > >> Amelchev Nikita > >> > > > > -- > *Nikita Safonov* > Technical Writer, > Saint Petersburg > +79112988496 > https://www.gridgain.com > Powered by Apache® Ignite™ -- Best wishes, Amelchev Nikita
Re: Stop sending IGNITE Created e-mails to dev@
Hi, Ilya, could you please add me to "Contributors 1" too? пн, 26 апр. 2021 г. в 12:29, Ilya Kasnacheev : > Hello! > > I have added you to "Contributors 1" role. Everybody in this role will > still get those "issue created" e-mail. > > Feel free in asking me to enlist. > > Regards, > -- > Ilya Kasnacheev > > > чт, 22 апр. 2021 г. в 18:16, Ivan Pavlukhin : > > > > All issues notifications are also sent to iss...@ignite.apache.org so > > one can subscribe to this list in order to track the created tickets. > > > > Does not sound as useful advice. Issues list [1] looks like real > > scrapyard, I doubt that it can be usable for anyone in current flavor. > > Can we send only "Created" notifications there? > > > > [1] https://lists.apache.org/list.html?iss...@ignite.apache.org > > > > 2021-04-21 18:30 GMT+03:00, Ilya Kasnacheev : > > > Hello! > > > > > > INFRA ticket created: > https://issues.apache.org/jira/browse/INFRA-21762 > > > > > > I have asked to keep sending the created issue notifications for > > > "Contributors 1" role, which is empty at present. So if you wish to > keep > > > getting those e-mails, please add yourself to this role or tell me to > do > > so > > > for you. > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > ср, 21 апр. 2021 г. в 17:59, Alexey Goncharuk < > > alexey.goncha...@gmail.com>: > > > > > >> I support the idea. All issues notifications are also sent to > > >> iss...@ignite.apache.org so one can subscribe to this list in order > to > > >> track the created tickets. The notifications trash the devlist archive > > UI > > >> and make it extremely difficult to navigate. > > >> > > >> вт, 20 апр. 2021 г. в 18:35, Ilya Kasnacheev < > ilya.kasnach...@gmail.com > > >: > > >> > > >> > Hello, Maxim! > > >> > > > >> > You are free to revert any commit which has led to any new stable > test > > >> > failure, or new flaky test that was non-flaky before. > > >> > > > >> > Just revert the change and reopen the ticket. > > >> > > > >> > The problem here is that it's very hard to detect on the spot, most > of > > >> > MTCGA e-mails are false positives and even if they are not, it is > not > > >> > relevant for most of developers. > > >> > > > >> > WDYT? I'm also still waiting for more input. > > >> > > > >> > Regards, > > >> > -- > > >> > Ilya Kasnacheev > > >> > > > >> > > > >> > ср, 14 апр. 2021 г. в 21:26, Maxim Muzafarov : > > >> > > > >> > > +1 for new JIRA issues > > >> > > -1 for MTCGA notifications > > >> > > > > >> > > Why we should hide errors from the dev-list? Who should take care > of > > >> > > issues reported by MTCGA.Bot in this case? > > >> > > We must apply stricter rules for such issues: a commit leading to > an > > >> > > error must be reverted. > > >> > > > > >> > > On Wed, 14 Apr 2021 at 20:00, Denis Mekhanikov > > >> > > > > >> > > wrote: > > >> > > > > > >> > > > Huge +1 to this. > > >> > > > > > >> > > > I've already brought up this topic in the past: > > >> > > > > > >> > > > > >> > > > >> > > > http://apache-ignite-developers.2346864.n4.nabble.com/Bots-on-dev-list-td34406.html > > >> > > > I hope some day newcomers won't need to set up their email > filters > > >> when > > >> > > > they come to the developers list. > > >> > > > > > >> > > > Denis > > >> > > > > > >> > > > ср, 14 апр. 2021 г. в 18:07, Atri Sharma : > > >> > > > > > >> > > > > +1 to move issues to the issues list. > > >> > > > > > > >> > > > > For MTCGA, maybe build@? > > >> > > > > > > >> > > > > On Wed, Apr 14, 2021 at 8:35 PM Ilya Kasnacheev > > >> > > > > > > >> > > wrote: > > >> > > > > > > > >> > > > > > Hello! > > >> > > > > > > > >> > > > > > We have a discussion on how to ensure best engagement in > dev@ > > >> > list, > > >> > > and > > >> > > > > it > > >> > > > > > seems that Issue Created emails from IGNITE project consume > a > > >> > > > > > lot > > >> > of > > >> > > > > screen > > >> > > > > > space, it's hard to spot genuine discussions in > > >> > > > > > https://lists.apache.org/list.html?dev@ignite.apache.org > for > > >> > > example. > > >> > > > > > > > >> > > > > > We already have issues@ mailing list. I propose that we > stop > > >> > > sending any > > >> > > > > > JIRA emails to dev@. If anyone wishes to get just Created > > >> emails, > > >> > > they > > >> > > > > can > > >> > > > > > subscribe to these messages in their JIRA account settings. > I > > >> > imagine > > >> > > > > most > > >> > > > > > of you already filter these messages out, so you may need to > > >> adjust > > >> > > your > > >> > > > > > filters slightly. > > >> > > > > > > > >> > > > > > A distant second is MTCGA messages, which are also > > >> > > > > > autogenerated > > >> > and > > >> > > not > > >> > > > > > informative for most readers of the channel, since they are > at > > >> best > > >> > > > > > targeted at a single committer and at worst flaky. > > >> > > > > > > > >> > > > > > Where could we move those? What is your opinion here, on > both > > >> > issues? > > >> > > > > >
