Re: [DISCUSS] Ignite 3.0 development approach

[Nikolay Izhikov]

Hello, Valentin.

> Nikolay, Maxim, are you OK with this route?

-1 to have another repo for Ignite3 development.

> 13 нояб. 2020 г., в 03:04, Valentin Kulichenko 
>  написал(а):
> 
> Folks,
> 
> We already have multiple IEPs for Ignite 3.0, and as far as I know, there are 
> contributors that would like to work on them (or probably already started). 
> That said, we should make a decision as soon as possible.
> 
> At this point, it doesn't seem that there are any strong objections to the 
> technical side of things. So I would suggest the following:
> 
> 1. Proceed with Alexey's approach to the development process, as it seems to 
> be the best (in my opinion - the only) way to address all the technical 
> concerns and issues expressed in the thread. We'll start by creating a new 
> repo and a new TC project.
> 2. Start a separate discussion around transparency. If there are any changes 
> we need to make to our contributor guidelines, I am happy to talk them 
> through, but I don't think it's reasonable to delay feature development 
> because of this. In the short term, I will make sure that everything that 
> happens within the new repo is as open to the community as possible.
> 
> Nikolay, Maxim, are you OK with this route?
> 
> -Val
> 
> On Tue, Nov 10, 2020 at 4:55 PM Valentin Kulichenko 
>  wrote:
> Maxim,
> 
> 2.x and 3.x will have to coexist for some time - I don't see how we can avoid 
> this considering the set of proposed changes. That said, we effectively will 
> need to have two "masters" - one for each major version. Master for 3.x can 
> technically be a branch in the existing repo, but having a separate repo 
> seems cleaner, simply because it will not be a "branch" in the traditional 
> sense.
> 
> Note that the new repo will still be under the Apache org, with the same set 
> of committers, managed by the community, etc. All the development happening 
> for 3.0 must follow the rules that we currently have (if anything, it's an 
> opportunity to improve those rules).
> 
> As I said during the call on Friday, I strongly believe that if there is a 
> transparency issue, it will exist regardless of the approach we choose for 
> 3.0. If community members develop without IEPs or public discussions, this 
> will happen for both 2.x and 3.x unless we address this separately. I don't 
> see how this is related to Alexey's suggestion, which targets *technical* 
> issues with the product more than anything else. This a way to achieve better 
> modularity, introduce better coverage with unit tests, reduce conflicts 
> during development, etc.
> 
> Coming back to transparency, let's identify the issues and fix them. It 
> probably makes sense to have a separate discussion on this topic.
> 
> -Val
> 
> On Tue, Nov 10, 2020 at 1:05 PM Maxim Muzafarov  wrote:
>  Sergey,
> 
> 
> Your summary makes sense to me.
> 
> However, how we come up from *Development transparency* to *create a
> separate public repository dedicated for 3.0*? For me *development
> transparency* is about making changes in the master branch. These
> changes will definitely be seen by all the Ignite developers.
> 
> A dedicated public repository is technically public and visible for
> everyone, but it allows development without IEPs, without public
> discussion (since all the code changes are not related to the master
> branch) it also allows a large number of assumptions and deviations
> (like code-style violations). It also not about *development
> transparency* since developers which are working on 3.0 is only a
> subset of all Ignite developers which may continue working on 2.x. For
> me, this would be a huge step backwards.
> 
> Ignite veterans should remember how long the branch stabilization took
> for the 2.x version with the PDS.
> 
> 
> I think each breaking change should be passed through the master branch.
> 
> On Tue, 10 Nov 2020 at 22:18, Alexei Scherbakov
>  wrote:
> >
> > Makes sense to me.
> >
> > вт, 10 нояб. 2020 г. в 18:47, Sergey Chugunov :
> >
> > > Igniters,
> > >
> > > I thought over Friday meeting ideas and concerns and summarized them in
> > > these three points:
> > >
> > >
> > >1. *Components design unification approach.* New proposed components
> > >will be developed by different contributors, but they need to be 
> > > unified
> > >and should integrate with each other easily. To ensure that I suggest
> > >calling an architecture group that will create design guidelines for 
> > > all
> > >components and high-level overview of overall architecture. How code is
> > >split into components, what are component boundaries, how component
> > >lifecycle works and what are its interfaces - all these and other
> > > questions
> > >should be covered.
> > >
> > >2. *Scope management.* Apache 3.0 should be implemented within a
> > >reasonable time, so we need some procedure to decide whether a
> > > particular
> > >feature should be dropped from the scope of 3.0 and 

