Re: [ANNOUNCE] New committer: Roman Puchkovskiy

[Roman Puchkovskiy]

Thanks guys.

ср, 8 мая 2024 г. в 16:15, Stephen Darlington :
>
> Congratulations!
>
> On Wed, 8 May 2024 at 12:07, Mirza Aliev  wrote:
>
> > Congratulations, Roman!
> >
> > ср, 8 мая 2024 г. в 10:27, Zhenya Stanilovsky  > >:
> >
> > >
> > > Great ! My congrats too !
> > >
> > >
> > >
> > > >Congrats, Roman! Well deserved!
> > > >
> > > >Thanks,
> > > >S.
> > > >
> > > >ср, 8 мая 2024г. в 07:28, Pavel Tupitsyn < ptupit...@apache.org >:
> > > >
> > > >> Dear Igniters,
> > > >>
> > > >> The Project Management Committee (PMC) for Apache Ignite
> > > >> has invited Roman Puchkovskiy to become a committer and we are pleased
> > > >> to announce that they have accepted.
> > > >>
> > > >> Being a committer enables easier contribution to the
> > > >> project since there is no need to go via the patch
> > > >> submission process. This should enable better productivity.
> > > >>
> > > >> Roman, congratulations on your new role!
> > > >>
> > > >> Pavel Tupitsyn
> > > >> on behalf of Apache Ignite PMC
> > > >>
> > >
> > >
> > >
> > >
> >

Re: [ANNOUNCE] New committer: Mikhail Pochatkin

[Roman Puchkovskiy]

Congratulations!

ср, 8 мая 2024 г. в 10:28, Zhenya Stanilovsky :
>
>
> Great ! Good luck Mikhail !
>
>
>
> >Congratulations, keep it going!
> >
> >Thanks,
> >S.
> >
> >ср, 8 мая 2024г. в 07:27, Pavel Tupitsyn < ptupit...@apache.org >:
> >
> >> Dear Igniters,
> >>
> >> The Project Management Committee (PMC) for Apache Ignite
> >> has invited Mikhail Pochatkin to become a committer and we are pleased
> >> to announce that they have accepted.
> >>
> >> Being a committer enables easier contribution to the
> >> project since there is no need to go via the patch
> >> submission process. This should enable better productivity.
> >>
> >> Mikhail, congratulations on your new role!
> >>
> >> Pavel Tupitsyn
> >> on behalf of Apache Ignite PMC
> >>
>
>
>
>

Re: [Announce] New committer: Iurii Gerzhedovich

[Roman Puchkovskiy]

Congratulations!

вт, 13 февр. 2024 г. в 23:51, Dmitriy Pavlov :
>
> Dear Igniters,
>
> The Project Management Committee (PMC) for Apache Ignite
> has invited Iurii Gerzhedovich to become a committer and we are pleased
> to announce that he has accepted.
>
> Being a committer enables easier contribution to the
> project since there is no need to go via the patch
> submission process. This should enable better productivity.
>
>
> Please join me in sincere congratulations to Iurii on his new role!
> Iurii, keep the pace!
>
>
> Sincerely,
> Dmitriy Pavlov on behalf of Apache Ignite PMC

Re: [DISCUSSION] IEP-112: Ignite 3. Criteria API queries

[Roman Puchkovskiy]

Hi Andrey. I believe IEP-112 is already taken, please consult
https://cwiki.apache.org/confluence/display/IGNITE/Active+Proposals
The lowest free number is 115.

ср, 15 нояб. 2023 г. в 16:12, Andrey Novikov :
>
> Hi all,
>
> Please review "IEP-112: Ignite 3. Criteria API queries” proposal.
> The main purpose of this document is to describe criteria API queries
> from the user's point of view.
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-112%3A+Ignite+3.+Criteria+API+querie
> s

Re: [DISCUSSION] Service awareness for thin client.

[Roman Puchkovskiy]

Hi Vladimir. Sorry to intervene, but we have a clash with IEP numbers,
there is already IEP-110 in Ignite 3, it was created on August, 1:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-110%3A+Schema+synchronization%3A+basic+schema+changes

Is it possible to pick another number, while your IEP is fresh?

чт, 26 окт. 2023 г. в 14:05, Vladimir Steshin :
>
>  All right. Pavel, thank you.
>
> IEP:
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-110+Thin+Client+Service+Awareness
>
> Ticket: https://issues.apache.org/jira/browse/IGNITE-20656
>
> On 25.10.2023 11:04, Pavel Tupitsyn wrote:
> > Looks good to me
> >
> > On Tue, Oct 24, 2023 at 1:50 PM Vladimir Steshin  wrote:
> >
> >>   We've privately discussed with Mikhail Petrov and Alexey Plekhanov.
> >> To us, #2 seems OK with the exceptions that a dedicated request would be
> >> better for transferring the service topology. And it should be processed
> >> by the client instead of every service proxy.
> >>
> >> So, the suggested solution is:
> >> 1) Bring a new feature to the thin client protocol.
> >> 2) Require the partition awareness flag enabled.
> >> 3) Obtain service topology with a dedicated request by the client and
> >> provide it to the service proxies.
> >> 4) Initiate the topology update with: first service invocation, cluster
> >> topology change, some timeout (only if service is invoked).
> >>
> >> Cons:
> >>- Some delay of the topology obtaining. The invocation redirects are
> >> still possible when service migrates.
> >>- No sign of service cancel/deploy on the client side. We have to
> >> update by a timeout too.
> >>- The topology is probably kept by client while it exists even if is
> >> not in use any more.
> >>
> >> If the suggestion looks reasonable, I'm ready to implement, create IEP.
> >>
> >> On 17.10.2023 18:28, Vladimir Steshin wrote:
> >>>  They barely can guarantee. If client miss service instance node,
> >>> the request is just redirected. But I talk about the most reliable way
> >>> to keep actual service topology. If we watch cluster topology change
> >>> event, we have to take in account cases like:
> >>>
> >>> - Client request service, gets its topology
> >>>
> >>> - The service is canceled and redeployed to another nodes. No cluster
> >>> topology change, no sign of it on the client side.
> >>>
> >>> - Client continue service requesting and misses instance node forever
> >>> or often.
> >>>
> >>> If we provide, for example, version or hash of client topology version
> >>> in every service call request, we always get actual service topology
> >>> just by comparing on server side. Independently of why and when
> >>> service redeploys. Isn't it simple and safe?
> >>>
> >>> On 17.10.2023 15:52, Pavel Tupitsyn wrote:
>  None of the described approaches provides 100% guarantee of hitting the
>  primary node in all conditions.
>  And it is fine to miss a few requests. I don't see a reason to increase
>  complexity trying to optimize a rare use case.
> 
>  On Tue, Oct 17, 2023 at 2:49 PM  wrote:
> 
> > What if topology change event preceedes service redeployment and
> >> service
> > mapping change? There a possibility for client to save new topology
> >> version
> > before services are actually redeployed. If we rely on actual change
> >> of the
> > service mapping (redeployment), there is no such problem.
> >
> > On 17.10.2023 13:44, Pavel Tupitsyn  wrote:
> >> I think if it's good enough for cache partition awareness, then it's
> >> good
> >> enough for services. Topology changes are not that frequent.
> >>
> >> On Tue, Oct 17, 2023 at 12:22 PM  wrote:
> >>
> >>> Hi, Pavel.
> >>>
> >>> 1. Correct.
> >>> 2. Yes, client watches ClientFlag.AFFINITY_TOPOLOGY_CHANGED flag and
> > sends
> >>> additional ClientOperation.CLUSTER_GROUP_GET_NODE_ENDPOINTS to get
> >> new
> >>> cluster topology. Thus, the topology updates with some delay. We
> >> could
> >>> watch this event somehow in the service proxy. But direct service
> > topology
> >>> version in the call responses should work faster if service is being
> >>> requested. Or you think this is not significant?
> >>>
> >>>
> >>> On 17.10.2023 11:13, Pavel Tupitsyn  wrote:
>  Hi Vladimir,
> 
>  1. A topology of a deployed service can change only when the cluster
>  topology changes.
>  2. We already have a topology change flag in every server response.
> 
>  Therefore, the client can request the topology once per service, and
>  refresh it when cluster topology changes, right?
> 
> 
>  On Mon, Oct 16, 2023 at 8:17 PM Vladimir Steshin >>> wrote:
> > Hi Igniters! I propose to add the /service awareness feature to the
> >>> thin
> > client/. I remember a couple of users asked of it. Looks nice to
> >> have
> > 

