Ignite-spring-boot-autoconfigurer

2020-01-11 Thread Николай Ижиков
Hello, Igniters.

During Ignite meetup I took part in there was a request from the users.
They propose to create a custom spring boot autoconfigurer module for Ignite.
This module should provide a smooth injection of Ignite to any spring-boot 
application.

I've implemented a tiny straightforward prototype of the module [1] 
Examples of the usage of integration can be found in the example application 
[2] 

For now, the module provides the following features:

1. Starts Ignite node and inject it in the spring ApplicationContext if bean of 
the type IgniteConfiguration exists in the context.
This can be achieved in two ways:
* create `IgniteConfiguration` from java code [3] 
* add `ignite.xml` file to the application context [4] 

2. Starts IgniteClient instance and injects it int the spring Application if: 
* ClientConfiguration bean exists in the context [5] 
* `spring.data.ignite.clientAddresses` exists in the application 
properties. [6] 

I have a following questions regards new module:

1. We have an extension initiative so where is the right place for the new 
module?
2. Do we have spring experts in the community? What other features for this 
autoconfigurer module required?

[1] https://github.com/apache/ignite/pull/7237/files
[2] https://github.com/nizhikov/ignite-spring-boot-autoconfigure-example
[3] 
https://github.com/nizhikov/ignite-spring-boot-autoconfigure-example/tree/master/src/main/java/org/apache/ignite/spring/boot/configfrombean
[4] 
https://github.com/nizhikov/ignite-spring-boot-autoconfigure-example/tree/master/src/main/java/org/apache/ignite/spring/boot/configfromfile
[5] 
https://github.com/nizhikov/ignite-spring-boot-autoconfigure-example/tree/master/src/main/java/org/apache/ignite/spring/boot/thinclientfrombean
[6] 
https://github.com/nizhikov/ignite-spring-boot-autoconfigure-example/tree/master/src/main/java/org/apache/ignite/spring/boot/thinclientfromconfig



[MTCGA]: new failures in builds [4915518] needs to be handled

2020-01-11 Thread dpavlov . tasks
Hi Igniters,

 I've detected some new issue on TeamCity to be handled. You are more than 
welcomed to help.

 *New stable failure of a flaky test in master-nightly 
IgniteShutdownOnSupplyMessageFailureTest.testShutdownOnSupplyMessageFailure 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=3621332090219359104=%3Cdefault%3E=testDetails
 No changes in the build

 - 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 19:48:40 11-01-2020 


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

2020-01-11 Thread Sergey Antonov
Guys, I created two pull requests [1] [2] for 2.8 release.

First of them [1] is a patch with ticket [3] for ignite-2.8 branch.
Second [2] is a revert of ticket [4] from 2.8 release.

I'm waiting TC run all nightly results for both PRs. I'll write update when
TC runs will be ok.
I'm okay with both proposals (add ticket [1] to release, remove read-only
feature from 2.8 release scope). But I'm not okay with @IgniteExperemental
annotation.

[1] https://github.com/apache/ignite/pull/7239
[2] https://github.com/apache/ignite/pull/7238
[3] https://issues.apache.org/jira/browse/IGNITE-12225
[4] https://issues.apache.org/jira/browse/IGNITE-11256


пт, 10 янв. 2020 г. в 14:21, Zhenya Stanilovsky :