Re: Live coding session next week

[Ilya Kazakov]

Hello Valentin!

Could you provide a link for a meeting, please?

-
Ilya Kazakov

пт, 13 нояб. 2020 г. в 07:07, Valentin Kulichenko <
valentin.kuliche...@gmail.com>:

> Igniters,
>
> On Tuesday next week (Nov 17), Denis Magda and I will conduct a live
> coding session, where we will implement a primitive Ignite-like distributed
> database from scratch. We will demonstrate major components required for
> such a system, show how they interact with each other and how they can be
> implemented in Java.
>
> Join if you would like to better understand how distributed systems work
> under the hood, or if you simply want to have some fun :)
>
> RSVP and all the details here: Tuesday, November 17, 2020
> 8:00 AM to 10:00 AM PST
>
> -Val
>

Re: [DISCUSS] Ignite 3.0 development approach

[Valentin Kulichenko]

Folks,

We already have multiple IEPs for Ignite 3.0, and as far as I know, there
are contributors that would like to work on them (or probably already
started). That said, we should make a decision as soon as possible.

At this point, it doesn't seem that there are any strong objections to the
technical side of things. So I would suggest the following:

1. Proceed with Alexey's approach to the development process, as it seems
to be the best (in my opinion - the only) way to address all the technical
concerns and issues expressed in the thread. We'll start by creating a new
repo and a new TC project.
2. Start a separate discussion around transparency. If there are any
changes we need to make to our contributor guidelines, I am happy to talk
them through, but I don't think it's reasonable to delay feature
development because of this. In the short term, I will make sure that
everything that happens within the new repo is as open to the community
as possible.

Nikolay, Maxim, are you OK with this route?

-Val