Re: [ANNOUNCE] Welcome Aleksandr Polovtsev as a new committer

[Roman Puchkovskiy]

Congratulations!

пн, 21 авг. 2023 г. в 09:29, Pavel Tupitsyn :
>
> Congratulations, Aleksandr! Well deserved!
>
> On Mon, Aug 21, 2023 at 8:01 AM Kseniya Romanova 
> wrote:
>
> > Igniters!
> >
> > The Project Management Committee (PMC) for Apache Ignite has invited
> > Aleksandr
> > Polovtsev to become a committer and we are pleased to announce that he has
> > accepted.
> >
> > Alexandr makes valuable contributions to the Apache Ignite code (including
> > Node Join Protocol and Initialization[1] for the Ignite 3), participates in
> > important dev discussions and contributes as well to the Project awareness
> > by presenting twice at the Ignite Summit[2]
> >
> > Please join me in welcoming Alexandr, and congratulating him on the new
> > role in the Apache Ignite Community!
> >
> >
> > Kseniya Romanova
> >
> > on behalf of Apache Ignite PMC
> >
> > [1]
> >
> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-77%3A+Node+Join+Protocol+and+Initialization+for+Ignite+3
> >
> >
> > [2] https://ignite-summit.org/2023-june/sessions/484805
> > https://ignite-summit.org/2022-june/sessions/337234
> >

Re: [DISCUSSION] IEP-110: Schema synchronization: basic schema changes

[Roman Puchkovskiy]

Hi Andrey.

Thanks for noting this, I've added the implementation tickets.