>
> Ivan, if i correctly understand, you suggest additional «expiremental»
> stuff only for hiding already leaked RO interface ?
> poor approach as for me.
>
> >Folks,
> >
> >Some thoughts:
> >* Releasing an API with known fallacies sounds really bad thing to me.
> >It can have a negative consequences for a whole project for years. My
> >opinion here that we should resolve the problem with this API somehow
> >before release.
> >* We can mark cluster read-only API (without enum) as experimental and
> >change the API in e.g. 2.8.1.
> >* We can try to exclude read-only API from 2.8 at all.
> >
> >What do you think?
> >
> >пт, 10 янв. 2020 г. в 11:20, Alex Plehanov < plehanov.a...@gmail.com >:
> >>
> >> Guys,
> >>
> >> There is also an issue with cluster activation by thin clients. This
> >> feature (.NET thin client API change and protocol change) was added by
> [1]
> >> without any discussion on dev-list. Sergey's patch [2] deprecate methods
> >> "IgniteCluster.active(boolean)" and "IgniteCluster.active()", but
> didn't do
> >> this for thin clients. If we want to include IGNITE-12225 to 2.8 we also
> >> should not forget about thin client changes, since it will be strange
> if we
> >> introduce some methods to thin client API and protocol and in the same
> >> Ignite version deprecate these methods for servers and thick clients.
> >>
> >> [1]:  https://issues.apache.org/jira/browse/IGNITE-11709
> >> [2]:  https://issues.apache.org/jira/browse/IGNITE-12225
> >>
> >>
> >> пт, 10 янв. 2020 г. в 10:24, Zhenya Stanilovsky <
> arzamas...@mail.ru.invalid
> >> >:
> >>
> >> >
> >> >
> >> > Agree with Nikolay, -1 from me, too.
> >> >
> >> > >Hello, Igniters.
> >> > >
> >> > >I’m -1 to include the read-only patch to 2.8.
> >> > >I think we shouldn’t accept any patches to 2.8 except bug fixes for
> >> > blockers and major issues.
> >> > >
> >> > >Guys, we don’t release Apache Ignite for 13 months!
> >> > >We should focus on the release and make it ASAP.
> >> > >
> >> > >We can’t extend the scope anymore.
> >> > >
> >> > >> 10 янв. 2020 г., в 04:29, Sergey Antonov <
> antonovserge...@gmail.com >
> >> > написал(а):
> >> > >>
> >> > >> Hello, Maxim!
> >> > >>
> >> > >>> This PR [2] doesn't look a very simple +5,517 −2,038, 111 files
> >> > >> changed.
> >> > >> Yes, PR is huge, but I wrote a lot of new tests and reworked
> already
> >> > >> presented. Changes in product code are minimal - only 30 changed
> files
> >> > in
> >> > >> /src/main/ part. And most of them are new control.sh commands and
> >> > >> configuration.
> >> > >>
> >> > >>> Do we have customer requests for this feature or maybe users who
> are
> >> > >> waiting for exactly that ENUM values exactly in 2.8 release (not
> the
> >> > 2.8.1
> >> > >> for instance)?
> >> > >> Can we introduce in new features in maintanance release (2.8.1)?
> Cluster
> >> > >> read-only mode will be new feature, if we remove
> IgniteCluster#readOnly
> >> > in
> >> > >> 2.8 release. If all ok with that, lets remove
> IgniteCluster#readOnly and
> >> > >> move ticket [1] to 2.8.1 release.
> >> > >>
> >> > >>> Do we have extended test results report (on just only TC.Bot green
> >> > visa)
> >> > >> on this feature to be sure that we will not add any blocker issues
> to
> >> > the
> >> > >> release?
> >> > >> I'm preparing patch for 2.8 release and I will get new TC Bot visa
> vs
> >> > >> release branch.
> >> > >>
> >> > >> [1]  https://issues.apache.org/jira/browse/IGNITE-12225
> >> > >>
> >> > >>
> >> > >>
> >> > >> чт, 9 янв. 2020 г. в 19:38, Maxim Muzafarov <  mmu...@apache.org
> >:
> >> > >>
> >> > >>> Folks,
> >> > >>>
> >> > >>>
> >> > >>> Let me remind you that we are working on the 2.8 release branch
> >> > >>> stabilization currently (please, keep it in mind).
> >> > >>>
> >> > >>>
> >> > >>> Do we have a really STRONG reason for adding such a change [1] to
> the
> >> > >>> ignite-2.8 branch? This PR [2] doesn't look a very simple +5,517
> >> > >>> −2,038, 111 files changed.
> >> > >>> Do we have customer requests for this feature or maybe users who
> are
> >> > >>> waiting for exactly that ENUM values exactly in 2.8 release (not
> the
> >> > >>> 2.8.1 for instance)?
> >> > >>> Can we just simply remove IgniteCluster#readOnly to eliminate any
> >> > >>> backward compatibility issues