On Tue, Nov 10, 2020 at 4:55 PM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Maxim,
>
> 2.x and 3.x will have to coexist for some time - I don't see how we can
> avoid this considering the set of proposed changes. That said, we
> effectively will need to have two "masters" - one for each major version.
> Master for 3.x can technically be a branch in the existing repo, but having
> a separate repo seems cleaner, simply because it will not be a "branch" in
> the traditional sense.
>
> Note that the new repo will still be under the Apache org, with the same
> set of committers, managed by the community, etc. All the development
> happening for 3.0 must follow the rules that we currently have (if
> anything, it's an opportunity to improve those rules).
>
> As I said during the call on Friday, I strongly believe that if there is a
> transparency issue, it will exist regardless of the approach we choose for
> 3.0. If community members develop without IEPs or public discussions, this
> will happen for both 2.x and 3.x unless we address this separately. I don't
> see how this is related to Alexey's suggestion, which targets *technical*
> issues with the product more than anything else. This a way to achieve
> better modularity, introduce better coverage with unit tests, reduce
> conflicts during development, etc.
>
> Coming back to transparency, let's identify the issues and fix them. It
> probably makes sense to have a separate discussion on this topic.
>
> -Val
>
> On Tue, Nov 10, 2020 at 1:05 PM Maxim Muzafarov  wrote:
>
>>  Sergey,
>>
>>
>> Your summary makes sense to me.
>>
>> However, how we come up from *Development transparency* to *create a
>> separate public repository dedicated for 3.0*? For me *development
>> transparency* is about making changes in the master branch. These
>> changes will definitely be seen by all the Ignite developers.
>>
>> A dedicated public repository is technically public and visible for
>> everyone, but it allows development without IEPs, without public
>> discussion (since all the code changes are not related to the master
>> branch) it also allows a large number of assumptions and deviations
>> (like code-style violations). It also not about *development
>> transparency* since developers which are working on 3.0 is only a
>> subset of all Ignite developers which may continue working on 2.x. For
>> me, this would be a huge step backwards.
>>
>> Ignite veterans should remember how long the branch stabilization took
>> for the 2.x version with the PDS.
>>
>>
>> I think each breaking change should be passed through the master branch.
>>
>> On Tue, 10 Nov 2020 at 22:18, Alexei Scherbakov
>>  wrote:
>> >
>> > Makes sense to me.
>> >
>> > вт, 10 нояб. 2020 г. в 18:47, Sergey Chugunov <
>> sergey.chugu...@gmail.com>:
>> >
>> > > Igniters,
>> > >
>> > > I thought over Friday meeting ideas and concerns and summarized them
>> in
>> > > these three points:
>> > >
>> > >
>> > >1. *Components design unification approach.* New proposed
>> components
>> > >will be developed by different contributors, but they need to be
>> unified
>> > >and should integrate with each other easily. To ensure that I
>> suggest
>> > >calling an architecture group that will create design guidelines
>> for all
>> > >components and high-level overview of overall architecture. How
>> code is
>> > >split into components, what are component boundaries, how component
>> > >lifecycle works and what are its interfaces - all these and other
>> > > questions
>> > >should be covered.
>> > >
>> > >2. *Scope management.* Apache 3.0 should be implemented within a
>> > >reasonable time, so we need some procedure to decide whether a
>> > > particular
>> > >feature should be dropped from the scope of 3.0 and postponed to
>> 3.1
>> > >release. To do so I suggest to range all features by two
>> parameters:
>> > >criticality for 3.0 and amount of breaking 

Live coding session next week

[Valentin Kulichenko]

Igniters,

On Tuesday next week (Nov 17), Denis Magda and I will conduct a live coding
session, where we will implement a primitive Ignite-like distributed
database from scratch. We will demonstrate major components required for
such a system, show how they interact with each other and how they can be
implemented in Java.

Join if you would like to better understand how distributed systems work
under the hood, or if you simply want to have some fun :)

RSVP and all the details here: Tuesday, November 17, 2020
8:00 AM to 10:00 AM PST

-Val

.NET 5 and Ignite

[Pavel Tupitsyn]

Igniters,

Here is a short note on recently released .NET 5:
https://ptupitsyn.github.io/Ignite-on-NET-5/

Re: [DISCUSS] Release Ignite streamer extensions

[Mikhail Petrov]

PR [0] was updated. Scope of Ignite and  
dependencies has been set to "provided".


Could someone take a look, please?

[0] - https://github.com/apache/ignite-extensions/pull/28

On 12.11.2020 11:53, Alexey Goncharuk wrote:

Yes, the idea is correct. I cannot vouch for the ignite-spring-data
extension because I do not know whether there are maintenance releases for
each of the sprint-data-[2.0, 2.1, 2.2] streams. If spring-data-2.0.x is no
longer supported, then definitely we should be good to release it once and
move on.

--AG

ср, 11 нояб. 2020 г. в 17:26, Mikhail Petrov :


Alexey,

Did I understand you correctly?

For each new version of any extension, the minimum Ignite version and
the minimum version of  will be explicitly specified
in the release notes/documentation. It is also assumed that due to
backward compatibility users can safely use this extension with any
version of Ignite and  that is higher than the
specified minimum versions. And if any version of Ignite or  don't satisfy backward compatibility, new version of the
corresponding extension must be released.

If so, should we in this case get rid of multiple existing
ignite-spring-data-[2.0, 2.1, 2.2] modules and just successively release
existing modules with separate versions?

On 11.11.2020 11:54, Nikolay Izhikov wrote:

+1 to make extensions as independent as possible.

Doubt if we can do it for each module.
We have, ignite-hibernate_4.2, ignite-hibernate_5.1 modules that

attached to specific hibernate version by their name.



11 нояб. 2020 г., в 11:19, Alexey Goncharuk 