чт, 27 июл. 2023 г. в 17:35, Andrey Gura :
>
> Hi, Roman.
>
> Thanks for IEP. Could you please also add tickets to the corresponding
> section (see otghert IEP's for example).
>
> On Mon, Jul 24, 2023 at 9:28 AM Roman Puchkovskiy
>  wrote:
> >
> > Hi Igniters!
> >
> > Please take a look at a proposal about the application of the Schema
> > Synchronization framework to basic schema change types in Ignite 3
> > [1].
> >
> > 1. 
> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-110%3A+Schema+synchronization%3A+basic+schema+changes

[DISCUSSION] IEP-110: Schema synchronization: basic schema changes

[Roman Puchkovskiy]

Hi Igniters!

Please take a look at a proposal about the application of the Schema
Synchronization framework to basic schema change types in Ignite 3
[1].

1. 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-110%3A+Schema+synchronization%3A+basic+schema+changes

Re: [DISCUSSION] IEP-108 Change column type feature in Ignite 3

[Roman Puchkovskiy]

Hi Andrey.

Would it make sense to include the following to the list of type
changes that do not require validation?

1. Increasing precision for a type containing a time component (TIME,
DATETIME, TIMESTAMP)
2. Conversion of anything to VARCHAR (with enough capacity)

ср, 14 июн. 2023 г. в 19:27, Andrey Mashenkov :
>
> Hi,
>
> Please review "IEP-108 Change column type” proposal
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-108+Change+column+type
>
> --
> Best regards,
> Andrey V. Mashenkov

Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3

[Roman Puchkovskiy]

Hi guys.

The thing is that we already use reactor-core transitively (it is a
dependency of scalecube-cluster-api and scalecube-cluster). We also
use it directly (in just a few places) in the networking code. If we
shade the one that comes with the micronaut, the other one will still
remain. We will probably need to shade all of them.

Even if we are going to do it, should we postpone such an aggressive
shading till a later date? It seems that it might be easier to develop
using the normal dependency model, without shading anything. We could
add the corresponding TODOs and resolve them closer to the GA.

What do you think?

пт, 17 февр. 2023 г. в 13:46, Andrey Mashenkov :
>
> Hi Ivan,
>
> I'm ok to add reactive-streams.jar, because it contains just interfaces
> that 1:1 java-flow API and FlowAdapter to convert JDK <-> ReactiveStreams
> interfaces.
>
> The interfaces available in JDK >= 9 java.util.concurrent.Flow, are 1:1
> > semantically equivalent to their respective Reactive Streams counterparts.
> > This means that there will be a migratory period, while libraries move to
> > adopt the new types in the JDK, however this period is expected to be short
> > - due to the full semantic equivalence of the libraries, as well as the
> > Reactive Streams <-> Flow adapter library as well as a TCK compatible
> > directly with the JDK Flow types.
>
>
> However,  Project-reactor dependency (e.g. reactor.core.publisher.Flux) is
> what we prefer to avoid or 'shadow' somehow.
>
>
> On Fri, Feb 17, 2023 at 10:49 AM Ivan Gagarkin 
> wrote:
>
> > There is a PR https://github.com/apache/ignite-3/pull/1569
> >
> > On Fri, Feb 17, 2023 at 11:47 AM Ivan Gagarkin 
> > wrote:
> >
> > > The wrong link is above. It returns
> > >
> > https://www.reactive-streams.org/reactive-streams-1.0.3-javadoc/org/reactivestreams/Publisher.html
> > >
> > > On Fri, Feb 17, 2023 at 11:45 AM Ivan Gagarkin 
> > > wrote:
> > >
> > >> We have to add reactor because we should implement
> > >>
> > https://github.com/micronaut-projects/micronaut-security/blob/master/security/src/main/java/io/micronaut/security/authentication/AuthenticationProvider.java
> > >> which returns
> > >>
> > https://micronaut-projects.github.io/micronaut-security/2.4.0/api/io/micronaut/security/authentication/AuthenticationProvider.html
> > .
> > >> I don't see any implementations in the project right now.
> > >>
> > >> On Fri, Feb 3, 2023 at 6:18 PM Михаил Початкин  > >
> > >> wrote:
> > >>
> > >>> Hi, Ivan.
> > >>>
> > >>> I don't see any problems with adding *micronaut-security* in the
> > context
> > >>> of
> > >>> the IGNITE-18575 epic of security implementation. Moreover, we already
> > >>> have
> > >>> several micronaut modules in dependencies (micronaut-inject,
> > >>> micronaut-runtime, micronaut-validation, micronaut-http, etc) and I
> > think
> > >>> that we should not deviate from a single ecosystem. I would also like
> > to
> > >>> see the answer to Alexander's question about the reactor dependency.
> > >>>
> > >>> Thanks!
> > >>>
> > >>> пт, 3 февр. 2023 г. в 12:11, Aleksandr Pakhomov :
> > >>>
> > >>> > Hi Ivan,
> > >>> >
> > >>> > Why do we add reactor dependency? The Ignite 3 codebase
> > >>> > uses java async API. Just wonder to know it we could escape
> > >>> > the usage of third party async libraries.
> > >>> >
> > >>> > --
> > >>> > Best regards,
> > >>> > Aleksandr
> > >>> >
> > >>> > > On 3 Feb 2023, at 10:51, Ivan Gagarkin 
> > >>> wrote:
> > >>> > >
> > >>> > > I'd like to add a few 3rd party libraries to Ignite 3
> > >>> > >
> > >>> > >   1. Micronaut Security
> > >>> > >
> > >>> https://micronaut-projects.github.io/micronaut-security/latest/guide/
> > >>> > >   2. Micronaut Reactor
> > >>> > >
> > >>> https://micronaut-projects.github.io/micronaut-reactor/latest/guide/
> > >>> > >
> > >>> > > We have to have them for authentication and authorization in the
> > >>> REST.
> > >>> > > https://issues.apache.org/jira/browse/IGNITE-18576
> > >>> > >
> > >>> > > WDYT? Any objections? Also, comments on IEP-87 are welcomed.
> > >>> > > --
> > >>> > > Best Regards, Ivan
> > >>> >
> > >>> >
> > >>>
> > >>> --
> > >>> С уважением,
> > >>> Початкин Михаил.
> > >>>
> > >>
> > >>
> > >> --
> > >> Best Regards, Ivan
> > >>
> > >
> > >
> > > --
> > > Best Regards, Ivan
> > >
> >
> >
> > --
> > Best Regards, Ivan
> >
>
>
> --
> Best regards,
> Andrey V. Mashenkov

Ability to comment Confluence pages of Ignite project

[Roman Puchkovskiy]

Hi Igniters!

I would like to contribute by commenting on Confluence pages (namely,
I would like to add some comments to
https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol
). Could you please provide me with the necessary permissions? My
login is 'rpuch'.

Roman Puchkovskiy

Re: Naming style for configuration properties defining durations in Ignite 3

[Roman Puchkovskiy]

It's an interesting idea. That would solve the problem for
configuration files (or other external representations of a
configuration, like JMX or whatnot). As for the Java API, we could
model durations with java.time.Duration instances, so it would be

/** Node join timeout. */
@Value(hasDefault = true)
public Duration joinTimeout = Duration.ofSeconds(5);

If the number of instances/allocations is a problem, we could apply
something like the Flyway pattern to cache the durations somewhere
inside configuration-related infrastructure code.

пн, 26 дек. 2022 г. в 21:12, Alexei Scherbakov :
>
> What about specifying dimensions in config, like
>
> joinTimeout=5s
>
> Internally it is always stored in millis.
>
>
> пт, 23 дек. 2022 г. в 11:53, Pavel Tupitsyn :
>
> > Agree with the proposal.
> > Those properties go into config files (json/hocon), and it is difficult to
> > navigate to relevant docs from there.
> >
> > I would go with point 3 - longer suffixes like Millis - to make it
> > unambiguous.
> >
> > On Fri, Dec 23, 2022 at 10:06 AM Roman Puchkovskiy <
> > roman.puchkovs...@gmail.com> wrote:
> >
> > > Hi Igniters!
> > >
> > > In Ignite 3, in configuration schemas, we have some properties that
> > > define durations/intervals (usually, these are timeout durations).
> > > Almost always they are defined without mentioning the duration unit,
> > > like this:
> > >
> > > /** Node join timeout. */
> > > @Value(hasDefault = true)
> > > public int joinTimeout = 5_000;
> > >
> > > This makes a user puzzled about the unit of measure: it might be
> > > milliseconds (as it often is), but who knows.
> > > It seems beneficial to include the unit of measure in names of such
> > > properties, like joinTimeoutMs or joinTimeoutMillis.
> > >
> > > We might try to solve this via documentation, but, when a property
> > > name speaks by itself, we don't need to reach for the documentation at
> > > all, so it still seems better to have it in a name (and, if you edit a
> > > config file, reaching for documentation might be a bit more
> > > time-consuming than navigating to a method javadoc in an IDE).
> > >
> > > We could do one of the following:
> > >
> > > 1. Do not change the naming schema, just improve the documentation; we
> > > might also establish a strong convention of always having all
> > > durations in the same unit (like milliseconds) [there is a
> > > disadvantage: if we add a property that is naturally measured in, say,
> > > hours, we would still have to use millis, which would make
> > > configuration very cumbersome with all these zeros]
> > > 2. Use short suffixes (ns/ms/sec/min/hr/days): joinTimeoutMs. There is
> > > a problem with microseconds if we ever need them (how do we abbreviate
> > > it according to this style?)
> > > 3. Use longer suffixes (nanos/micros/millis/secs/mins/hours/days):
> > > joinTimeoutMillis. A bit longer than the previous one.
> > > 4. ... or something else?
> > >
> > > What do you think?
> > >
> >
>
>
> --
>
> Best regards,
> Alexei Scherbakov

Naming style for configuration properties defining durations in Ignite 3

[Roman Puchkovskiy]

Hi Igniters!

In Ignite 3, in configuration schemas, we have some properties that
define durations/intervals (usually, these are timeout durations).
Almost always they are defined without mentioning the duration unit,
like this:

/** Node join timeout. */
@Value(hasDefault = true)
public int joinTimeout = 5_000;

This makes a user puzzled about the unit of measure: it might be
milliseconds (as it often is), but who knows.
It seems beneficial to include the unit of measure in names of such
properties, like joinTimeoutMs or joinTimeoutMillis.

We might try to solve this via documentation, but, when a property
name speaks by itself, we don't need to reach for the documentation at
all, so it still seems better to have it in a name (and, if you edit a
config file, reaching for documentation might be a bit more
time-consuming than navigating to a method javadoc in an IDE).

We could do one of the following:

1. Do not change the naming schema, just improve the documentation; we
might also establish a strong convention of always having all
durations in the same unit (like milliseconds) [there is a
disadvantage: if we add a property that is naturally measured in, say,
hours, we would still have to use millis, which would make
configuration very cumbersome with all these zeros]
2. Use short suffixes (ns/ms/sec/min/hr/days): joinTimeoutMs. There is
a problem with microseconds if we ever need them (how do we abbreviate
it according to this style?)
3. Use longer suffixes (nanos/micros/millis/secs/mins/hours/days):
joinTimeoutMillis. A bit longer than the previous one.
4. ... or something else?

What do you think?

Re: [DISCUSSION] IEP-91 Transaction protocol

[Roman Puchkovskiy]

Hi Alexei.

Great proposal, thank you for your efforts.

One thing that I noted is that the proposed IgniteInstructions
interface contains parameterless commit*() and rollback*() methods.
The transactions are not thread-bound, so there seems to be no
implicit mechanism for the global IgniteInstructions to know about the
current transaction, hence it looks like either these methods need to
belong to the Transaction interface, or that they need Transaction to
be passed as a parameter. Or, if there is still some other mechanism,
I missed it while reading.

пн, 26 сент. 2022 г. в 16:32, Alexei Scherbakov :
>
> Hello, igniters.
>
> After a long and hard work I've finally pushed the IEP
> 
> to
> the necessary detail level.
> Any useful feedback would be greatly appreciated.
>
> --
>
> Best regards,
> Alexei Scherbakov

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

[Roman Puchkovskiy]

Congratulations, Kirill!

пн, 10 окт. 2022 г. в 18:15, Pavel Tupitsyn :
>
> The Project Management Committee (PMC) for Apache Ignite
> has invited Kirill Tkalenko to become a committer and we are pleased
> to announce that they have accepted.
>
> Kirill is an active contributor and community member, he made significant
> additions to Ignite 2.x and 3.x code bases, WAL and PageMemory improvements
> among others.
>
> Being a committer enables easier contribution to the
> project since there is no need to go via the patch
> submission process. This should enable better productivity.
>
> Please join me in welcoming Kirill, and congratulating him on the new role
> in
> the Apache Ignite Community!
>
> Regards,
> Pavel Tupitsyn

Re: [DISCUSSION] IEP-93: Ignite Packaging

[Roman Puchkovskiy]

Hi Mikhail.

The suggestion looks great.

I have a nitpick. In 'ignite3-cli' and 'ignite3-db' sections, Linux
and Windows are explicitly mentioned, but MacOS is not. Does this mean
that MacOS will not be supported in these cases, or it's just
forgotten? Also, when it comes to scripts, could it be that the idea
was to have a Windows script and a Unix shell-compatible script (not
necessarily Linux)?

пт, 19 авг. 2022 г. в 17:15, Mikhail Pochatkin :
>
> Hi, Petr.
>
> So, after this discussion will close I also need to start the voting
> process to accept changes provided by this IEP. But, as I see not anyone
> provided some comments in the discussion and I think that the voting
> process should be fine. Currently, I am in the progress of Gradle build
> implementation (IGNITE-17485) and I think that it should be finished in a
> short time.
>
> On Fri, Aug 19, 2022 at 12:40 PM Petr Ivanov  wrote:
>
> > Hi, Mikhail!
> >
> >
> > The IEP looks great and there are a lot of work to be done.
> > I guess we are waiting now for the initial Gradle build implementation to
> > start applying changes on TC and further work for packaging?
> >
> > > On 15 Aug 2022, at 13:43, Mikhail Pochatkin 
> > wrote:
> > >
> > > Hello, Igniters.
> > >
> > > I'd like to start a discussion about Ignite Packaging for Apache Ignite
> > > 3[1]. The main purpose of these changes is related to improving Apache
> > > Ignite 3 distribution process.
> > >
> > > [1]
> > >
> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-93%3A+Ignite+Packaging
> >
> >

Re: [ANNOUNCE] New PMC member: Vyacheslav Koptilin

[Roman Puchkovskiy]

Congratulations, Slava!

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

Re: [DISCUSSION] IEP-88: CLI Tool

[Roman Puchkovskiy]

Aleksandr,

The thing is that `cluster init` is not just for setting some kind of
a configuration, it's more about doing cluster initialization
described in [1]. This init process transitions the cluster from
'empty' state to 'initialized state'; this can be only made once per
cluster, and it has to be done for the cluster to function.

So I'd suggest to remove the mentioning of 'configuration' at all;
also, `--cluster-url` and `--configuration-file` are not the
parameters that are currently implemented; it's actually (currently)
taking `--node-endpoint`, `--meta-storage-node` (1+ occurrences) and
`--cmg-node` (0+ occurrences) parameters.

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-77%3A+Node+Join+Protocol+and+Initialization

пт, 27 мая 2022 г. в 13:04, Aleksandr Pakhomov :
>
> Hi Roman,
>
> That is a good point. In the proposal I mean
> the analogue for existing ‘cluster init’. Maybe
> “distributed configuration” confuses you and
> probably I have to name it like “meta-storage”
> configuration or something like this.
>
> As for 'ignite init’  I think it would be more clearer
> if we rename it to ‘ignite install’ and there won’t
> any confusion at all.
>
> What do you think?
>
> > On 27 May 2022, at 10:20, Roman Puchkovskiy  
> > wrote:
> >
> > Hi Aleksandr.
> >
> > There is a command named 'init' in your proposal. According to its
> > description, it initializes the cluster with a distributed
> > configuration. I'm not sure how it's mapped to the existing commands.
> > The thing is that currently, there is `ignite init` command that
> > initializes (actually, installs) Ignite on the current machine (its
> > description does not mention distributed configuration), and there is
> > also `ignite cluster init` that initializes the cluster (see [1], for
> > example), which does not concern distributed configuration as well.
> >
> > So it looks like the 2 existing commands got dropped and replaced with
> > another 'init' command relating to the distributed config.
> >
> > Was it intentional?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-14871
> >
> > ср, 25 мая 2022 г. в 18:12, Andrey Gura :
> >>
> >> Aleksandr,
> >>
> >> Both proposed options look good to me because both cases assume that a
> >> user must express their intent explicitly.
> >>
> >> On Thu, May 19, 2022 at 10:53 AM Aleksandr Pakhomov  
> >> wrote:
> >>>
> >>> I got it. What do you think about this proposal:
> >>>
> >>> -  “ignite”  prints help
> >>> -  “ignite shell” enters REPL
> >>>
> >>> Or
> >>>
> >>> -  “ignite” prints help
> >>> -  “ignite-shell” enters REPL and it is a separate application
> >>>
> >>> I prefer the first varian but I would like to hear opinions of other 
> >>> community members.
> >>>
> >>>
> >>>> On 19 May 2022, at 01:16, Andrey Gura  wrote:
> >>>>
> >>>> I can just have a mistake in my script, e.g. running ignite command
> >>>> without any parameters. What will happen in such a case from the
> >>>> script perspective? I think the script will wait for returning value
> >>>> while the shell will wait for a user input. Due to a server-side
> >>>> nature of the script it will hang forever because there is no user on
> >>>> the server side.
> >>>
>

Re: [DISCUSSION] IEP-88: CLI Tool

[Roman Puchkovskiy]

Hi Aleksandr.

There is a command named 'init' in your proposal. According to its
description, it initializes the cluster with a distributed
configuration. I'm not sure how it's mapped to the existing commands.
The thing is that currently, there is `ignite init` command that
initializes (actually, installs) Ignite on the current machine (its
description does not mention distributed configuration), and there is
also `ignite cluster init` that initializes the cluster (see [1], for
example), which does not concern distributed configuration as well.

So it looks like the 2 existing commands got dropped and replaced with
another 'init' command relating to the distributed config.

Was it intentional?

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

ср, 25 мая 2022 г. в 18:12, Andrey Gura :
>
> Aleksandr,
>
> Both proposed options look good to me because both cases assume that a
> user must express their intent explicitly.
>
> On Thu, May 19, 2022 at 10:53 AM Aleksandr Pakhomov  wrote:
> >
> > I got it. What do you think about this proposal:
> >
> > -  “ignite”  prints help
> > -  “ignite shell” enters REPL
> >
> > Or
> >
> > -  “ignite” prints help
> > -  “ignite-shell” enters REPL and it is a separate application
> >
> > I prefer the first varian but I would like to hear opinions of other 
> > community members.
> >
> >
> > > On 19 May 2022, at 01:16, Andrey Gura  wrote:
> > >
> > > I can just have a mistake in my script, e.g. running ignite command
> > > without any parameters. What will happen in such a case from the
> > > script perspective? I think the script will wait for returning value
> > > while the shell will wait for a user input. Due to a server-side
> > > nature of the script it will hang forever because there is no user on
> > > the server side.
> >

Re: [DISCUSSION] IEP-89: PITR

[Roman Puchkovskiy]

Hi Maksim.

Do I understand correctly that 'consistent cut start' message always
contains IDs of transactions to include, while 'consistent cut finish'
message always contains IDs of transactions to exclude from the
consistent cut? (At least, this is the impression I got from the
example of parsing the WAL and the accompanying figure). If this is
the case, then it looks like the `include` and `check` fields are
mutually exclusive in ConsistentCutRecord. Would it make sense to
replace it with two classes, like ConsistentCutStartRecord(cutVer,
include) and ConsistentCutFinishRecord(cutVer, exclude)?

Also, it seems that it could be beneficial to have a separate section
explaining when the corresponding records are written to WAL, to make
this information easier to find. Or, maybe, this could be added to the
current 'WAL records' section.

пн, 16 мая 2022 г. в 12:52, Maksim Timonin :
>
> Dear Igniters,
>
> I just published IEP-89 [1] that proposes a new feature to Ignite - (point
> in time recovery) PITR. I propose to implement the Consistent Cut algorithm
> for this, actually I achieved a working PoC for Ignite. And based on my
> research I wrote this IEP.
>
> Let's start a discussion here. Any questions or comments are welcomed.
>
> Thanks!
>
>
> [1]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=211884314

Re: [DISCUSSION] IEP-87: Open API support for REST

[Roman Puchkovskiy]

Oops, sent it too early :) I'll proceed.

