Re: Pushing forward IGNITE-6826: Change default DiscoverySpi ipFinder type for examples
Why not use a combination of Multicast and VM finders? This way we do not have to make any sacrifices. D. On Wed, Jul 18, 2018 at 9:38 PM, Vladimir Ozerov wrote: > TcpDiscoveryVmIpFinder can be configured with 127.0.0.1. Example with > remote nodes will work fine on a single machine. Users rarely run examples > on multiple machines. > > чт, 19 июля 2018 г. в 5:30, Dmitriy Setrakyan : > > > I am confused, the TcpDiscoveryVmIpFinder will only discover nodes with > > specified list of IPs. Don't we have examples that require remote nodes > to > > join? > > > > D. > > > > On Wed, Jul 18, 2018 at 7:52 AM, Stanislav Lukyanov < > > stanlukya...@gmail.com> > > wrote: > > > > > > It can seem not important, but saves a minute for everyone. > > > No, it actually does seem important when you think about it :) Thanks > for > > > the suggestion. > > > Let me correct this then. > > > > > > The issue is > > > IGNITE-6826: Change default DiscoverySpi ipFinder type for examples > > > https://issues.apache.org/jira/browse/IGNITE-6826 > > > It is about changing the ipFinders used in the Ignite examples from > > > TcpDiscoveryMulticastIpFinder to TcpDiscoveryVmIpFinder. > > > > > > Thanks, > > > Stan > > > > > > From: Dmitry Pavlov > > > Sent: 18 июля 2018 г. 17:30 > > > To: dev@ignite.apache.org > > > Cc: antkr@gmail.com; somefire...@gmail.com; ptupit...@apache.org > > > Subject: Re: Pushing IGNITE-6826 forward > > > > > > Hi Stanislav, > > > > > > I wish this push will have effect. > > > > > > Just two proposals that will help Igniters to easily jump into such > > emails: > > > 1. Include ticket short description into subject, not only number. > > > 2. Include link to JIRA issue into body so it could be easily clicked > to > > > find out details. > > > It can seem not important, but saves a minute for everyone. > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > ср, 18 июл. 2018 г. в 16:32, Stanislav Lukyanov < > stanlukya...@gmail.com > > >: > > > > > > > Hi Igniters, > > > > > > > > There is a small but annoying issue with examples using > > MulticastIpFinder > > > > by default. > > > > The JIRA is IGNITE-6826. > > > > > > > > AntonK and DmitriiR have suggested PRs to fix this, but PavelT had > some > > > > concerns and the fix stuck as the result. > > > > > > > > Pavel, could you please suggest necessary changes to the PRs so that > > guys > > > > can move forward with integration? > > > > > > > > Thanks, > > > > Stan > > > > > > > > > > > > >
Re: Pushing IGNITE-6826 forward
Why can't we use a combination of both, VM and Multicast IP finders? D. On Thu, Jul 19, 2018 at 8:28 AM, Stanislav Lukyanov wrote: > Yakov, > > First, it doesn’t seem likely that many people would run examples on > several machines. Even if someone would, they’d probably start doing so > after some experimentation with a single host – at the moment when they’re > already adjusted enough to check and edit some configs. > > Second, I don’t think that this use case outweighs the troubles new (and > even experienced) users get because of the multicast. > Even if it helps some users to get started in their first 30 minutes with > Ignite, it will just as well confuse them later and leave a feeling of > unstable product. > > Showing a warning with default settings is confusing – a user didn’t do > anything wrong, and still we smack their hand with a warning. > I believe we should use warnings for erroneous conditions only. > > Thanks, > Stan > > From: Yakov Zhdanov > Sent: 19 июля 2018 г. 16:54 > To: dev@ignite.apache.org > Cc: antkr@gmail.com; somefire...@gmail.com; ptupit...@apache.org > Subject: Re: Pushing IGNITE-6826 forward > > Guys, multicast IP finder gives new user an opportunity to run tests on > several machines with zero config changes. And you want to change this > which is not good in my view. > > Probably, we need to output warning pointing that user can change multicast > group to avoid undesired discovery and isolate several clusters in the same > network. > > --Yakov > > 2018-07-18 17:30 GMT+03:00 Dmitry Pavlov : > > > Hi Stanislav, > > > > I wish this push will have effect. > > > > Just two proposals that will help Igniters to easily jump into such > emails: > > 1. Include ticket short description into subject, not only number. > > 2. Include link to JIRA issue into body so it could be easily clicked to > > find out details. > > It can seem not important, but saves a minute for everyone. > > > > Sincerely, > > Dmitriy Pavlov > > > > ср, 18 июл. 2018 г. в 16:32, Stanislav Lukyanov >: > > > > > Hi Igniters, > > > > > > There is a small but annoying issue with examples using > MulticastIpFinder > > > by default. > > > The JIRA is IGNITE-6826. > > > > > > AntonK and DmitriiR have suggested PRs to fix this, but PavelT had some > > > concerns and the fix stuck as the result. > > > > > > Pavel, could you please suggest necessary changes to the PRs so that > guys > > > can move forward with integration? > > > > > > Thanks, > > > Stan > > > > > > >
[GitHub] ignite pull request #4387: Debug Port Fix
Github user DaveWHarvey closed the pull request at: https://github.com/apache/ignite/pull/4387 ---
[GitHub] ignite pull request #4387: Debug Port Fix
GitHub user DaveWHarvey opened a pull request: https://github.com/apache/ignite/pull/4387 Debug Port Fix You can merge this pull request into a Git repository by running: $ git pull https://github.com/percipiomedia/ignite dharvey-ignite-2.5 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4387.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4387 commit 42bb1e038d2b1c66cbf5ffdf7d28389e5c372811 Author: markusgay <38728546+markusgay@...> Date: 2018-06-07T10:37:41Z Merge pull request #5 from apache/ignite-2.5 Merge latest Apache Ignite 2.5 into Percipiomedia 2.5 branch commit 52441d46ec8df0b6e4de110f1e9907ccfb3143c3 Author: mgay Date: 2018-06-07T13:29:12Z Initial Jobcase docker image commit 1518312875227ae5fad4c4c5b21fd313011246bb Author: markusgay <38728546+markusgay@...> Date: 2018-06-07T13:36:46Z Merge pull request #7 from percipiomedia/mgay-ignite-2.5 Initial Jobcase docker image commit fd6e4760f9d1db551157118666f4d8ae3425e788 Author: mgay Date: 2018-06-07T15:02:03Z Initial Jenkins job definitions commit 19b770a5ecbf125e40fad0f74a81936f5ee01189 Author: markusgay <38728546+markusgay@...> Date: 2018-06-07T15:04:40Z Merge pull request #8 from percipiomedia/mgay-ignite-2.5 Initial Jenkins job definitions commit fad8c05116bb08e3130b3ed0e66a3bbc2cfd3dda Author: mgay Date: 2018-06-08T17:08:20Z Use Oracle JAVA SDK instead Open JDK in docker image commit 439176640415dfaf2b6f9fe2a91bc6dee1e51fcd Author: markusgay <38728546+markusgay@...> Date: 2018-06-09T13:00:39Z Merge pull request #10 from percipiomedia/mgay-ignite-2.5 Use Oracle JAVA SDK instead Open JDK in docker image commit 105587f1fe47fbb07a4891a5aee682f2493193fd Author: Markus Gay Date: 2018-06-19T12:09:03Z Latest AWS SDK version 1.11.349 commit bf8f0e4e435e05e2eeed1cb6ed1dce937e278c59 Author: markusgay <38728546+markusgay@...> Date: 2018-06-19T12:17:53Z Merge pull request #14 from percipiomedia/mgay-ignite-2.5 Latest AWS SDK version 1.11.349 commit 37601508426ef27a939a9ac1e807d330ba2f801f Author: Markus Gay Date: 2018-07-09T16:16:54Z Add vim, ps and nc to image commit f08a631b5d36a8e24990e7fdc67eedb66232a81e Author: markusgay <38728546+markusgay@...> Date: 2018-07-09T16:19:26Z Merge pull request #15 from percipiomedia/mgay-ignite-2.5 Add vim, ps and nc to image commit 8386238223daa2babb81d6b4af359814f831e929 Author: Markus Gay Date: 2018-07-10T17:31:54Z Add support of -Drelease.version=xyz to mvn build commit 05f75f70e7f5a749479de1af2f6c8d3f4008ea8a Author: markusgay <38728546+markusgay@...> Date: 2018-07-10T17:35:51Z Merge pull request #16 from percipiomedia/mgay-ignite-2.5 Add support of -Drelease.version=xyz to mvn build commit b5f3605ac6bbfa8bf854e5ff9be58ea43cf97b54 Author: Markus Gay Date: 2018-07-11T14:39:29Z Enable java assertions in docker image commit 0b9a9c7ec148a303976d57a750e93e8a1a306022 Author: markusgay <38728546+markusgay@...> Date: 2018-07-11T14:42:41Z Merge pull request #17 from percipiomedia/mgay-ignite-2.5 Enable java assertions in docker image commit 4d3fb0df349f914f3f80bc8156b1fe3bad306446 Author: Markus Gay Date: 2018-07-12T13:47:18Z Add logging to AttributeNodeFilter commit 397a35807ec2f8abca8258a1710faab9f8364db9 Author: markusgay <38728546+markusgay@...> Date: 2018-07-12T13:48:55Z Merge pull request #18 from percipiomedia/mgay-ignite-2.5 Add logging to AttributeNodeFilter commit 9fda387e8a7b9202d17f26279472aceb486a1c1d Author: Markus Gay Date: 2018-07-14T14:40:23Z Use deploymentMode CONTINUOUS and JVM debug opts commit 02d72282c34914db95d4e445a47567ae0030892b Author: markusgay <38728546+markusgay@...> Date: 2018-07-14T14:45:03Z Merge pull request #19 from percipiomedia/mgay-ignite-2.5 Use deploymentMode CONTINUOUS and JVM debug opts commit 2db4fd28d7176f0490193652f45c6364f681e5d4 Author: Markus Gay Date: 2018-07-14T15:20:16Z Don't add JVM_DEBUG_OPTS as default to JVM_OPTS commit 3ef6a1ee02956b556452f04eac435585af2ca50a Author: markusgay <38728546+markusgay@...> Date: 2018-07-14T15:23:43Z Merge pull request #20 from percipiomedia/mgay-ignite-2.5 Don't add JVM_DEBUG_OPTS as default to JVM_OPTS commit d9e06fd4cce78a1076a5e7a6a81f23b16696a55a Author: Dave Harvey Date: 2018-07-15T16:58:47Z PER-48: If IGNITE_CONSISTENT_ID is not set, set it to the concatenation of IGNITE_HOST_NAME and the docker host's name, if those are both set. commit eb2c3c8fb4ba79d89123b5d0ff52531ef9bd9caa Author: Dave Harvey Date: 2018-07-16T11:32:34Z Fixed spelling error "PERSISENT", use DefaultAWSCredentialsProviderChain since AWS library is updated commit
Re: Documenting Ignite
I appologize, initially I misundersood proposal. I've concluded that new doc issue will be created automatically by closing original ticket, - this can be done by plugin only. If we just introduce flag or combobox for indicate doc is required, there is no technical issues, it is defenetely possible. So +1 from my side without concerns. чт, 19 июл. 2018 г. в 22:02, Denis Magda : > Ok, if all our doc writers are in the agreement then let's give a couple of > days to our fellow Igniters to share alternate opinions. > > Artem, if you don't hear back by Monday then feel free to create an INFRA > ticket. > > -- > Denis > > On Thu, Jul 19, 2018 at 10:43 AM Prachi Garg wrote: > > > I totally agree with Denis's point - > > > > "Another benefit of having "Docs Required" flag enabled by default, is > that > > Artem and Prachi can see all such tickets months and weeks before a > > release, figure out details from source code contributors and complete > the > > docs in advance." > > > > On Wed, Jul 18, 2018 at 2:49 PM, Dmitry Pavlov > > wrote: > > > >> Yes, I agree. My concern is related only to process implementation > aspect, > >> I wonder if it is technically possible. > >> > >> Generally I like idea of automatic control. > >> > >> ср, 18 июл. 2018 г. в 23:21, Denis Magda : > >> > >> > Hi folks, > >> > > >> > Artem's proposal might simplify and make our doc tickets tracking less > >> > error-prone. The current approach implies that a contributor keeps in > >> mind > >> > what needs to go to the docs. If he/she has a good memory, a doc JIRA > >> > counterpart will be created once the contribution is accepted. But the > >> > practice shows that the memory lets us down :) > >> > > >> > Another benefit of having "Docs Required" flag enabled by default, is > >> that > >> > Artem and Prachi can see all such tickets months and weeks before a > >> > release, figure out details from source code contributors and complete > >> the > >> > docs in advance. > >> > > >> > -- > >> > Denis > >> > > >> > On Wed, Jul 18, 2018 at 8:39 AM Artem Budnikov < > >> > a.budnikov.ign...@gmail.com> wrote: > >> > > >> >> Dmitry, > >> >> > >> >> The goal I had in mind by proposing that suggestion was to rectify > the > >> >> fact that JIRA issues for documentation are created on an ad-hoc > basis, > >> >> and often issues are created when the lack of documentation becomes > an > >> >> issue for somebody. So we need to be more proactive. > >> >> > >> >> I think manual tracking of issues is possible but as efficient as the > >> >> current situation with the docs. Manual tracking will have to be > shared > >> >> between multiple contributors and performed outside of JIRA, which > has > >> >> its own limitation. If you have any suggestions for improvement > without > >> >> creating fields in JIRA, please share your thoughts. > >> >> > >> >> If you are concerned that it's not possible to add a field, then we > >> >> should contact Apache Infra and find out. > >> >> > >> >> > >> >> Best regards, > >> >> > >> >> Artem Budnikov > >> >> > >> >> > >> >> On 18.07.2018 16:14, Dmitry Pavlov wrote: > >> >> > Hi Artem, > >> >> > > >> >> > I sometimes receive feedback that Ignite docs has potential for > >> >> > improvement, while I found our docs quite intuitive and simple to > >> >> > understand. So if experienced tech writer will join community it > >> could > >> >> > benefit all of us, and users, of course. So you're very welcome to > >> the > >> >> > community! > >> >> > > >> >> > About idea of fields introduction I guess we will need assistance > of > >> >> Apache > >> >> > Infra team, because Ignite shares JIRA with all other Apache > project. > >> >> And > >> >> > I'm not sure that technical implementation of proposed process is > >> even > >> >> > possible without plugins. Could we consider some manual processing > of > >> >> > completed issues in relation to doc requrement? > >> >> > > >> >> > Sincerely, > >> >> > Dmitriy Pavlov > >> >> > > >> >> > ср, 18 июл. 2018 г. в 15:06, Artem Budnikov < > >> >> a.budnikov.ign...@gmail.com>: > >> >> > > >> >> >> Hi Igniters, > >> >> >> > >> >> >> Being a technical writer, I'm going to contribute to Ignite's > >> >> >> documentation, and I believe documentation is an important part of > >> >> every > >> >> >> product, especially such a complex product as Apache Ignite. > >> >> >> > >> >> >> I'd like to put forward a suggestion on how to increase our > chances > >> of > >> >> >> making Ignite documentation more comprehensive. The basic idea is > to > >> >> >> have a Jira issue with the Component field set to "Documentation" > >> for > >> >> >> every feature that needs to be documented. This will ensure that > >> there > >> >> >> are documentation issues that cover the entire product > >> functionality. > >> >> >> Then someone can take on an issue and contribute an article on the > >> >> subject. > >> >> >> > >> >> >> This is how I envision it to work technically. A new field > >> (checkbox) > >> >> is > >> >>
Re: Documenting Ignite
Ok, if all our doc writers are in the agreement then let's give a couple of days to our fellow Igniters to share alternate opinions. Artem, if you don't hear back by Monday then feel free to create an INFRA ticket. -- Denis On Thu, Jul 19, 2018 at 10:43 AM Prachi Garg wrote: > I totally agree with Denis's point - > > "Another benefit of having "Docs Required" flag enabled by default, is that > Artem and Prachi can see all such tickets months and weeks before a > release, figure out details from source code contributors and complete the > docs in advance." > > On Wed, Jul 18, 2018 at 2:49 PM, Dmitry Pavlov > wrote: > >> Yes, I agree. My concern is related only to process implementation aspect, >> I wonder if it is technically possible. >> >> Generally I like idea of automatic control. >> >> ср, 18 июл. 2018 г. в 23:21, Denis Magda : >> >> > Hi folks, >> > >> > Artem's proposal might simplify and make our doc tickets tracking less >> > error-prone. The current approach implies that a contributor keeps in >> mind >> > what needs to go to the docs. If he/she has a good memory, a doc JIRA >> > counterpart will be created once the contribution is accepted. But the >> > practice shows that the memory lets us down :) >> > >> > Another benefit of having "Docs Required" flag enabled by default, is >> that >> > Artem and Prachi can see all such tickets months and weeks before a >> > release, figure out details from source code contributors and complete >> the >> > docs in advance. >> > >> > -- >> > Denis >> > >> > On Wed, Jul 18, 2018 at 8:39 AM Artem Budnikov < >> > a.budnikov.ign...@gmail.com> wrote: >> > >> >> Dmitry, >> >> >> >> The goal I had in mind by proposing that suggestion was to rectify the >> >> fact that JIRA issues for documentation are created on an ad-hoc basis, >> >> and often issues are created when the lack of documentation becomes an >> >> issue for somebody. So we need to be more proactive. >> >> >> >> I think manual tracking of issues is possible but as efficient as the >> >> current situation with the docs. Manual tracking will have to be shared >> >> between multiple contributors and performed outside of JIRA, which has >> >> its own limitation. If you have any suggestions for improvement without >> >> creating fields in JIRA, please share your thoughts. >> >> >> >> If you are concerned that it's not possible to add a field, then we >> >> should contact Apache Infra and find out. >> >> >> >> >> >> Best regards, >> >> >> >> Artem Budnikov >> >> >> >> >> >> On 18.07.2018 16:14, Dmitry Pavlov wrote: >> >> > Hi Artem, >> >> > >> >> > I sometimes receive feedback that Ignite docs has potential for >> >> > improvement, while I found our docs quite intuitive and simple to >> >> > understand. So if experienced tech writer will join community it >> could >> >> > benefit all of us, and users, of course. So you're very welcome to >> the >> >> > community! >> >> > >> >> > About idea of fields introduction I guess we will need assistance of >> >> Apache >> >> > Infra team, because Ignite shares JIRA with all other Apache project. >> >> And >> >> > I'm not sure that technical implementation of proposed process is >> even >> >> > possible without plugins. Could we consider some manual processing of >> >> > completed issues in relation to doc requrement? >> >> > >> >> > Sincerely, >> >> > Dmitriy Pavlov >> >> > >> >> > ср, 18 июл. 2018 г. в 15:06, Artem Budnikov < >> >> a.budnikov.ign...@gmail.com>: >> >> > >> >> >> Hi Igniters, >> >> >> >> >> >> Being a technical writer, I'm going to contribute to Ignite's >> >> >> documentation, and I believe documentation is an important part of >> >> every >> >> >> product, especially such a complex product as Apache Ignite. >> >> >> >> >> >> I'd like to put forward a suggestion on how to increase our chances >> of >> >> >> making Ignite documentation more comprehensive. The basic idea is to >> >> >> have a Jira issue with the Component field set to "Documentation" >> for >> >> >> every feature that needs to be documented. This will ensure that >> there >> >> >> are documentation issues that cover the entire product >> functionality. >> >> >> Then someone can take on an issue and contribute an article on the >> >> subject. >> >> >> >> >> >> This is how I envision it to work technically. A new field >> (checkbox) >> >> is >> >> >> added to the Apache Ignite Jira project. The checkbox indicates that >> >> the >> >> >> feature requested in this issue needs to be documented. The >> checkbox is >> >> >> selected by default. If the feature does not require documentation, >> >> then >> >> >> the author unchecks the checkbox. If it does require documentation, >> the >> >> >> author creates a related Jira issue selecting "Documentation" in the >> >> >> Component field, providing details on what exactly should be >> >> documented. >> >> >> >> >> >> The field is called "Requires documentation" or similarly. It could >> be >> >> >> also useful to create a new issue type for
Re: [ML] Machine Learning Pipeline Improvement
Hi Alexey, I can't name myself an ML expert but heard that our ML component is missing some essential data preprocessing APIs. Are these pipelines part of our intention to bring in the preprocessing APIs to Ignite? -- Denis On Thu, Jul 19, 2018 at 5:29 AM Alexey Zinoviev wrote: > Hi Igniters, > > I suggest to add and implement by myself sequential pipeline of machine > learning operations including all preprocessing stages like Pipeline object > in Python library scikit-learn (look here > > http://scikit-learn.org/stable/modules/generated/sklearn.pipeline.Pipeline.html > for the details) > > It can be combined with current Cross-Validator and Evaluator objects. > > The possible solution will sequentially apply a list of transforms and a > final estimator. > > Alexey >
[jira] [Created] (IGNITE-9036) Update FasterXML jackson-databind dependency version in Apache Ignite
Dmitriy Pavlov created IGNITE-9036: -- Summary: Update FasterXML jackson-databind dependency version in Apache Ignite Key: IGNITE-9036 URL: https://issues.apache.org/jira/browse/IGNITE-9036 Project: Ignite Issue Type: Improvement Reporter: Dmitriy Pavlov Actual: jackson2.version in ignite parent pom is 2.6.5, required 2.9.5 or later, Latest version is 2.9.6 affected modules will be at least ignite-aws. It is required to run RunAll to check all tests passed, check full build locally using build.sh. Probably it is required to run release step to make sure release candidate can be prepared. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9035) Update log4j 2x version in Apache Ignite
Dmitriy Pavlov created IGNITE-9035: -- Summary: Update log4j 2x version in Apache Ignite Key: IGNITE-9035 URL: https://issues.apache.org/jira/browse/IGNITE-9035 Project: Ignite Issue Type: Test Reporter: Dmitriy Pavlov Fix For: 2.7 It is suggested to update log4j 2x version to log4j 2.8.2 or later. org.apache.logging.log4j log4j 2.8.2 pom It is required to run RunAll to check all tests passed. Probably it is required to run release step to make sure release candidate can be prepared. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Documenting Ignite
I totally agree with Denis's point - "Another benefit of having "Docs Required" flag enabled by default, is that Artem and Prachi can see all such tickets months and weeks before a release, figure out details from source code contributors and complete the docs in advance." On Wed, Jul 18, 2018 at 2:49 PM, Dmitry Pavlov wrote: > Yes, I agree. My concern is related only to process implementation aspect, > I wonder if it is technically possible. > > Generally I like idea of automatic control. > > ср, 18 июл. 2018 г. в 23:21, Denis Magda : > > > Hi folks, > > > > Artem's proposal might simplify and make our doc tickets tracking less > > error-prone. The current approach implies that a contributor keeps in > mind > > what needs to go to the docs. If he/she has a good memory, a doc JIRA > > counterpart will be created once the contribution is accepted. But the > > practice shows that the memory lets us down :) > > > > Another benefit of having "Docs Required" flag enabled by default, is > that > > Artem and Prachi can see all such tickets months and weeks before a > > release, figure out details from source code contributors and complete > the > > docs in advance. > > > > -- > > Denis > > > > On Wed, Jul 18, 2018 at 8:39 AM Artem Budnikov < > > a.budnikov.ign...@gmail.com> wrote: > > > >> Dmitry, > >> > >> The goal I had in mind by proposing that suggestion was to rectify the > >> fact that JIRA issues for documentation are created on an ad-hoc basis, > >> and often issues are created when the lack of documentation becomes an > >> issue for somebody. So we need to be more proactive. > >> > >> I think manual tracking of issues is possible but as efficient as the > >> current situation with the docs. Manual tracking will have to be shared > >> between multiple contributors and performed outside of JIRA, which has > >> its own limitation. If you have any suggestions for improvement without > >> creating fields in JIRA, please share your thoughts. > >> > >> If you are concerned that it's not possible to add a field, then we > >> should contact Apache Infra and find out. > >> > >> > >> Best regards, > >> > >> Artem Budnikov > >> > >> > >> On 18.07.2018 16:14, Dmitry Pavlov wrote: > >> > Hi Artem, > >> > > >> > I sometimes receive feedback that Ignite docs has potential for > >> > improvement, while I found our docs quite intuitive and simple to > >> > understand. So if experienced tech writer will join community it could > >> > benefit all of us, and users, of course. So you're very welcome to the > >> > community! > >> > > >> > About idea of fields introduction I guess we will need assistance of > >> Apache > >> > Infra team, because Ignite shares JIRA with all other Apache project. > >> And > >> > I'm not sure that technical implementation of proposed process is even > >> > possible without plugins. Could we consider some manual processing of > >> > completed issues in relation to doc requrement? > >> > > >> > Sincerely, > >> > Dmitriy Pavlov > >> > > >> > ср, 18 июл. 2018 г. в 15:06, Artem Budnikov < > >> a.budnikov.ign...@gmail.com>: > >> > > >> >> Hi Igniters, > >> >> > >> >> Being a technical writer, I'm going to contribute to Ignite's > >> >> documentation, and I believe documentation is an important part of > >> every > >> >> product, especially such a complex product as Apache Ignite. > >> >> > >> >> I'd like to put forward a suggestion on how to increase our chances > of > >> >> making Ignite documentation more comprehensive. The basic idea is to > >> >> have a Jira issue with the Component field set to "Documentation" for > >> >> every feature that needs to be documented. This will ensure that > there > >> >> are documentation issues that cover the entire product functionality. > >> >> Then someone can take on an issue and contribute an article on the > >> subject. > >> >> > >> >> This is how I envision it to work technically. A new field (checkbox) > >> is > >> >> added to the Apache Ignite Jira project. The checkbox indicates that > >> the > >> >> feature requested in this issue needs to be documented. The checkbox > is > >> >> selected by default. If the feature does not require documentation, > >> then > >> >> the author unchecks the checkbox. If it does require documentation, > the > >> >> author creates a related Jira issue selecting "Documentation" in the > >> >> Component field, providing details on what exactly should be > >> documented. > >> >> > >> >> The field is called "Requires documentation" or similarly. It could > be > >> >> also useful to create a new issue type for documentation issues > >> >> exclusively. > >> >> > >> >> Once this is done, we'll be able to filter out > >> >> > >> >> 1. issues that do not require documentation, > >> >> 2. issues that have related documentation tickets, and > >> >> 3. issues that require documentation but have no related issues > >> (which > >> >> means that the author forgot to create a documentation issue for > >> it). > >> >> > >> >> >
[CVE-2018-8018] Possible Execution of Arbitrary Code via Apache Ignite GridClientJdkMarshaller
Severity: Important Vendor: The Apache Software Foundation Versions Affected: Apache Ignite 2.5 and earlier Impact: An attacker can execute arbitrary code on Ignite nodes via GridClientJdkMarshaller deserialization endpoint in the case when Ignite classpath contains arbitrary vulnerable classes. Description: Apache Ignite serialization mechanism does not have a list of classes allowed for serialization/deserialization, which makes it possible to run arbitrary code when 3-rd party vulnerable classes are present in Ignite classpath. The vulnerability can be exploited if the one sends a specially prepared form of a serialized object to GridClientJdkMarshaller deserialization endpoint. Mitigation: •All Ignite versions: make sure there are no vulnerable classes among your custom code used in Apache Ignite. •Ignite 2.5 or earlier users: upgrade to Ignite 2.6 and use IGNITE_MARSHALLER_WHITELIST and/or IGNITE_MARSHALLER_BLACKLIST system properties to define classes allowed for deserialization. Refer to this documentation for more details: https://apacheignite.readme.io/docs/securing-data-deserialization Credit: * The vulnerability was discovered by Man Yue Mo of lgtm.com. References: * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8018
[CVE-2018-1273] Apache Ignite impacted by security vulnerability in Spring Data Commons
Severity: Important Vendor: The Apache Software Foundation Versions Affected: * Apache Ignite 1.0.0-RC3 to 2.5 Impact: An unauthenticated remote malicious user (or attacker) can issue requests against Spring Data REST or Spring Data Description: Apache Ignite utilizes Spring Data Common library for some of its components. The vulnerability affects Apache Ignite users who us Spring Data REST for access an Ignite cluster via HTTP and Spring Data. Spring Data Commons, versions prior to 1.13 to 1.13.10, 2.0 to 2.0.5, and older unsupported versions, contain a property binder vulnerability caused by improper neutralization of special elements. An unauthenticated remote malicious user (or attacker) can supply specially crafted request parameters against Spring Data REST backed HTTP resources or using Spring Data's projection-based request payload binding hat can lead to a remote code execution attack. Mitigation: * Upgrade to Apache Ignite 2.6 or later that include Spring Data Commons versions not vulnerable to the disclosed issue. Credit: * Harendra Rai of NCR Corporation discovered the impact of the existing vulnerability on Apache Ignite. References: * https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1273 * https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1274
[GitHub] ignite pull request #4386: IGNITE-8220
GitHub user EdShangGG opened a pull request: https://github.com/apache/ignite/pull/4386 IGNITE-8220 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8220-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4386.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4386 commit fd9e66bfab07ab810e2e25aceeb64ef7c9f62d50 Author: EdShangGG Date: 2018-07-19T15:32:52Z IGNITE-8220 WIP commit a876f48a6da3189332385e37f8cdf0028edd378f Author: EdShangGG Date: 2018-07-19T15:33:16Z IGNITE-8220 ---
[jira] [Created] (IGNITE-9034) [ML] Add Estimator API support to TensorFlow cluster on top of Apache Ignite
Yury Babak created IGNITE-9034: -- Summary: [ML] Add Estimator API support to TensorFlow cluster on top of Apache Ignite Key: IGNITE-9034 URL: https://issues.apache.org/jira/browse/IGNITE-9034 Project: Ignite Issue Type: Improvement Components: ml Reporter: Yury Babak Assignee: Anton Dmitriev Fix For: 2.7 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
RE: Pushing IGNITE-6826 forward
Yakov, First, it doesn’t seem likely that many people would run examples on several machines. Even if someone would, they’d probably start doing so after some experimentation with a single host – at the moment when they’re already adjusted enough to check and edit some configs. Second, I don’t think that this use case outweighs the troubles new (and even experienced) users get because of the multicast. Even if it helps some users to get started in their first 30 minutes with Ignite, it will just as well confuse them later and leave a feeling of unstable product. Showing a warning with default settings is confusing – a user didn’t do anything wrong, and still we smack their hand with a warning. I believe we should use warnings for erroneous conditions only. Thanks, Stan From: Yakov Zhdanov Sent: 19 июля 2018 г. 16:54 To: dev@ignite.apache.org Cc: antkr@gmail.com; somefire...@gmail.com; ptupit...@apache.org Subject: Re: Pushing IGNITE-6826 forward Guys, multicast IP finder gives new user an opportunity to run tests on several machines with zero config changes. And you want to change this which is not good in my view. Probably, we need to output warning pointing that user can change multicast group to avoid undesired discovery and isolate several clusters in the same network. --Yakov 2018-07-18 17:30 GMT+03:00 Dmitry Pavlov : > Hi Stanislav, > > I wish this push will have effect. > > Just two proposals that will help Igniters to easily jump into such emails: > 1. Include ticket short description into subject, not only number. > 2. Include link to JIRA issue into body so it could be easily clicked to > find out details. > It can seem not important, but saves a minute for everyone. > > Sincerely, > Dmitriy Pavlov > > ср, 18 июл. 2018 г. в 16:32, Stanislav Lukyanov : > > > Hi Igniters, > > > > There is a small but annoying issue with examples using MulticastIpFinder > > by default. > > The JIRA is IGNITE-6826. > > > > AntonK and DmitriiR have suggested PRs to fix this, but PavelT had some > > concerns and the fix stuck as the result. > > > > Pavel, could you please suggest necessary changes to the PRs so that guys > > can move forward with integration? > > > > Thanks, > > Stan > > >
[GitHub] ignite pull request #4384: fix 3
Github user dgarus closed the pull request at: https://github.com/apache/ignite/pull/4384 ---
Re: Pushing IGNITE-6826 forward
Guys, multicast IP finder gives new user an opportunity to run tests on several machines with zero config changes. And you want to change this which is not good in my view. Probably, we need to output warning pointing that user can change multicast group to avoid undesired discovery and isolate several clusters in the same network. --Yakov 2018-07-18 17:30 GMT+03:00 Dmitry Pavlov : > Hi Stanislav, > > I wish this push will have effect. > > Just two proposals that will help Igniters to easily jump into such emails: > 1. Include ticket short description into subject, not only number. > 2. Include link to JIRA issue into body so it could be easily clicked to > find out details. > It can seem not important, but saves a minute for everyone. > > Sincerely, > Dmitriy Pavlov > > ср, 18 июл. 2018 г. в 16:32, Stanislav Lukyanov : > > > Hi Igniters, > > > > There is a small but annoying issue with examples using MulticastIpFinder > > by default. > > The JIRA is IGNITE-6826. > > > > AntonK and DmitriiR have suggested PRs to fix this, but PavelT had some > > concerns and the fix stuck as the result. > > > > Pavel, could you please suggest necessary changes to the PRs so that guys > > can move forward with integration? > > > > Thanks, > > Stan > > >
Re: Place Ignite TC helper to ASF Ignite supplementary git repo
Hi Dmitriy Pavlov, MTCGA.Bot seems like useful tool to make analysis and monitoring of our test base so I also support the idea of publishing its source code. When it is adopted by more community members they may come up with ideas of improvements so its sources should be available. Placing it in a separate repo seems reasonable to me but we should provide clear information about new repo and its purpose somewhere on wiki to make it visible to the community. Clear documentation on source code won't hurt as well. -- Thanks, Sergey Chugunov On Thu, Jul 19, 2018 at 1:29 PM Dmitry Pavlov wrote: > Hi Dmitriy, > > Yes, I'm going to create INFRA ticket for new ASF supplementary repository > for project, I just want to be absolutely sure, that Community supports my > plan. > > Or do you mean I need to create ticket to find out if domain > mtcga.ignite.apache.org is possible to create? > > Sincerely, > Dmitriy Pavlov > > чт, 19 июл. 2018 г. в 1:43, Dmitriy Setrakyan : > > > Dmitriy, > > > > I think you should file an INFRA ticket and ask if this is possible. > > > > D. > > > > On Wed, Jul 18, 2018 at 3:12 PM, Denis Magda wrote: > > > > > Dmitriy, > > > > > > Things for clearing the things out. No objections from my side then. > > > > > > Let's see what other Ignite fellows think on your proposal. Someone > might > > > have a different perspective. > > > > > > -- > > > Denis > > > > > > On Wed, Jul 18, 2018 at 1:58 PM Dmitry Pavlov > > > wrote: > > > > > > > Hi Denis, > > > > > > > > It will made things simple. > > > > > > > > 1) For example any comitter will be able to change rules of > > notification > > > > and fix the Bot if something goes wrong. Now it is my github repo. > ASF > > > repo > > > > will guarantee that code will be always accessible by community > > members. > > > > > > > > 2) Being a part of ASF repo the Bot will be simple thing that less > > > > experienced developer can start with. The Bot uses latest AI release > as > > > DB > > > > with persistence enabled, so bot developer became at least Apache > > Ignite > > > > user, and as most - new contributor. > > > > > > > > If we agree to place this bot to ASF, next step could be asking Infra > > > Team > > > > to provide 2nd level apache domain, e.g. mtcga.ignite.apache.org for > > web > > > > UI. I guess it would be plus if our tool code is available in ASF > repo, > > > but > > > > not in some private git repo. > > > > > > > > Sincerely, > > > > Dmitriy Pavlov > > > > > > > > ср, 18 июл. 2018 г. в 23:03, Denis Magda : > > > > > > > > > Hi Dmitriy, > > > > > > > > > > The whole year has passed since this initiative launch, hell, the > > times > > > > > passes by :) > > > > > > > > > > What would be the benefits of having the tool in the Apache repo? > > Does > > > it > > > > > simplify the things for us. > > > > > > > > > > -- > > > > > Denis > > > > > > > > > > On Wed, Jul 18, 2018 at 3:59 AM Dmitry Pavlov < > dpavlov@gmail.com > > > > > > > > wrote: > > > > > > > > > > > Hi Igniters, > > > > > > > > > > > > Almost 1 year has passed since Make Teamcity Green Again was > > > initially > > > > > > proposed. During this process we managed to get almost successful > > Run > > > > > Alls > > > > > > in master, but currently regressions still occur. We all tried a > > lot > > > of > > > > > > things: careful examination of PR tests, continuous monitoring of > > > > master, > > > > > > suite responsible contributor, tickets creation and so on. > > > > > > > > > > > > According to Igniter's feedback most productive thing was master > > > > > monitoring > > > > > > and timely fix of new failures. But contributor’s enthusiasm is > > > limited > > > > > and > > > > > > monitoring is not most enjoyable thing, so it's time to automate > > this > > > > > > activity. I’ve created MTCGA.Bot which sends emails about new > > > failures > > > > > and > > > > > > in addition has a couple of useful features. > > > > > > > > > > > > The Bot is being developed only based on your feedback. 30 Ignite > > > > > > developers already tried it. I'm going to run short > > > > webinar/presentation > > > > > at > > > > > > Mon 23 July and tell more about Bot capabilites, so everyone can > > make > > > > an > > > > > > impression. > > > > > > > > > > > > I would like to continue development and I propose to place TC > > Helper > > > > > code > > > > > > to Apache Ignite supplementary repository (same as > ignite-release). > > > > What > > > > > do > > > > > > you think about it? Please share your vision till 24 July. > > > > > > > > > > > > Sincerely, > > > > > > Dmitriy Pavlov > > > > > > > > > > > > References: > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/ > > > Make+Teamcity+Green+Again#MakeTeamcityGreenAgain-MTCGABot > > > > > > > > > > > > https://github.com/dspavlov/ignite-teamcity-helper > > > > > > > > > > > > > > > > > > > > >
[GitHub] ignite pull request #4071: IGNITE-8495: Implement C++ thin client start and ...
Github user isapego closed the pull request at: https://github.com/apache/ignite/pull/4071 ---
[GitHub] ignite pull request #4349: IGNITE-8922 Fix delivery of pending messages
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4349 ---
Re: Upgrading Ignite to JCache 1.1
Hi, Alex! Could you also help with the ticket [1]? If you have time. [1] https://issues.apache.org/jira/browse/IGNITE-9020 On Tue, Jul 17, 2018 at 4:50 PM Denis Magda wrote: > > Pavel, > > Could you chime in please? > > -- > Denis > > On Tue, Jul 17, 2018 at 6:43 AM Nikita Amelchev > wrote: > > > Hi, Igniters. > > > > I'm implementing new version TCK 1.1 and I found the problem [1] in the > > .NET module. > > > > In brief, .NET creates cache entry event based on values exist checking. > > > > TCK 1.1 says that getValue() not null for REMOVE/EXPIRED events if old > > value required and it breaks logic. > > > > I'm looking for a .net contributor. Anyone ready to help? > > > > 1. https://issues.apache.org/jira/browse/IGNITE-9020 > > > > 2018-06-15 14:35 GMT+03:00 Александр Меньшиков : > > > > > Denis, I think we can include it to a minor release. Because the network > > > protocol, API, binary compatibility will be saved. And all behavior > > > changes, in fact, make implementation closer to the documentation of > > JCache > > > 1.0. Because TCK 1.1.0 in general fixes differents between documentation > > > and tests in 1.0. > > > > > > 2018-06-14 21:41 GMT+03:00 Denis Magda : > > > > > > > Guys, are you targeting this for the next big Ignite release? Should be > > > in > > > > 3 m from now. > > > > > > > > -- > > > > Denis > > > > > > > > On Thu, Jun 14, 2018 at 2:58 AM Anton Vinogradov > > wrote: > > > > > > > > > Corrected IEP URL: > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP- > > > > 21%3A+JCache+1.1+support > > > > > > > > > > чт, 14 июн. 2018 г. в 12:48, Александр Меньшиков < > > sharple...@gmail.com > > > >: > > > > > > > > > > > Igniters, > > > > > > > > > > > > I've prepared IEP-21 [1] for this JCache updating task. > > > > > > It will help us to manage the issues and see the progress in one > > > place. > > > > > > Also, we have finally added tests for TCK 1.1.0 [2] to our TC which > > > can > > > > > be > > > > > > run on any branch. > > > > > > Both tests cases (for 1.0.1 and for 1.1.0) will coexist until > > IEP-21 > > > > > > finish. > > > > > > > > > > > > [1] > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-21:+JCache+1.1 > > > > > > [2] > > > > > > > > > > > > > > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId= > > > > IgniteTests24Java8_JCacheTck11 > > > > > > > > > > > > 2018-06-06 0:49 GMT+03:00 Denis Magda : > > > > > > > > > > > > > Agree, I see zero benefits of being compliant with both > > > specification > > > > > > > versions. Let’s just focus on the latest one. > > > > > > > > > > > > > > Denis > > > > > > > > > > > > > > On Tuesday, June 5, 2018, Dmitriy Setrakyan < > > dsetrak...@apache.org > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Alex, > > > > > > > > > > > > > > > > I think it is OK to break TCK 1.0.1 tests in favor of TCK 1.1. > > > Once > > > > > we > > > > > > > > finish the migration, I would remove the TCK 1.0.1 test suite > > > > > > altogether. > > > > > > > > > > > > > > > > D. > > > > > > > > > > > > > > > > On Tue, Jun 5, 2018 at 11:13 AM, Александр Меньшиков < > > > > > > > sharple...@gmail.com > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Okay. There are tests results: > > > > > > > > > > > > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=1361493; > > > > > > > > > > > tab=buildResultsDiv=IgniteTests24Java8_JCacheTck11 > > > > > > > > > > > > > > > > > > It's the same as locally. > > > > > > > > > > > > > > > > > > Also, I have created sub-tasks for all problems we have: > > > > > > > > > > > > > > > > > > 1) CacheManagerTest.getUnsafeTypedCacheRequest failed. > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-8704 > > > > > > > > > > > > > > > > > > 2) CacheMBStatisticsBeanTest.testClear failed. > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-8705 > > > > > > > > > > > > > > > > > > 3) CacheManagerTest.close_cachesEmpty failed. > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-8708 > > > > > > > > > > > > > > > > > > 4) CacheMBStatisticsBeanTest.testPutIfAbsent failed. > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-8709 > > > > > > > > > > > > > > > > > > 5) CacheEntryEvent.getOldValue should be available. > > > > > > > > > Two tests fail because of it. > > > > > > > > > > > > > > > > > > Looks like a bug. > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-8714 > > > > > > > > > > > > > > > > > > 6) Problems with Closeable objects from Factory > > > > > > > > > > > > > > > > > > *98* tests fail because of it. > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-8715 > > > > > > > > > > > > > > > > > > > > > > > > > > > For first 4 problems, I already have PRs. > > > > > > > > > Problems 2) and 3) will break tests for TCK 1.0.1 because > > these > > > > > tests > > > > > > > > work > > > > > > > > > wrong in 1.0.1, > > > > > >
[ML] Machine Learning Pipeline Improvement
Hi Igniters, I suggest to add and implement by myself sequential pipeline of machine learning operations including all preprocessing stages like Pipeline object in Python library scikit-learn (look here http://scikit-learn.org/stable/modules/generated/sklearn.pipeline.Pipeline.html for the details) It can be combined with current Cross-Validator and Evaluator objects. The possible solution will sequentially apply a list of transforms and a final estimator. Alexey
[jira] [Created] (IGNITE-9033) .NET: specify expiry policy when creating cache using thin client
Igor Sapego created IGNITE-9033: --- Summary: .NET: specify expiry policy when creating cache using thin client Key: IGNITE-9033 URL: https://issues.apache.org/jira/browse/IGNITE-9033 Project: Ignite Issue Type: New Feature Components: platforms Reporter: Igor Sapego Need to add ability to create dynamic caches specifying expiry policy with thin client. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: TC issue. Spring Data build.
Hi Nikolay, There was an issue in spring data when we were migrating to spring data 2.0. And if you PR is based on old master branch issue can happen. Is this PR's base quite fresh? Sincerely, Dmitriy Pavlov чт, 19 июл. 2018 г. в 14:32, Nikolay Izhikov : > Hello, Igniters. > > I faced with TC issue for my PR [1] > Seems like some TC misconfiguration. > Locally, all runs OK. > > AFAIK, other Igniters also gets this error on TC. > > Please, help me with TC configuration. > > > https://ci.ignite.apache.org/viewLog.html?buildId=1512664=buildResultsDiv=IgniteTests24Java8_SpringData#testNameId-4044715836195573554 > > Caused by: org.springframework.beans.BeanInstantiationException: Failed to > instantiate [org.apache.ignite.Ignite]: Factory method 'igniteInstance' > threw exception; nested exception is > java.lang.NoClassDefFoundError: Could not initialize class > org.apache.ignite.internal.IgniteVersionUtils > at > org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:185) > at > org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:579) > ... 61 more > Caused by: java.lang.NoClassDefFoundError: Could not initialize class > org.apache.ignite.internal.IgniteVersionUtils > at > org.apache.ignite.internal.IgniteKernal.ackAsciiLogo(IgniteKernal.java:1892) > at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:843) > > > [1] https://github.com/apache/ignite/pull/4378
TC issue. Spring Data build.
Hello, Igniters. I faced with TC issue for my PR [1] Seems like some TC misconfiguration. Locally, all runs OK. AFAIK, other Igniters also gets this error on TC. Please, help me with TC configuration. https://ci.ignite.apache.org/viewLog.html?buildId=1512664=buildResultsDiv=IgniteTests24Java8_SpringData#testNameId-4044715836195573554 Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.apache.ignite.Ignite]: Factory method 'igniteInstance' threw exception; nested exception is java.lang.NoClassDefFoundError: Could not initialize class org.apache.ignite.internal.IgniteVersionUtils at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:185) at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:579) ... 61 more Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.apache.ignite.internal.IgniteVersionUtils at org.apache.ignite.internal.IgniteKernal.ackAsciiLogo(IgniteKernal.java:1892) at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:843) [1] https://github.com/apache/ignite/pull/4378 signature.asc Description: This is a digitally signed message part
[GitHub] ignite pull request #4385: IGNITE-9021
GitHub user zaleslaw opened a pull request: https://github.com/apache/ignite/pull/4385 IGNITE-9021 - Fixed tests - Leave classes used in MLP/DT/another algorithms only - Fixed code-style for many places You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9021 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4385.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4385 commit ca6a608bd6fff3a8e719ad475c0d662f38bf7f60 Author: Zinoviev Alexey Date: 2018-07-19T10:34:22Z IGNITE-9021: refactored impls and tests commit ea6f95655f957dc8ac97fed4157e395025bacd3c Author: Zinoviev Alexey Date: 2018-07-19T11:28:43Z IGNITE-9021: fixed code issues ---
[GitHub] ignite pull request #4384: fix 3
GitHub user dgarus opened a pull request: https://github.com/apache/ignite/pull/4384 fix 3 You can merge this pull request into a Git repository by running: $ git pull https://github.com/dgarus/ignite ignte-8131_fix_3 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4384.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4384 commit eed42a68a27f4f2388df96c04136938817a54c5f Author: Garus Denis Date: 2018-07-19T10:28:28Z IGNITE-8183. fix 3 commit c6979b01fe6b15fcac76ca213555ea0752d66543 Author: Garus Denis Date: 2018-07-19T11:29:25Z fix 3 remove fail from test ---
[GitHub] ignite pull request #4383: IGNITE-9004
GitHub user EdShangGG opened a pull request: https://github.com/apache/ignite/pull/4383 IGNITE-9004 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9004 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4383.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4383 commit c4ab6c9481d0b019434e65085c08f501a58259c8 Author: EdShangGG Date: 2018-07-17T19:13:32Z IGNITE-9004 WIP commit 3229732dee496a22606504893681d2cec3f7dc93 Author: EdShangGG Date: 2018-07-18T11:50:54Z IGNITE-9004 WIP commit 476de884606860599156b15b338c59353dc2a980 Author: EdShangGG Date: 2018-07-18T16:23:47Z IGNITE-9004 WIP commit 3c1f0503c934dcafa475a21cc9f2859324e5978d Author: EdShangGG Date: 2018-07-18T19:00:49Z IGNITE-9004 WIP commit 3cd22b88c8569b9d9bd6efeafc217019df5d99ad Author: Eduard Shangareev Date: 2018-07-19T11:27:57Z Revert "IGNITE-9004 WIP" This reverts commit 3c1f050 ---
[GitHub] ignite pull request #4382: IGNITE-8183. fix 3
Github user dgarus closed the pull request at: https://github.com/apache/ignite/pull/4382 ---
Re: Place Ignite Abbrev Plugin to ASF Ignite supplementary git repo
Hi Vyacheslav,
For Abbrev plugin I also thought that ASF git repo as primary and
https://github.com/apacheignite mirror would cover all cases.
Thank you for sharing your vision.
Sincerely,
Dmitriy Pavlov
чт, 19 июл. 2018 г. в 9:08, Vyacheslav Daradur :
> I vote for a separate repo for the Ignite Abbrev Plugin project.
>
> The reason is:
> Ignite Abbrev Plugin - build on top of IntelliJ Platform SDK [1] and
> can't be easily packaged without it, moreover, it doesn't depend on
> Ignite internals (unlike .NET/C++ clients).
>
> One more place where we could place the project (if this repo
> maintained by Ignite's commiters) [2].
>
> [1] http://www.jetbrains.org/intellij/sdk/docs/welcome.html
> [2] https://github.com/apacheignite
> On Thu, Jul 19, 2018 at 12:48 AM Dmitry Pavlov
> wrote:
> >
> > Hi Denis,
> >
> > This option can be considered also. I have no arguments against this
> > solution.
> >
> > In the same time I think Ignite developer will need pre-build
> distributive
> > (Jar) of plugin, probably in /idea subfolder.
> >
> > So standalone ASF repo & [build/link to build] in main repo can be still
> > considered. This option can save checkout time, and reduce main repo
> size.
> >
> > I hope this make sense. I would appreciate Igniter's opinion on this
> topic.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > ср, 18 июл. 2018 г. в 23:05, Denis Magda :
> >
> > > Hi Dmitriy,
> > >
> > > Yes, I would have this tool at hands soon as I check out Ignite repo
> and
> > > start setting it up. However, instead of a new repo let's place it
> under
> > > {ignite}/dev-tools folder. What do you think?
> > >
> > > --
> > > Denis
> > >
> > > On Wed, Jul 18, 2018 at 4:37 AM Dmitry Pavlov
> > > wrote:
> > >
> > > > Hi Igniters,
> > > >
> > > > There is one mode widely used tool in Apache Ignite, abbreviation
> plugin
> > > > for Intelli J Idea. This plugin is used by almost all experienced
> Ignite
> > > > contributors.
> > > >
> > > > I would like to say thanks to all contributors which created this
> plugin:
> > > > vkazakov, sevdokimov, daradurvs, agoncharuk. And because this plugin
> is
> > > > also a part of our process I also want to place plugin code to ASF
> > > > repository.
> > > >
> > > > What do you think about placing plugin code to supplementary Apache
> > > > repository? Please share your vision till 24 July.
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > >
> > > >
> > >
> https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules#AbbreviationRules-IntelliJIdeaPlugin
> > > >
> > > >
> > > > https://github.com/dspavlov/ignite-abbrev-plugin
> > > >
> > >
>
>
>
> --
> Best Regards, Vyacheslav D.
>
Re: Place Ignite TC helper to ASF Ignite supplementary git repo
Hi Dmitriy, Yes, I'm going to create INFRA ticket for new ASF supplementary repository for project, I just want to be absolutely sure, that Community supports my plan. Or do you mean I need to create ticket to find out if domain mtcga.ignite.apache.org is possible to create? Sincerely, Dmitriy Pavlov чт, 19 июл. 2018 г. в 1:43, Dmitriy Setrakyan : > Dmitriy, > > I think you should file an INFRA ticket and ask if this is possible. > > D. > > On Wed, Jul 18, 2018 at 3:12 PM, Denis Magda wrote: > > > Dmitriy, > > > > Things for clearing the things out. No objections from my side then. > > > > Let's see what other Ignite fellows think on your proposal. Someone might > > have a different perspective. > > > > -- > > Denis > > > > On Wed, Jul 18, 2018 at 1:58 PM Dmitry Pavlov > > wrote: > > > > > Hi Denis, > > > > > > It will made things simple. > > > > > > 1) For example any comitter will be able to change rules of > notification > > > and fix the Bot if something goes wrong. Now it is my github repo. ASF > > repo > > > will guarantee that code will be always accessible by community > members. > > > > > > 2) Being a part of ASF repo the Bot will be simple thing that less > > > experienced developer can start with. The Bot uses latest AI release as > > DB > > > with persistence enabled, so bot developer became at least Apache > Ignite > > > user, and as most - new contributor. > > > > > > If we agree to place this bot to ASF, next step could be asking Infra > > Team > > > to provide 2nd level apache domain, e.g. mtcga.ignite.apache.org for > web > > > UI. I guess it would be plus if our tool code is available in ASF repo, > > but > > > not in some private git repo. > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > ср, 18 июл. 2018 г. в 23:03, Denis Magda : > > > > > > > Hi Dmitriy, > > > > > > > > The whole year has passed since this initiative launch, hell, the > times > > > > passes by :) > > > > > > > > What would be the benefits of having the tool in the Apache repo? > Does > > it > > > > simplify the things for us. > > > > > > > > -- > > > > Denis > > > > > > > > On Wed, Jul 18, 2018 at 3:59 AM Dmitry Pavlov > > > > > wrote: > > > > > > > > > Hi Igniters, > > > > > > > > > > Almost 1 year has passed since Make Teamcity Green Again was > > initially > > > > > proposed. During this process we managed to get almost successful > Run > > > > Alls > > > > > in master, but currently regressions still occur. We all tried a > lot > > of > > > > > things: careful examination of PR tests, continuous monitoring of > > > master, > > > > > suite responsible contributor, tickets creation and so on. > > > > > > > > > > According to Igniter's feedback most productive thing was master > > > > monitoring > > > > > and timely fix of new failures. But contributor’s enthusiasm is > > limited > > > > and > > > > > monitoring is not most enjoyable thing, so it's time to automate > this > > > > > activity. I’ve created MTCGA.Bot which sends emails about new > > failures > > > > and > > > > > in addition has a couple of useful features. > > > > > > > > > > The Bot is being developed only based on your feedback. 30 Ignite > > > > > developers already tried it. I'm going to run short > > > webinar/presentation > > > > at > > > > > Mon 23 July and tell more about Bot capabilites, so everyone can > make > > > an > > > > > impression. > > > > > > > > > > I would like to continue development and I propose to place TC > Helper > > > > code > > > > > to Apache Ignite supplementary repository (same as ignite-release). > > > What > > > > do > > > > > you think about it? Please share your vision till 24 July. > > > > > > > > > > Sincerely, > > > > > Dmitriy Pavlov > > > > > > > > > > References: > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/ > > Make+Teamcity+Green+Again#MakeTeamcityGreenAgain-MTCGABot > > > > > > > > > > https://github.com/dspavlov/ignite-teamcity-helper > > > > > > > > > > > > > > >
[GitHub] ignite pull request #4382: IGNITE-8183. fix 3
GitHub user dgarus opened a pull request: https://github.com/apache/ignite/pull/4382 IGNITE-8183. fix 3 You can merge this pull request into a Git repository by running: $ git pull https://github.com/dgarus/ignite ignte-8131_fix_3 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4382.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4382 commit eed42a68a27f4f2388df96c04136938817a54c5f Author: Garus Denis Date: 2018-07-19T10:28:28Z IGNITE-8183. fix 3 ---
Re: Place Ignite TC helper to ASF Ignite supplementary git repo
Hi Vyacheslav, Thank you for your feedback. https://github.com/apacheignite will have mirror from ASF repository, as docs or main repo have. Sincerely, Dmitriy Pavlov чт, 19 июл. 2018 г. в 8:54, Vyacheslav Daradur : > I vote for a separate repo for the TC helper project. > > IMO TC Helper - is an application project and a separate repo is a > more convenient way to the project developing. > > One more place where we could place the project (if the place > maintained by Ignite's commiters): > https://github.com/apacheignite > > On Thu, Jul 19, 2018 at 1:43 AM Dmitriy Setrakyan > wrote: > > > > Dmitriy, > > > > I think you should file an INFRA ticket and ask if this is possible. > > > > D. > > > > On Wed, Jul 18, 2018 at 3:12 PM, Denis Magda wrote: > > > > > Dmitriy, > > > > > > Things for clearing the things out. No objections from my side then. > > > > > > Let's see what other Ignite fellows think on your proposal. Someone > might > > > have a different perspective. > > > > > > -- > > > Denis > > > > > > On Wed, Jul 18, 2018 at 1:58 PM Dmitry Pavlov > > > wrote: > > > > > > > Hi Denis, > > > > > > > > It will made things simple. > > > > > > > > 1) For example any comitter will be able to change rules of > notification > > > > and fix the Bot if something goes wrong. Now it is my github repo. > ASF > > > repo > > > > will guarantee that code will be always accessible by community > members. > > > > > > > > 2) Being a part of ASF repo the Bot will be simple thing that less > > > > experienced developer can start with. The Bot uses latest AI release > as > > > DB > > > > with persistence enabled, so bot developer became at least Apache > Ignite > > > > user, and as most - new contributor. > > > > > > > > If we agree to place this bot to ASF, next step could be asking Infra > > > Team > > > > to provide 2nd level apache domain, e.g. mtcga.ignite.apache.org > for web > > > > UI. I guess it would be plus if our tool code is available in ASF > repo, > > > but > > > > not in some private git repo. > > > > > > > > Sincerely, > > > > Dmitriy Pavlov > > > > > > > > ср, 18 июл. 2018 г. в 23:03, Denis Magda : > > > > > > > > > Hi Dmitriy, > > > > > > > > > > The whole year has passed since this initiative launch, hell, the > times > > > > > passes by :) > > > > > > > > > > What would be the benefits of having the tool in the Apache repo? > Does > > > it > > > > > simplify the things for us. > > > > > > > > > > -- > > > > > Denis > > > > > > > > > > On Wed, Jul 18, 2018 at 3:59 AM Dmitry Pavlov < > dpavlov@gmail.com> > > > > > wrote: > > > > > > > > > > > Hi Igniters, > > > > > > > > > > > > Almost 1 year has passed since Make Teamcity Green Again was > > > initially > > > > > > proposed. During this process we managed to get almost > successful Run > > > > > Alls > > > > > > in master, but currently regressions still occur. We all tried a > lot > > > of > > > > > > things: careful examination of PR tests, continuous monitoring of > > > > master, > > > > > > suite responsible contributor, tickets creation and so on. > > > > > > > > > > > > According to Igniter's feedback most productive thing was master > > > > > monitoring > > > > > > and timely fix of new failures. But contributor’s enthusiasm is > > > limited > > > > > and > > > > > > monitoring is not most enjoyable thing, so it's time to automate > this > > > > > > activity. I’ve created MTCGA.Bot which sends emails about new > > > failures > > > > > and > > > > > > in addition has a couple of useful features. > > > > > > > > > > > > The Bot is being developed only based on your feedback. 30 Ignite > > > > > > developers already tried it. I'm going to run short > > > > webinar/presentation > > > > > at > > > > > > Mon 23 July and tell more about Bot capabilites, so everyone can > make > > > > an > > > > > > impression. > > > > > > > > > > > > I would like to continue development and I propose to place TC > Helper > > > > > code > > > > > > to Apache Ignite supplementary repository (same as > ignite-release). > > > > What > > > > > do > > > > > > you think about it? Please share your vision till 24 July. > > > > > > > > > > > > Sincerely, > > > > > > Dmitriy Pavlov > > > > > > > > > > > > References: > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/ > > > Make+Teamcity+Green+Again#MakeTeamcityGreenAgain-MTCGABot > > > > > > > > > > > > https://github.com/dspavlov/ignite-teamcity-helper > > > > > > > > > > > > > > > > > > > > > > -- > Best Regards, Vyacheslav D. >
Re: Place Ignite Abbrev Plugin to ASF Ignite supplementary git repo
I vote for a separate repo for the Ignite Abbrev Plugin project.
The reason is:
Ignite Abbrev Plugin - build on top of IntelliJ Platform SDK [1] and
can't be easily packaged without it, moreover, it doesn't depend on
Ignite internals (unlike .NET/C++ clients).
One more place where we could place the project (if this repo
maintained by Ignite's commiters) [2].
[1] http://www.jetbrains.org/intellij/sdk/docs/welcome.html
[2] https://github.com/apacheignite
On Thu, Jul 19, 2018 at 12:48 AM Dmitry Pavlov wrote:
>
> Hi Denis,
>
> This option can be considered also. I have no arguments against this
> solution.
>
> In the same time I think Ignite developer will need pre-build distributive
> (Jar) of plugin, probably in /idea subfolder.
>
> So standalone ASF repo & [build/link to build] in main repo can be still
> considered. This option can save checkout time, and reduce main repo size.
>
> I hope this make sense. I would appreciate Igniter's opinion on this topic.
>
> Sincerely,
> Dmitriy Pavlov
>
> ср, 18 июл. 2018 г. в 23:05, Denis Magda :
>
> > Hi Dmitriy,
> >
> > Yes, I would have this tool at hands soon as I check out Ignite repo and
> > start setting it up. However, instead of a new repo let's place it under
> > {ignite}/dev-tools folder. What do you think?
> >
> > --
> > Denis
> >
> > On Wed, Jul 18, 2018 at 4:37 AM Dmitry Pavlov
> > wrote:
> >
> > > Hi Igniters,
> > >
> > > There is one mode widely used tool in Apache Ignite, abbreviation plugin
> > > for Intelli J Idea. This plugin is used by almost all experienced Ignite
> > > contributors.
> > >
> > > I would like to say thanks to all contributors which created this plugin:
> > > vkazakov, sevdokimov, daradurvs, agoncharuk. And because this plugin is
> > > also a part of our process I also want to place plugin code to ASF
> > > repository.
> > >
> > > What do you think about placing plugin code to supplementary Apache
> > > repository? Please share your vision till 24 July.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > >
> > >
> > https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules#AbbreviationRules-IntelliJIdeaPlugin
> > >
> > >
> > > https://github.com/dspavlov/ignite-abbrev-plugin
> > >
> >
--
Best Regards, Vyacheslav D.