написал(а):

Hello Mikhail,

I see that now only Ignite dependencies are marked as 'provided',

however,

it makes sense to move all libraries being integrated to the 'provided'
scope (for example, the Apache Camel dependency for camel-ext and so

on).

This is how it is currently done for the spring-autoconfigure, and I
believe we should be consistent here: either always freeze the

integrations

versions, or always assume a user will provide them externally.

Thoughts?

вт, 10 нояб. 2020 г. в 14:14, Mikhail Petrov :


Igniters,

It seems that we came to decision on change of Ignite dependency scopes
to "provided". Don't we?

The corresponding ticket [1] is ready to final review. Saikat Maitra
have already reviewed and approved PR [2].

Could some committer take a final look?

[1] - https://issues.apache.org/jira/browse/IGNITE-13634
[2] - https://github.com/apache/ignite-extensions/pull/28

On 28.10.2020 20:24, Saikat Maitra wrote:

Hi

Alex,

Yes, we can start releasing the extensions modules. I would like to

also

help in releasing a few extensions, it will also help me to be

familiarized

with the release process.

Mikhail and I have been having discussion about whether we should use
provided scope for dependencies or shall we use 2.9.0 for

ignite.version

for the extensions modules?

Jira : https://issues.apache.org/jira/browse/IGNITE-13621
PR : https://github.com/apache/ignite-extensions/pull/28/files

Please let us know your thoughts.

Denis,

We have the following jira ticket for documentation work for ignite
extensions releases.

https://issues.apache.org/jira/browse/IGNITE-12951

Please let us know if the scope in the issue looks good.

Regards,
Saikat


On Wed, Oct 28, 2020 at 10:28 AM Denis Magda 

wrote:

Alex,

Should we create a dedicated ticket for the documentation changes or

can we

reuse IGNITE-13634? As a bare minimum, we need to update maven

artifacts'

names and versions:



https://github.com/apache/ignite/tree/master/docs/_docs/extensions-and-integrations


-
Denis


On Wed, Oct 28, 2020 at 5:10 AM Alexey Goncharuk <
alexey.goncha...@gmail.com>
wrote:


Igniters,

Since Ignite 2.9 has been released, I think we can now release the
extension modules related to streaming.

I noticed that unlike spring autoconfigure, the streamer extensions
dependencies do not have provided scope, so I created a ticket to

fix

that

[1]. Anything else we should fix before releasing the extensions?

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

--AG

Re: [REVIEW REQUEST] IEP-47 Native Persistence Defragmentation, core logic

[Denis Magda]

Ivan,

Nice! Is the plan to get it added to Ignite 2.10?

-
Denis


On Thu, Nov 12, 2020 at 7:11 AM Ivan Bessonov  wrote:

> Hi Igniters,
>
> Core functionality of defragmentation is finally implemented in [1].
> There's no public API in it
> for now, patch is already very big and had to be split into smaller tasks
> (that consist mostly of refactoring).
>
> Code is a little rough right now, I'm gonna go through all the remaining
> TODO, but you can already
> start reviewing it. PR is here: [2].
>
> First control.sh commands are here, but I don't have TC test results yet:
> [3].
> There will be more API related issues later, but now I'd like to polish
> core classes.
>
> Please leave your thoughts here and in PR.
>
> Thank you!
>
> [0]
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-47%3A+Native+persistence+defragmentation
> [1] https://issues.apache.org/jira/browse/IGNITE-13190
> [2] https://github.com/apache/ignite/pull/7984/files
> [3] https://issues.apache.org/jira/browse/IGNITE-13697
>
> --
> Sincerely yours,
> Ivan Bessonov
>

[jira] [Created] (IGNITE-13702) Fix description of soLibger for DiscoveryTcpSpi.

[Vladimir Steshin (Jira)]

Vladimir Steshin created IGNITE-13702:
-

 Summary: Fix description of soLibger for DiscoveryTcpSpi.
 Key: IGNITE-13702
 URL: https://issues.apache.org/jira/browse/IGNITE-13702
 Project: Ignite
  Issue Type: Improvement
  Components: documentation