... As a side note, as far as I know, there were some discussions
about using automatic dependency injection in Ignite 3 (as the whole
system), but no decision was made.

3. In the table in the API section, there is this phrase: 'Update node
configuration with a given body.'. I suggest replacing 'Update' with
'Patch' because 'update' could mean a full replacement, and 'patch'
makes it more specific. Same relates to 'Update cluster configuration
with a given body.'.

чт, 19 мая 2022 г. в 11:12, Roman Puchkovskiy :
>
> Hi Aleksandr.
>
> Thank you for your effort, it looks interesting. I have a few
> comments/questions on some little details.
>
> 1. About the paragraph named 'Versioning'. Could you please elaborate
> what is the difference between 'API version' and 'specification
> version'? Both might have 'breaking changes', what does it mean in
> each of the cases?
>
> 2. If I'm not mistaken, at runtime, Micronaut maintains an application
> context containing beans, these beans can be injected into other beans
> and components (like controllers). In your example code, RestComponent
> receives a RestConfiguration instance via constructor. Is the
> RestConfiguration instance injected automatically by the Micronaut IoC
> container? Is the IoC injection going to be used at all? If yes, given
> that currently Ignite 3 uses no such automagic injection, then what
> are the planned/supposed bounds of the area which would use automatic
> injection and how will we build the 'border' between auto-injecting
> and non-auto-injecting code? (For instance, how our RestConfiguration
> will be registered with the Micronaut context?)
> As a sidenote
>
> чт, 12 мая 2022 г. в 23:22, Aleksandr Pakhomov :
> >
> > Hi, Andrey.
> >
> > Thank you for your comments.
> >
> > I've put the main value to the description and added "artifact management" 
> > part [1].
> > Yes, you are right. I've adjusted the IEP.
> >3, 4, 5. Done.
> >
> > [1] 
> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Artifactmanagement
> >  
> > <https://cwiki.apache.org/confluence/display/IGNITE/IEP-87:+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Artifactmanagement>
> >
> >
> > > On 11 May 2022, at 16:46, Andrey Gura  wrote:
> > >
> > > Hi,
> > >
> > > I took a look at the proposal and have some questions and comments.
> > >
> > > 1. It is not clear what the main value of this proposal is. The
> > > current implementation of REST is code-first. API specification could
> > > be written manually. It seems that the main value is the possibility
> > > to generate an API specification from code. If so, then it would be
> > > great to point it out strongly. Otherwise, this proposal looks like an
> > > attempt to replace one implementation by another one (may be more
> > > popular) but with additional 3rd party dependencies. Also, it would be
> > > great to propose a process of artefact management (what should we do
> > > and when) in relation to specification (Where it should be published?
> > > Should it be placed in a source code repository or not? Should we do
> > > some version management?)
> > >
> > > 2. The "Modular architecture support" part says: "Ignite modules can
> > > provide endpoints that will be included into the netty server by
> > > RestComponent **at the build time**". If I understood correctly, we
> > > talk only about endpoints here, but registration/deregistration of
> > > handlers for known endpoints could be done at runtime. Am I right?
> > >
> > > 3. The "API" part refers to the meta storage nodes and CMG nodes.
> > > Could you please refer to a document which introduces these concepts?
> > >
> > > 4. Also it would be great to state that the proposed API actually is
> > > the current API which exists in Apache Ignite.
> > >
> > > 5. The task about developer documentation should be added to the
> > > issues list. The documentation is a readme.md file which will help an
> > > Ignite developer to understand how to add a new endpoint, how to
> > > generate API specification, etc.
> > >
> > > On Wed, May 11, 2022 at 11:17 AM Aleksandr Pakhomov  
> > > wrote:
> > >>
> > >> Hello, Igniters.
> > >>
> > >> I’d like to start a discussion about Open API support for REST [1]. The 
> > >> main purpose of this improvement is to add the support of Open API 
> > >> specification by generating it from the source code.
> > >>
> > >> [1] 
> > >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST
> >