Affects Versions: 2.10
Reporter: Vladimir Steshin
Assignee: Vladimir Steshin
 Fix For: 2.10


Fix description of soLibger for DiscoveryTcpSpi.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: First two chapters of Ignite ML book

[Kseniya Romanova]

Thank you, Alexey! Such posts can really help those, who are just
considering using Ignite. That kind of contribution is as significant as
the code!

чт, 12 нояб. 2020 г. в 14:42, Alexey Zinoviev :

> Hi, dear community, today I published two first chapters of Ignite ML books
>
>1. Apache Ignite ML: origins and development
>
> 
>2. Apache Ignite ML: possible use cases, racing with Spark ML, plans
>for the future
>
> 
>
> If you have any questions or feedback please let me know.
>
> P.S. I ask you to do +50 claps for my new article, if you have a medium
> account, this will increase it in the search results and recommendations.
>

[REVIEW REQUEST] IEP-47 Native Persistence Defragmentation, core logic

[Ivan Bessonov]

Hi Igniters,

Core functionality of defragmentation is finally implemented in [1].
There's no public API in it
for now, patch is already very big and had to be split into smaller tasks
(that consist mostly of refactoring).

Code is a little rough right now, I'm gonna go through all the remaining
TODO, but you can already
start reviewing it. PR is here: [2].

First control.sh commands are here, but I don't have TC test results yet:
[3].
There will be more API related issues later, but now I'd like to polish
core classes.

Please leave your thoughts here and in PR.

Thank you!

[0]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-47%3A+Native+persistence+defragmentation
[1] https://issues.apache.org/jira/browse/IGNITE-13190
[2] https://github.com/apache/ignite/pull/7984/files
[3] https://issues.apache.org/jira/browse/IGNITE-13697

-- 
Sincerely yours,
Ivan Bessonov

[jira] [Created] (IGNITE-13701) SQL Indexes,Tables and Schemas views in IEP-35 changed amount, order of columns and content

[Andrey N. Gura (Jira)]

Andrey N. Gura created IGNITE-13701:
---

 Summary: SQL Indexes,Tables and Schemas views in IEP-35 changed 
amount, order of columns and content
 Key: IGNITE-13701
 URL: https://issues.apache.org/jira/browse/IGNITE-13701
 Project: Ignite
  Issue Type: Bug
  Components: sql
Reporter: Andrey N. Gura
 Fix For: 2.10


https://issues.apache.org/jira/browse/IGNITE-12213 broke backward compatibility:

  * {{CACHE_GROUP_ID}} and {{CACHE_GROUP_NAME}} columns was removed from the 
{{INDEXES}} view.
  * {{CACHE_GROUP_ID}} and {{CACHE_GROUP_NAME}} columns was removed from the 
{{TABLES}} view.
  * {{SCHEMA_NAME}} column was renamed to {{NAME}} for the {{SCHEMAS}} view.
  * {{PREDEFINED}} column was added to the {{SCHEMAS}} view.

Default columns order was changed.

Also content of {{SCHEMAS}} view has changed in a wrong way: now view contains 
proxy indexes (it is simply wrapper and implementation detail) and indexes for 
cache key displays as {{PK}} index (it is incorrect, because {{PK}} index could 
be only for table and this kind of indexes is implementation detail).

This behavior should be replaced by previous one.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13700) ConcurrentModificationException on node join.

[Konstantin Sirotkin (Jira)]

Konstantin Sirotkin created IGNITE-13700:


 Summary: ConcurrentModificationException on node join.
 Key: IGNITE-13700
 URL: https://issues.apache.org/jira/browse/IGNITE-13700
 Project: Ignite
  Issue Type: Bug
Reporter: Konstantin Sirotkin
Assignee: Konstantin Sirotkin


This issue was created for more complex investigation of problem IGNITE-13554.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

First two chapters of Ignite ML book

[Alexey Zinoviev]

Hi, dear community, today I published two first chapters of Ignite ML books

   1. Apache Ignite ML: origins and development
   

   2. Apache Ignite ML: possible use cases, racing with Spark ML, plans for
   the future
   


If you have any questions or feedback please let me know.

P.S. I ask you to do +50 claps for my new article, if you have a medium
account, this will increase it in the search results and recommendations.

[jira] [Created] (IGNITE-13699) Support new metrics framework in ZookeeperDiscovery

[Ivan Daschinskiy (Jira)]

Ivan Daschinskiy created IGNITE-13699:
-

 Summary: Support new metrics framework in ZookeeperDiscovery
 Key: IGNITE-13699
 URL: https://issues.apache.org/jira/browse/IGNITE-13699
 Project: Ignite
  Issue Type: Improvement
  Components: zookeeper
Reporter: Ivan Daschinskiy
Assignee: Ivan Daschinskiy






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13698) SQL EXPLAIN Shows Impossible Index

[Alexey Kukushkin (Jira)]

Alexey Kukushkin created IGNITE-13698:
-

 Summary: SQL EXPLAIN Shows Impossible Index
 Key: IGNITE-13698
 URL: https://issues.apache.org/jira/browse/IGNITE-13698
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.9
Reporter: Alexey Kukushkin


+*Steps to Reproduce*+

1. Create a table with a VARCHAR field and an index on that field

{{CREATE TABLE TEST (ID INT PRIMARY KEY, TITLE VARCHAR);}}
{{CREATE INDEX TEST_TITLE_ASC_IDX ON TEST(TITLE); }}

2. Show a plan for querying the table with a filter UPPER(TITLE) LIKE '%A%'

{{EXPLAIN SELECT _KEY FROM TEST WHERE UPPER(TITLE) LIKE '%A%';}}

+*Expected*+

The table SCAN on the TITLE field since the TEST_TITLE_ASC_IDX cannot be 
applied due to any of"
 # The UPPER(TITLE) SQL function on the left-hand side
 # The LIKE pattern starting from % (any symbol)

+*Actual*+

The TEST_TITLE_ASC_IDX is used

{{SELECT}}
{{ __Z0._KEY AS __C0_0}}
{{FROM PUBLIC.TEST __Z0}}
{{ /* PUBLIC.TEST_TITLE_ASC_IDX */}}
{{WHERE UPPER(__Z0.TITLE) LIKE '%A%'}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)

[Anton Vinogradov]

> - Distributed environment tests [2] (Nikolay Izhikov, Anton
> Vinogradov, Ivan Daschinskiy)
> Will all related issues be included in the 2.10?
We're at the final preparations phase. Going to start the merge discussion
soon.

On Wed, Nov 11, 2020 at 4:48 PM Alexey Zinoviev 
wrote:

> Yes, Model Export/Import for ML will be finished, now it's ready, but under
> testing on my side.
>
> ср, 11 нояб. 2020 г. в 16:08, Nikolay Izhikov :
>
> > I suggest to include CDC feature to the 2.10 scope.
> >
> > > 11 нояб. 2020 г., в 16:06, Maxim Muzafarov 
> > написал(а):
> > >
> > > Igniters,
> > >
> > >
> > > Can you clarify the issue statuses according to the Apache Ignite
> > > Roadmap [1] and the 2.10 Apache Ignite Release? Here are some major
> > > issues which are expected to be included in 2.10 with the unknown
> > > status:
> > >
> > > - Distributed environment tests [2] (Nikolay Izhikov, Anton
> > > Vinogradov, Ivan Daschinskiy)
> > > Will all related issues be included in the 2.10?
> > >
> > > - Native persistence defragmentation [6][7] (Anton Kalashnikov, Sergey
> > Chugunov)
> > > Are we on the last mile with this for 2.10?
> > >
> > > - Consistency-related improvements for atomic caches [3] (Alexey
> > Scherbakov)
> > > Do we have the JIRA issue? Will the issue be included in 2.10?
> > >
> > > - Tombstone objects during rebalancing [4] (Alexey Scherbakov)
> > > The issue [4] is in progress state. Will it be finished prior to code
> > freeze?
> > >
> > > - SQL runtime statistics (Konstantin Orlov)
> > > Do we have an IEP for this or JIRA issue?
> > >
> > > - ML Model export/import [5] (Alexey Zinoviev)
> > > - Will the issue be finished?
> > >
> > >
> > > [1]
> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap
> > > [2]
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-56%3A+Distributed+environment+tests
> > > [3]
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-12+Make+ATOMIC+Caches+Consistent+Again
> > > [4] https://issues.apache.org/jira/browse/IGNITE-11704
> > > [5] https://issues.apache.org/jira/browse/IGNITE-6642
> > > [6] https://issues.apache.org/jira/browse/IGNITE-13143
> > > [7]
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-47%3A+Native+persistence+defragmentation
> > >
> > > On Tue, 10 Nov 2020 at 15:58, Maxim Muzafarov 
> wrote:
> > >>
> > >> Folks,
> > >>
> > >> I've created the release page on the Confluence. Feel free to mail in
> > >> case of any errors.
> > >>
> > >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.10
> > >>
> > >> On Fri, 6 Nov 2020 at 17:56, Maxim Muzafarov 
> wrote:
> > >>>
> > >>> Igniters,
> > >>>
> > >>>
> > >>> Let's finalize the discussion [1] about the next upcoming major
> Apache
> > >>> Ignite 2.10  release. The major improvements related to the proposed
> > >>> release:
> > >>> - Improvements for partition clearing related parts
> > >>> - Add tracing of SQL queries.
> > >>> - CPP: Implement Cluster API
> > >>> - .NET: Thin client: Transactions
> > >>> - .NET: Thin Client: Continuous Query
> > >>> - Java Thin client Kubernetes discovery
> > >>>
> > >>> etc.
> > >>> Total: 166 RESOLVED issues [2].
> > >>>
> > >>>
> > >>> Let's start the discussion about Time and Scope, and also I propose
> > >>> myself as the release manager of the Apache Ignite 2.10. If you'd
> like
> > >>> to lead this release, please, let us know, I see no problems to chose
> > >>> a better candidate.
> > >>>
> > >>>
> > >>> Proposed release timeline:
> > >>>
> > >>> Scope Freeze: December 10, 2020
> > >>> Code Freeze: December 24, 2020
> > >>> Voting Date: January 18, 2021
> > >>> Release Date: January 25, 2021
> > >>>
> > >>>
> > >>> Proposed release scope:
> > >>> [2]
> > >>>
> > >>>
> > >>> WDYT?
> > >>>
> > >>>
> > >>> [1]
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/2-9-1-release-proposal-tp49769p49867.html
> > >>> [2]
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.10%20and%20status%20in%20(Resolved%2C%20Closed)%20and%20resolution%20%3D%20Fixed%20order%20by%20priority%20
> >
> >
>

[jira] [Created] (IGNITE-13697) Control.sh API - schedule & cancel

[Ivan Bessonov (Jira)]

Ivan Bessonov created IGNITE-13697:
--

 Summary: Control.sh API - schedule & cancel
 Key: IGNITE-13697
 URL: https://issues.apache.org/jira/browse/IGNITE-13697
 Project: Ignite
  Issue Type: Sub-task
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] Release Ignite streamer extensions

[Alexey Goncharuk]

Yes, the idea is correct. I cannot vouch for the ignite-spring-data
extension because I do not know whether there are maintenance releases for
each of the sprint-data-[2.0, 2.1, 2.2] streams. If spring-data-2.0.x is no
longer supported, then definitely we should be good to release it once and
move on.

--AG

ср, 11 нояб. 2020 г. в 17:26, Mikhail Petrov :