Re: [DISCUSSION] IEP-87: Open API support for REST

[Roman Puchkovskiy]

Hi Aleksandr.

Thank you for your effort, it looks interesting. I have a few
comments/questions on some little details.

1. About the paragraph named 'Versioning'. Could you please elaborate
what is the difference between 'API version' and 'specification
version'? Both might have 'breaking changes', what does it mean in
each of the cases?

2. If I'm not mistaken, at runtime, Micronaut maintains an application
context containing beans, these beans can be injected into other beans
and components (like controllers). In your example code, RestComponent
receives a RestConfiguration instance via constructor. Is the
RestConfiguration instance injected automatically by the Micronaut IoC
container? Is the IoC injection going to be used at all? If yes, given
that currently Ignite 3 uses no such automagic injection, then what
are the planned/supposed bounds of the area which would use automatic
injection and how will we build the 'border' between auto-injecting
and non-auto-injecting code? (For instance, how our RestConfiguration
will be registered with the Micronaut context?)
As a sidenote

чт, 12 мая 2022 г. в 23:22, Aleksandr Pakhomov :
>
> Hi, Andrey.
>
> Thank you for your comments.
>
> I've put the main value to the description and added "artifact management" 
> part [1].
> Yes, you are right. I've adjusted the IEP.
>3, 4, 5. Done.
>
> [1] 
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Artifactmanagement
>  
> 
>
>
> > On 11 May 2022, at 16:46, Andrey Gura  wrote:
> >
> > Hi,
> >
> > I took a look at the proposal and have some questions and comments.
> >
> > 1. It is not clear what the main value of this proposal is. The
> > current implementation of REST is code-first. API specification could
> > be written manually. It seems that the main value is the possibility
> > to generate an API specification from code. If so, then it would be
> > great to point it out strongly. Otherwise, this proposal looks like an
> > attempt to replace one implementation by another one (may be more
> > popular) but with additional 3rd party dependencies. Also, it would be
> > great to propose a process of artefact management (what should we do
> > and when) in relation to specification (Where it should be published?
> > Should it be placed in a source code repository or not? Should we do
> > some version management?)
> >
> > 2. The "Modular architecture support" part says: "Ignite modules can
> > provide endpoints that will be included into the netty server by
> > RestComponent **at the build time**". If I understood correctly, we
> > talk only about endpoints here, but registration/deregistration of
> > handlers for known endpoints could be done at runtime. Am I right?
> >
> > 3. The "API" part refers to the meta storage nodes and CMG nodes.
> > Could you please refer to a document which introduces these concepts?
> >
> > 4. Also it would be great to state that the proposed API actually is
> > the current API which exists in Apache Ignite.
> >
> > 5. The task about developer documentation should be added to the
> > issues list. The documentation is a readme.md file which will help an
> > Ignite developer to understand how to add a new endpoint, how to
> > generate API specification, etc.
> >
> > On Wed, May 11, 2022 at 11:17 AM Aleksandr Pakhomov  
> > wrote:
> >>
> >> Hello, Igniters.
> >>
> >> I’d like to start a discussion about Open API support for REST [1]. The 
> >> main purpose of this improvement is to add the support of Open API 
> >> specification by generating it from the source code.
> >>
> >> [1] 
> >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST
>

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