> Alexey,
>
> Did I understand you correctly?
>
> For each new version of any extension, the minimum Ignite version and
> the minimum version of  will be explicitly specified
> in the release notes/documentation. It is also assumed that due to
> backward compatibility users can safely use this extension with any
> version of Ignite and  that is higher than the
> specified minimum versions. And if any version of Ignite or  target> don't satisfy backward compatibility, new version of the
> corresponding extension must be released.
>
> If so, should we in this case get rid of multiple existing
> ignite-spring-data-[2.0, 2.1, 2.2] modules and just successively release
> existing modules with separate versions?
>
> On 11.11.2020 11:54, Nikolay Izhikov wrote:
> > +1 to make extensions as independent as possible.
> >
> > Doubt if we can do it for each module.
> > We have, ignite-hibernate_4.2, ignite-hibernate_5.1 modules that
> attached to specific hibernate version by their name.
> >
> >
> >> 11 нояб. 2020 г., в 11:19, Alexey Goncharuk 
> написал(а):
> >>
> >> Hello Mikhail,
> >>
> >> I see that now only Ignite dependencies are marked as 'provided',
> however,
> >> it makes sense to move all libraries being integrated to the 'provided'
> >> scope (for example, the Apache Camel dependency for camel-ext and so
> on).
> >> This is how it is currently done for the spring-autoconfigure, and I
> >> believe we should be consistent here: either always freeze the
> integrations
> >> versions, or always assume a user will provide them externally.
> >>
> >> Thoughts?
> >>
> >> вт, 10 нояб. 2020 г. в 14:14, Mikhail Petrov :
> >>
> >>> Igniters,
> >>>
> >>> It seems that we came to decision on change of Ignite dependency scopes
> >>> to "provided". Don't we?
> >>>
> >>> The corresponding ticket [1] is ready to final review. Saikat Maitra
> >>> have already reviewed and approved PR [2].
> >>>
> >>> Could some committer take a final look?
> >>>
> >>> [1] - https://issues.apache.org/jira/browse/IGNITE-13634
> >>> [2] - https://github.com/apache/ignite-extensions/pull/28
> >>>
> >>> On 28.10.2020 20:24, Saikat Maitra wrote:
>  Hi
> 
>  Alex,
> 
>  Yes, we can start releasing the extensions modules. I would like to
> also
>  help in releasing a few extensions, it will also help me to be
> >>> familiarized
>  with the release process.
> 
>  Mikhail and I have been having discussion about whether we should use
>  provided scope for dependencies or shall we use 2.9.0 for
> ignite.version
>  for the extensions modules?
> 
>  Jira : https://issues.apache.org/jira/browse/IGNITE-13621
>  PR : https://github.com/apache/ignite-extensions/pull/28/files
> 
>  Please let us know your thoughts.
> 
>  Denis,
> 
>  We have the following jira ticket for documentation work for ignite
>  extensions releases.
> 
>  https://issues.apache.org/jira/browse/IGNITE-12951
> 
>  Please let us know if the scope in the issue looks good.
> 
>  Regards,
>  Saikat
> 
> 
>  On Wed, Oct 28, 2020 at 10:28 AM Denis Magda 
> wrote:
> 
> > Alex,
> >
> > Should we create a dedicated ticket for the documentation changes or
> >>> can we
> > reuse IGNITE-13634? As a bare minimum, we need to update maven
> >>> artifacts'
> > names and versions:
> >
> >
> >>>
> https://github.com/apache/ignite/tree/master/docs/_docs/extensions-and-integrations
> >
> >
> > -
> > Denis
> >
> >
> > On Wed, Oct 28, 2020 at 5:10 AM Alexey Goncharuk <
> > alexey.goncha...@gmail.com>
> > wrote:
> >
> >> Igniters,
> >>
> >> Since Ignite 2.9 has been released, I think we can now release the
> >> extension modules related to streaming.
> >>
> >> I noticed that unlike spring autoconfigure, the streamer extensions
> >> dependencies do not have provided scope, so I created a ticket to
> fix
> > that
> >> [1]. Anything else we should fix before releasing the extensions?
> >>
> >> [1] https://issues.apache.org/jira/browse/IGNITE-13634
> >>
> >> --AG
> >>
>