[Roman Puchkovskiy]

Hi Nikita.

You already know this, just stating for the record: vulnerable Spring
versions in ignite-extensions were replaced with the latest patched
(and safe) versions in [1].

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

пн, 18 апр. 2022 г. в 18:11, Nikita Amelchev :
>
> Hi, Roman.
>
> Vulnerable Spring Boot is used in Ignite extensions. AI 2.13 releases
> ignite-parent that will be used for extensions to share versions. I
> will cherry-pick the patch.
>
> Thank you.
>
> пн, 18 апр. 2022 г. в 15:00, Roman Puchkovskiy :
> >
> > Hi Igniters.
> >
> > A fix for CVE-2022-22965 [1] vulnerability was merged to master branch
> > recently, Jira issue is [2].
> > I'm not sure whether this is a blocker, but the vulnerability seems to
> > be pretty bad.
> >
> > Should it be cherry-picked to release 2.13?
> >
> > [1] - https://nvd.nist.gov/vuln/detail/CVE-2022-22965
> > [2] - https://issues.apache.org/jira/browse/IGNITE-16781
> >
> > пн, 11 апр. 2022 г. в 19:53, Nikita Amelchev :
> > >
> > > I'm announcing a code freeze for the 2.13 release [1]. Only blockers
> > > are accepted to be included to the scope.
> > >
> > > [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.13
> > >
> > > пн, 28 мар. 2022 г. в 12:39, Nikita Amelchev :
> > > >
> > > > Guys,
> > > >
> > > > Could you help with the TC bot configuration to the `ignite-2.13`
> > > > release branch?
> > > >
> > > > пн, 28 мар. 2022 г. в 09:22, Zhenya Stanilovsky 
> > > > :
> > > >
> > > > >
> > > > >
> > > > > Thanks Nikita, cherry-picked: IGNITE-16742 Extend calcite module 
> > > > > documentation.
> > > > >
> > > > >
> > > > >
> > > > > >Igniters,
> > > > > >
> > > > > >I have cut the release branch: 'ignite-2.13'. Please, cherry-pick new
> > > > > >issues if needed.
> > > > > >
> > > > > >The 2.13 scope is freezed. Unresolved not-blocking issues will be
> > > > > >moved on the code freeze stage. The planning release date was updated
> > > > > >[1]:
> > > > > >
> > > > > >Scope Freeze: March 25, 2022
> > > > > >Code Freeze: April 8, 2022
> > > > > >Voting Date: April 15, 2022
> > > > > >Release Date: April 22, 2022
> > > > > >
> > > > > >[1]  
> > > > > >https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.13
> > > > > >
> > > > > >чт, 10 мар. 2022 г. в 16:17, Nikita Amelchev < namelc...@apache.org 
> > > > > >>:
> > > > > >>
> > > > > >> Hello, Igniters.
> > > > > >>
> > > > > >> I have created the 2.13 release page. [1]
> > > > > >>
> > > > > >> The new SQL Calcite engine is expected to merge in the coming week.
> > > > > >> [2] I suggest cutting the 2.13 branch after the merge. I've updated
> > > > > >> the planned release dates on the release page.
> > > > > >>
> > > > > >> [1]  
> > > > > >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.13
> > > > > >> [2]  
> > > > > >> https://lists.apache.org/thread/3fkq3mn2npz326bp6gjtw3sw8xrlqyho
> > > > > >>
> > > > > >> чт, 10 февр. 2022 г. в 15:23, Nikita Amelchev < 
> > > > > >> namelc...@apache.org >:
> > > > > >> >
> > > > > >> > Guys,
> > > > > >> >
> > > > > >> > +1 to await merge of the Calcite SQL engine before code-freeze 
> > > > > >> > phase
> > > > > >> > and release branch cutting. Other features and fixes can be 
> > > > > >> > awaited
> > > > > >> > too, it's discussable.
> > > > > >> >
> > > > > >> > But the 2.12 branch was cut on October 15, 2021. There are many 
> > > > > >> > fixes
> > > > > >> > and features that were merged into the master during this 
> > > > > >> > period. The
> > > > > >> > total time between branches cut is 

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

[Roman Puchkovskiy]

I've created a PR [1] that implements the above mentioned changes
(also described in [2]).
I triggered a build on TeamCity, here is the result: [3]. Two test
tasks failed, both due to the removal of ignite-spring-data-2.0-ext
and ignite-spring-data-2.2-ext (which was renamed to just
ignite-spring-data-ext), so the changed code seems to work from the
'point of view' of the tests.

Could you please take a look at the PR?

[1] - https://github.com/apache/ignite-extensions/pull/120
[2] - https://issues.apache.org/jira/browse/IGNITE-16869
[3] - 
https://ci.ignite.apache.org/viewLog.html?buildId=6533271=buildResultsDiv=IgniteExtensions_Tests_RunAllTests

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

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

[Roman Puchkovskiy]

Hi Igniters.

A fix for CVE-2022-22965 [1] vulnerability was merged to master branch
recently, Jira issue is [2].
I'm not sure whether this is a blocker, but the vulnerability seems to
be pretty bad.

Should it be cherry-picked to release 2.13?

[1] - https://nvd.nist.gov/vuln/detail/CVE-2022-22965
[2] - https://issues.apache.org/jira/browse/IGNITE-16781

пн, 11 апр. 2022 г. в 19:53, Nikita Amelchev :
>
> I'm announcing a code freeze for the 2.13 release [1]. Only blockers
> are accepted to be included to the scope.
>
> [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.13
>
> пн, 28 мар. 2022 г. в 12:39, Nikita Amelchev :
> >
> > Guys,
> >
> > Could you help with the TC bot configuration to the `ignite-2.13`
> > release branch?
> >
> > пн, 28 мар. 2022 г. в 09:22, Zhenya Stanilovsky 
> > :
> >
> > >
> > >
> > > Thanks Nikita, cherry-picked: IGNITE-16742 Extend calcite module 
> > > documentation.
> > >
> > >
> > >
> > > >Igniters,
> > > >
> > > >I have cut the release branch: 'ignite-2.13'. Please, cherry-pick new
> > > >issues if needed.
> > > >
> > > >The 2.13 scope is freezed. Unresolved not-blocking issues will be
> > > >moved on the code freeze stage. The planning release date was updated
> > > >[1]:
> > > >
> > > >Scope Freeze: March 25, 2022
> > > >Code Freeze: April 8, 2022
> > > >Voting Date: April 15, 2022
> > > >Release Date: April 22, 2022
> > > >
> > > >[1]  
> > > >https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.13
> > > >
> > > >чт, 10 мар. 2022 г. в 16:17, Nikita Amelchev < namelc...@apache.org >:
> > > >>
> > > >> Hello, Igniters.
> > > >>
> > > >> I have created the 2.13 release page. [1]
> > > >>
> > > >> The new SQL Calcite engine is expected to merge in the coming week.
> > > >> [2] I suggest cutting the 2.13 branch after the merge. I've updated
> > > >> the planned release dates on the release page.
> > > >>
> > > >> [1]  
> > > >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.13
> > > >> [2]  https://lists.apache.org/thread/3fkq3mn2npz326bp6gjtw3sw8xrlqyho
> > > >>
> > > >> чт, 10 февр. 2022 г. в 15:23, Nikita Amelchev < namelc...@apache.org >:
> > > >> >
> > > >> > Guys,
> > > >> >
> > > >> > +1 to await merge of the Calcite SQL engine before code-freeze phase
> > > >> > and release branch cutting. Other features and fixes can be awaited
> > > >> > too, it's discussable.
> > > >> >
> > > >> > But the 2.12 branch was cut on October 15, 2021. There are many fixes
> > > >> > and features that were merged into the master during this period. The
> > > >> > total time between branches cut is 5 months (if there is no delay
> > > >> > happens). Seems it is not so frequently.
> > > >> >
> > > >> > чт, 10 февр. 2022 г. в 15:17, Zhenya Stanilovsky < 
> > > >> > arzamas...@mail.ru.invalid >:
> > > >> > >
> > > >> > >
> > > >> > > Maxim, i think that more frequent releases are useful.
> > > >> > > Ready to release branch means that it passed all known tests and 
> > > >> > > also have an appropriate votes.
> > > >> > > More code changes creates more difficulties in final tests and 
> > > >> > > sometimes migration.
> > > >> > > No need to switch between neighbor minor versions for user if all 
> > > >> > > work properly well.
> > > >> > > I «vote» for more frequent releases.
> > > >> > >
> > > >> > > >
> > > >> > > >>
> > > >> > > >>>Hi, guys!
> > > >> > > >>>
> > > >> > > >>>Ignite 2.12 was released on 17th Jan. And here is a plan to 
> > > >> > > >>>release 2.13 on
> > > >> > > >>>28 Mar. It is only 2.5 months between those versions. IMHO, 
> > > >> > > >>>it's better to
> > > >> > > >>>have more time between releases:
> > > >> > > >>>1. We had some bug reports after releasing 2.11, and it can be 
> > > >> > > >>>worth
> > > >> > > >>>waiting for users feedback about 2.12. Also meetup with 
> > > >> > > >>>description of 2.12
> > > >> > > >>>will be only next week (16 Feb).
> > > >> > > >>>2. In my understanding, users don't switch between versions of 
> > > >> > > >>>databases
> > > >> > > >>>frequently. Actually it's hard work to upgrade such a 
> > > >> > > >>>dependency. So, no
> > > >> > > >>>need for continuous delivery here. I think it's a common 
> > > >> > > >>>practice, for
> > > >> > > >>>example, MongoDB releases 1 time per year, Cassandra 2 times. 
> > > >> > > >>>CockroachDB
> > > >> > > >>>releases minor versions every month, but major versions are 
> > > >> > > >>>still released
> > > >> > > >>>2 times a year. But I'm not aware of all databases.
> > > >> > > >>>
> > > >> > > >>>I think we should move dates for at least 1 month. Also it 
> > > >> > > >>>depends on the
> > > >> > > >>>Calcite engine readiness. WDYT?
> > > >> > > >>>
> > > >> > > >>>Anyway, from my side there are some tickets I want to include 
> > > >> > > >>>to the next
> > > >> > > >>>release scope:
> > > >> > > >>>1. Partition reservation for cache queries (it will make 
> > > >> > > >>>IndexQuery work on
> > > >> > > >>>unstable topology): 

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

[Roman Puchkovskiy]

Hi guys.

This thread has been hanging for quite some time (no pun intended).
While it was hanging, CVE-2022-22965 [1] was discovered which makes it
extremely dangerous to have vulnerable versions of Spring as
dependencies.

As discussed, ignite-extensions has 3 versions of spring-data
integrations (against versions 1.0, 2.0, 2.2 of spring-data), namely
ignite-spring-data, ignite-spring-data_2.0, ignite-spring-data_2.2.
They use Spring versions 4.3.x, 5.0.x, 5.2.x, respectively. Of them,
only 5.2 branch is still supported and got a fix for CVE-2022-22965.

My suggestion is to implement what was suggested earlier in this thread:

1. Remove ignite-spring-data and ignite-spring-data_2.0
2. Update ignite-spring-data_2.2 module to depend on the latest Spring
version in branch 5.2 (it's currently 5.2.21)
3. Probably also rename ignite-spring-data_2.2 extension to
ignite-spring-data (dropping the version postfix).

I created a Jira ticket [2].

Later, in a separate ticket (with no rush due to the urgency of the
matter), we could update the integration to work with the most recent
spring-data version.

What are your thoughts?

[1] - https://nvd.nist.gov/vuln/detail/CVE-2022-22965
[2] - https://issues.apache.org/jira/browse/IGNITE-16869

пт, 18 февр. 2022 г. в 20:58, Maksim Timonin :
>
> > My proposal is not about creating a separate repository for the spring-data
> extension - just left a single module
>
> Yeah, you're correct. I mean that we need a single point of truth for
> spring-data - single repository or single module. I'm +1 here.
>
> > So creating some branches to store obsolete code for a module seems a bit
> confusing
>
> IMHO, we should have an opportunity to release a hot fix asap for those
> modules in case of critical CVE, particularly if it is impossible to just
> make an upgrade from 2.0 to 2.2 or to the latest version due to backward
> compatibility.
>
> WDYT?
>
> On Fri, Feb 18, 2022 at 2:12 PM Mikhail Petrov 
> wrote:
>
> > Maksim,
> >
> > Currently, we have a single repository where all extensions are stored
> > as separate modules - [1]
> > My proposal is not about creating a separate repository for the
> > spring-data extension - just left a single module for the spring-data
> > extension and proceed with its developments the same way as for other
> > extensions - [2].
> > So creating some branches to store obsolete code for a module seems a
> > bit confusing.
> >
> >
> > One of the goals of this refactoring is to create the Spring Data
> > integration extension that will be independent of the version of Spring
> > Data.
> > (as it is already done for Spring Cache or Spring Transactions
> > integrations). It must be updated and re-released only in case of broken
> > backward compatibility between Spring Data versions or if the extension
> > itself is updated. This process is described in the thread - [2].
> >
> >
> > [1] - https://github.com/apache/ignite-extensions/tree/master/modules
> > [2] - https://lists.apache.org/thread/wox65gp3fyjkx048205t9omm418o3f20
> >
> > On 18.02.2022 13:13, Maksim Timonin wrote:
> > > Hi Mikhail,
> > >
> > >> remove extension modules that are tied to the specific Spring Data
> > versions
> > > - keep only a single spring-data-ext module. For now, it will contain
> > code
> > > for the latest Ignite Spring Data integration -
> > ignite-spring-data-2.2-ext.
> > >
> > > I'm +1 for having a single repository for the spring-data extensions.
> > But I
> > > think we must not completely remove code for 2.0, 2.1 versions. I'd
> > propose
> > > to create separated branches in the repository for those versions, and
> > put
> > > tags for already released versions.
> > >
> > >> According to [5] 1.0 and 2.0 versions are no longer supported
> > > According to this 2.2 isn't supported too, the last release was a year
> > ago,
> > > is it? Do we have plans to support spring-data with the latest version?
> > >
> > > On Fri, Feb 18, 2022 at 10:57 AM Mikhail Petrov 
> > > wrote:
> > >
> > >> Igniters,
> > >>Currently, we have three separate modules for Ignite Spring Data
> > >> integrations - [1 - 3]. Each of them depends on the specific version of
> > >> the Spring Data - 1.0, 2.0, and 2.2, respectively.
> > >>
> > >>I propose to:
> > >>1. remove extension modules that are tied to the specific Spring Data
> > >> versions - keep only a single spring-data-ext module. For now, it will
> > >> contain code for the latest Ignite Spring Data integration -
> > >> ignite-spring-data-2.2-ext.
> > >>2. Proceed with spring-data integration future releases as were
> > >> discussed here - [6].
> > >>
> > >>Motivation:
> > >>1. Almost all bug fixes or improvements for the Spring Data
> > >> integration are copied multiple times for each module
> > >>2. According to [5] 1.0 and 2.0 versions are no longer supported and
> > >> since the corresponding integrations were already released, we can
> > >> remove them safely.
> > >>3. Some patches already neglect 

Re: [VOTE] @Nullable/@NotNull annotation usage in Ignite 3

[Roman Puchkovskiy]

+1 to option 2

чт, 13 янв. 2022 г. в 15:58, Sergey :
>
> +1 for option2 (only @Nullable)
>
> Best regards,
> Sergey Kosarev.
>
>
> чт, 13 янв. 2022 г. в 13:25, Alexander Polovtcev :
>
> > Dear Igniters,
> >
> > In this thread
> >  we've
> > discussed possible approaches to using null-related annotations. As the
> > result, the following approaches were proposed:
> >
> >1. Use both @Nullable and @NotNull annotations everywhere;
> >2. Use only @Nullable;
> >3. Use only @NotNull;
> >4. Do not use* @*Nullable nor @NotNull.
> >
> > I would like to propose a vote: please post the corresponding number of the
> > option you like. The voting will commence on Thursday, January 20 at 11:00
> > UTC.
> >
> > --
> > With regards,
> > Aleksandr Polovtcev
> >

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

[Roman Puchkovskiy]

Semyon, well done and congratulations!

ср, 1 дек. 2021 г. в 15:Congrats and well done!

ср, 1 дек. 2021 г. в 15:56, Kseniya Romanova :
>
> Semyon, congrats!
>
> ср, 1 дек. 2021 г. в 12:51, Andrey Gura :
>
> > I'm sorry for the mistake. Of course please join me in welcoming
> > **Semyon**, and congratulating him on the new role in
> > the Apache Ignite Community.
> >
> > On Wed, Dec 1, 2021 at 8:51 AM Zhenya Stanilovsky
> >  wrote:
> > >
> > >
> > > Wellcome Semyon !
> > > Andrey what`s Ivan are you talking at the end of the message or this is
> > some kind of phraseologism that all russians are ivans ?:)
> > >
> > > >Igniters,
> > > >
> > > >The Apache Ignite Project Management Committee (PMC) has invited
> > > >Semyon Danilov to become a new committer and are happy to announce
> > > >that he
> > > >has accepted.
> > > >
> > > >Semyon contributes actively to the project's code base (AI 2 & 3) and
> > > >helps a lot with the development environment set up (you know, all
> > > >this Maven and plugins related issues).
> > > >
> > > >Being a committer enables easier contribution to the project since
> > there is
> > > >no need to go via the patch submission process. This should enable
> > better
> > > >productivity.
> > > >
> > > >Please join me in welcoming Ivan, and congratulating him on the new
> > role in
> > > >the Apache Ignite Community.
> > > >
> > > >Best Regards,
> > > >Andrey Gura
> > >
> > >
> > >
> > >
> >56, Kseniya Romanova :
>
> Semyon, congrats!
>
> ср, 1 дек. 2021 г. в 12:51, Andrey Gura :
>
> > I'm sorry for the mistake. Of course please join me in welcoming
> > **Semyon**, and congratulating him on the new role in
> > the Apache Ignite Community.
> >
> > On Wed, Dec 1, 2021 at 8:51 AM Zhenya Stanilovsky
> >  wrote:
> > >Congrats and well done!

ср, 1 дек. 2021 г. в 15:56, Kseniya Romanova :
>
> Semyon, congrats!
>
> ср, 1 дек. 2021 г. в 12:51, Andrey Gura :
>
> > I'm sorry for the mistake. Of course please join me in welcoming
> > **Semyon**, and congratulating him on the new role in
> > the Apache Ignite Community.
> >
> > On Wed, Dec 1, 2021 at 8:51 AM Zhenya Stanilovsky
> >  wrote:
> > >
> > >
> > > Wellcome Semyon !
> > > Andrey what`s Ivan are you talking at the end of the message or this is
> > some kind of phraseologism that all russians are ivans ?:)
> > >
> > > >Igniters,
> > > >
> > > >The Apache Ignite Project Management Committee (PMC) has invited
> > > >Semyon Danilov to become a new committer and are happy to announce
> > > >that he
> > > >has accepted.
> > > >
> > > >Semyon contributes actively to the project's code base (AI 2 & 3) and
> > > >helps a lot with the development environment set up (you know, all
> > > >this Maven and plugins related issues).
> > > >
> > > >Being a committer enables easier contribution to the project since
> > there is
> > > >no need to go via the patch submission process. This should enable
> > better
> > > >productivity.
> > > >
> > > >Please join me in welcoming Ivan, and congratulating him on the new
> > role in
> > > >the Apache Ignite Community.
> > > >
> > > >Best Regards,
> > > >Andrey Gura
> > >
> > >
> > >
> > >
> >
> > >
> > > Wellcome Semyon !
> > > Andrey what`s Ivan are you talking at the end of the message or this is
> > some kind of phraseologism that all russians are ivans ?:)
> > >
> > > >Igniters,
> > > >
> > > >The Apache Ignite Project Management Committee (PMC) has invited
> > > >Semyon Danilov to become a new committer and are happy to announce
> > > >that he
> > > >has accepted.
> > > >
> > > >Semyon contributes actively to the project's code base (AI 2 & 3) and
> > > >helps a lot with the development environment set up (you know, all
> > > >this Maven and plugins related issues).
> > > >
> > > >Being a committer enables easier contribution to the project since
> > there is
> > > >no need to go via the patch submission process. This should enable
> > better
> > > >productivity.
> > > >
> > > >Please join me in welcoming Ivan, and congratulating him on the new
> > role in
> > > >the Apache Ignite Community.
> > > >
> > > >Best Regards,
> > > >Andrey Gura
> > >
> > >
> > >
> > >
> >

Request for contributor permission

[Roman Puchkovskiy]

Hello Ignite community!

My name is Roman Puchkovskiy. I would like to contribute to Apache
Ignite. My Apache JIRA username is rpuch.
Could you please provide me with the corresponding permission?

Roman Puchkovskiy