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

[dpavlov . tasks]

Hi Igniters,

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

 If your changes can lead to this failure(s): We're grateful that you were a 
volunteer to make the contribution to this project, but things change and you 
may no longer be able to finalize your contribution.
 Could you respond to this email and indicate if you wish to continue and fix 
test failures or step down and some committer may revert you commit. 

 *New stable failure of a flaky test in master 
IgniteSinkConnectorTest.testSinkPutsWithoutTransformation 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7952366899750322781=%3Cdefault%3E=testDetails

 *New stable failure of a flaky test in master 
IgniteSinkConnectorTest.testSinkPutsWithTransformation 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-6495637752134628320=%3Cdefault%3E=testDetails
 Changes may lead to failure were done by 
 - dmitrii ryabov  
https://ci.ignite.apache.org/viewModification.html?modId=890732
 - mstepachev  
https://ci.ignite.apache.org/viewModification.html?modId=890735
 - andrey gura  
https://ci.ignite.apache.org/viewModification.html?modId=890728

 - Here's a reminder of what contributors were agreed to do 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 
 - Should you have any questions please contact dev@ignite.apache.org 

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 04:08:55 25-09-2019 

Re: nodes are restarting when i try to drop a table created with persistence enabled

[Denis Magda]

Shiva,

Does this issue still exist? Ignite Dev how do we debug this sort of thing?

-
Denis


On Tue, Sep 17, 2019 at 7:22 AM Shiva Kumar 
wrote:

> Hi dmagda,
>
> I am trying to drop the table which has around 10 million records and I am
> seeing "*Out of memory in data region*" error messages in Ignite logs and
> ignite node [Ignite pod on kubernetes] is restarting.
> I have configured 3GB for default data region, 7GB for JVM and total 15GB
> for Ignite container and enabled native persistence.
> Earlier I was in an impression that restart was caused by "
> *SYSTEM_WORKER_BLOCKED*" errors but now I am realized that  "
> *SYSTEM_WORKER_BLOCKED*" is added to ignore failure list and the actual
> cause is " *CRITICAL_ERROR* " due to  "*Out of memory in data region"*
>
> This is the error messages in logs:
>
> ""[2019-09-17T08:25:35,054][ERROR][sys-#773][] *JVM will be halted
> immediately due to the failure: [failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=class o.a.i.i.mem.IgniteOutOfMemoryException:
> Failed to find a page for eviction* [segmentCapacity=971652,
> loaded=381157, maxDirtyPages=285868, dirtyPages=381157, cpPages=0,
> pinnedInSegment=3, failedToPrepare=381155]
> *Out of memory in data region* [name=Default_Region, initSize=500.0 MiB,
> maxSize=3.0 GiB, persistenceEnabled=true] Try the following:
>   ^-- Increase maximum off-heap memory size
> (DataRegionConfiguration.maxSize)
>   ^-- Enable Ignite persistence
> (DataRegionConfiguration.persistenceEnabled)
>   ^-- Enable eviction or expiration policies]]
>
> Could you please help me on why *drop table operation* causing  "*Out of
> memory in data region"*? and how I can avoid it?
>
> We have a use case where application inserts records to many tables in
> Ignite simultaneously for some time period and other applications run a
> query on that time period data and update the dashboard. we need to delete
> the records inserted in the previous time period before inserting new
> records.
>
> even during *delete from table* operation, I have seen:
>
> "Critical system error detected. Will be handled accordingly to configured 
> handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, 
> super=AbstractFailureHandler [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED]]], 
> failureCtx=FailureContext [*type=CRITICAL_ERROR*, err=class 
> o.a.i.IgniteException: *Checkpoint read lock acquisition has been timed 
> out*.]] class org.apache.ignite.IgniteException: Checkpoint read lock 
> acquisition has been timed out.|
>
>
>
> On Mon, Apr 29, 2019 at 12:17 PM Denis Magda  wrote:
>
>> Hi Shiva,
>>
>> That was designed to prevent global cluster performance degradation or
>> other outages. Have you tried to apply my recommendation of turning of the
>> failure handler for this system threads?
>>
>> -
>> Denis
>>
>>
>> On Sun, Apr 28, 2019 at 10:28 AM shivakumar 
>> wrote:
>>
>>> HI Denis,
>>>
>>> is there any specific reason for the blocking of critical thread, like
>>> CPU
>>> is full or Heap is full ?
>>> We are again and again hitting this issue.
>>> is there any other way to drop tables/cache ?
>>> This looks like a critical issue.
>>>
>>> regards,
>>> shiva
>>>
>>>
>>>
>>> --
>>> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>>>
>>

Re: Please grant jira-user privilege to me.

[Denis Magda]

Ken,

As responded in Slack, you should be able to change the ticket status as
long as you're in the contributors' list.

-
Denis


On Tue, Sep 24, 2019 at 7:45 AM Ken Cheng  wrote:

> Hi dev,
>
> Right now I am working on
>
> https://issues.apache.org/jira/browse/IGNITE-11008
> https://issues.apache.org/jira/browse/IGNITE-11868
> https://issues.apache.org/jira/browse/IGNITE-12088
> https://issues.apache.org/jira/browse/IGNITE-11976
>
>
>
> most of them are ready for review.
>
> Can someone grant me 'jira-user' privilege to me. As I need to change the
> status to "patchable" for further processing.
>
> Thanks
>
> [image: image.png]
>
> Thanks,
> Ken Cheng
>

Re: Spark examples on TC

[Denis Magda]

Nikolay,

Thanks for the details. How about enforcing JDK 8 for the Spark integration
in general and run its tests on the VM only? We'll do this until Spark
community fully support JDK 11+.

As for Spark 2.4.0 module [1], how about releasing Ignite 2.7.7 with Spark
related changes only? As long as Ignite modularization is a long process,
we can follow your advice and create two more modules ignite_spark_24 and
ignite_spark_25 . Plus Alexey is working on extra Spark improvements.

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


On Thu, Sep 19, 2019 at 11:58 PM Nikolay Izhikov 
wrote:

> Hello, Denis.
>
> Spark uses Scala 2.11 [1]
> Scala 2.11 compatible with the jdk version described on [2].
>
> Few notes from the link:
>
> > We recommend using Java 8 for compiling Scala code
> > JDK 11 compatibility notes
> > As of Scala 2.13.0, 2.12.8 and 2.11.12, JDK 11 support is incomplete
>
> I also got several issues with the Spark itself when trying to run it on
> the Java 11.
> Please, take a look at [3], [4]
>
> All in all, with the spark 2.3 we should stay on java8 to get things
> worked.
>
> [1] http://spark.apache.org/docs/2.4.0/
> [2] https://docs.scala-lang.org/overviews/jdk-compatibility/overview.html
> [3]
>
> https://stackoverflow.com/questions/49961991/java-lang-illegalargumentexception-at-org-apache-xbean-asm5-classreader-initu?noredirect=1=1
> [4]
>
> https://stackoverflow.com/questions/51352591/spark-java-illegalargumentexception-at-org-apache-xbean-asm5-classreader
>
>
> чт, 19 сент. 2019 г. в 21:39, Denis Magda :
>
> > Nikolay,
> >
> > What needs to be done to ensure Java 9++ works with Spark Examples? Do we
> > need to create another Spark module or drop some scala version?
> >
> > -
> > Denis
> >
> >
> > On Thu, Sep 19, 2019 at 9:23 AM Nikolay Izhikov 
> > wrote:
> >
> > > Hello, Igniters.
> > >
> > > Examples suite on TC doesn't work correctly under java9+. [1], [2]
> > >
> > > The reason is the Spark examples.
> > >
> > > Spark 2.3(our current version) work with scala 2.11 and scala 2.11
> > support
> > > of java9+ is "incomplete".
> > >
> > > Can we stick example suite to jdk8 only?
> > >
> > > [1]
> > >
> >
> https://ci.ignite.apache.org/viewLog.html?buildId=4610507=IgniteTests24Java8_Examples
> > > [2]
> > >
> >
> https://ci.ignite.apache.org/viewLog.html?buildId=4609013=IgniteTests24Java8_Examples
> > >
> >
>

Re: Improvements for P2P class loading

[Denis Magda]

Denis,

Why do we broadcast the request to all the nodes in case of scenario a)?
There should be a reason for that.

Alex Goncharuk, do you remember we planned to revisit the P2P as part of
Ignite 3.0 to remove certain limitations? How about linking all the P2P
tasks together and create either an IEP or an umbrella ticket.

-
Denis


On Tue, Sep 24, 2019 at 12:55 AM Denis Garus  wrote:

> Igniters!
>
> I would like to propose a few improvements for the P2P class loading
> feature in Ignite.
> These improvements have the aim to reduce the number of requests that may
> be needing to get a class on a remote node.
>
> a. We should send a request for a class to the node initiator firstly.
> Currently, GridDeploymentClassLoader sends a request for a class to all
> participated nodes one by one until it gets a successful response. However,
> in most cases, the required byte code would be loaded from the node that
> initiates execution. To find out what is the node initiator, we can use the
> way that we use to determine a security context to execute a user-defined
> code (see GridIoManager#invokeListener). If the node initiator doesn't have
> a required class, we should ask other participated nodes as it is
> currently.
>
> b. Some classes in a single response.
> When a required class contains anonymous and/or inner classes, Ignite tries
> to get these classes using separate requests. However, we can determine
> that case and send data, that we send anyway, in a single response as an
> answer for the first request. In this way, we may significantly reduce the
> number of communications required for a class loading.
>
> What do you think?
>
> I would like to create a separate task for a. and b.
>

[jira] [Created] (IGNITE-12229) Column not found when using CASE named column from result

[Ilya Kasnacheev (Jira)]

Ilya Kasnacheev created IGNITE-12229:


 Summary: Column not found when using CASE named column from result
 Key: IGNITE-12229
 URL: https://issues.apache.org/jira/browse/IGNITE-12229
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Affects Versions: 2.7.6
Reporter: Ilya Kasnacheev


Consider the following SQL:
{code}
create table main (key varchar primary key, val int, grouper int);
create table joiner (key varchar primary key, value int, grouper int);
select m.key, case when m.grouper > j.grouper then 1 else -1 end d_grouper from 
main m join joiner j on m.key = j.key where d_grouper = 1 order by d_grouper;
{code}
Expected behavior - success.
Observed behavior:
{code}
[20:31:13,498][SEVERE][jdbc-request-handler-worker-#1828][JdbcRequestHandler] 
Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest 
[schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=select m.key, case when 
m.grouper > j.grouper then 1 else -1 end d_grouper from main m join joiner j on 
m.key = j.key where d_grouper = 1 order by d_grouper, args=[], 
stmtType=ANY_STATEMENT_TYPE, autoCommit=true]]
class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to 
parse query. Столбец "D_GROUPER" не найден
Column "D_GROUPER" not found; SQL statement:
select m.key, case when m.grouper > j.grouper then 1 else -1 end d_grouper from 
main m join joiner j on m.key = j.key where d_grouper = 1 order by d_grouper 
[42122-197]
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatementAndCaches(IgniteH2Indexing.java:2653)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.parseAndSplit(IgniteH2Indexing.java:2356)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:2196)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2128)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2123)
at 
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2693)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2137)
at 
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:511)
at 
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.doHandle(JdbcRequestHandler.java:245)
at 
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandlerWorker.body(JdbcRequestHandlerWorker.java:90)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.h2.jdbc.JdbcSQLException: Столбец "D_GROUPER" не найден
Column "D_GROUPER" not found; SQL statement:
select m.key, case when m.grouper > j.grouper then 1 else -1 end d_grouper from 
main m join joiner j on m.key = j.key where d_grouper = 1 order by d_grouper 
[42122-197]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:357)
at org.h2.message.DbException.get(DbException.java:179)
at org.h2.message.DbException.get(DbException.java:155)
at 
org.h2.expression.ExpressionColumn.optimize(ExpressionColumn.java:150)
at org.h2.expression.Comparison.optimize(Comparison.java:177)
at org.h2.expression.ConditionAndOr.optimize(ConditionAndOr.java:130)
at org.h2.command.dml.Select.prepare(Select.java:861)
at org.h2.command.Parser.prepareCommand(Parser.java:283)
at org.h2.engine.Session.prepareLocal(Session.java:611)
at org.h2.engine.Session.prepareCommand(Session.java:549)
at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1247)
at 
org.h2.jdbc.JdbcPreparedStatement.(JdbcPreparedStatement.java:76)
at org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:694)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepare0(IgniteH2Indexing.java:539)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatement(IgniteH2Indexing.java:509)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatement(IgniteH2Indexing.java:476)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatementAndCaches(IgniteH2Indexing.java:2635)
... 12 more
{code}



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

[jira] [Created] (IGNITE-12228) Implement an Apache Beam runner on top of Ignite compute grid?

[Romain Manni-Bucau (Jira)]

Romain Manni-Bucau created IGNITE-12228:
---

 Summary: Implement an Apache Beam runner on top of Ignite compute 
grid?
 Key: IGNITE-12228
 URL: https://issues.apache.org/jira/browse/IGNITE-12228
 Project: Ignite
  Issue Type: Wish
Reporter: Romain Manni-Bucau


Apache Ignite provides a compute grid.

It is therefore feasible to use that to execute a DAG pipeline.

Therefore implementing a Apache Beam runner executing a DAG on an ignite 
cluster would be very valuable for users and would provide a very interesting 
alternative to Spark, Dataflow etc...which would be very valuable when using 
data from ignite itself. 

Hoping it can help, here is Hazelcast Jet implementation which is not that far 
even if Jet is a bit more advanced in term of DAG support: 
[https://github.com/apache/beam/tree/master/runners/jet-experimental/src/main/java/org/apache/beam/runners/jet]



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

Re: [DISCUSSION] Single point in API for changing cluster state.

[Maxim Muzafarov]

Sergey,

+1, I like your idea.

I think from the user point the INACTIVE -> READ-ONLY transition [1]
should be allowed prior to adding a new `state` command [2] to avoid
unnecessary error messages. I also think we can avoid the word 'set`
in this command.

Example: control.sh --state ACTIVE [--yes]


What about cluster deactivation confirmation? Will it be used for all
the cluster state changes?
  Deactivate cluster:
control.(sh|bat) --deactivate [--yes]


[1] https://issues.apache.org/jira/browse/IGNITE-11866
[2] https://issues.apache.org/jira/browse/IGNITE-12225



On Tue, 24 Sep 2019 at 16:50, Sergey Antonov  wrote:
>
> Andrey,
>
> > What are state transitions valid?
> Now all transitions are valid, except INACTIVE -> READ-ONLY. This
> transition will be fixed under [1]
>
> > Regarding state names, as I understand, all transitions are valid from
> any to any of 3 states.
> Yes, see my comment above.
>
> > But, regarding on console.sh command it is not obvious.
> Yes. It's one of points why we should have single command in control.sh.
>
> > What effect will --read-only-on and --read-only-off commands have if
> current state is INACTIVE ?
> --read-only-on - cluster will be activated in read-only mode
> --read-only-off - cluster will be activated. I.e --read-only-off will have
> the same effect as --activate
> [1] https://issues.apache.org/jira/browse/IGNITE-11866
>
> вт, 24 сент. 2019 г. в 16:40, Andrey Mashenkov :
>
> > Sergey,
> >
> > What are state transitions valid?
> > For now we have only 2 states (active and inactive) and possible
> > transitions are obvious Active <--> Inactive.
> >
> > Regarding state names, as I understand, all transitions are valid from any
> > to any of 3 states.
> > But, regarding on console.sh command it is not obvious.
> > What effect will --read-only-on and --read-only-off commands have if
> > current state is INACTIVE ?
> >
> >
> > On Tue, Sep 24, 2019 at 4:23 PM Sergey Antonov 
> > wrote:
> >
> > > Also, I would add IGNITE-12225
> > >  ticket to 2.8
> > release
> > > scope.
> > >
> > > вт, 24 сент. 2019 г. в 16:18, Sergey Antonov  > >:
> > >
> > > > Hi, Igniters!
> > > >
> > > > We have 3 cluster states at the moment: inactive, active, read-only.
> > > >
> > > > For getting current cluster state and changing them IgniteCluster has
> > > > methods:
> > > >
> > > >- boolean active(), void active(boolean active) - for cluster
> > > >activation/deactivation
> > > >- boolean readOnly(), void readOnly(boolean readOnly) - for
> > > >enabling/disabling read-only mode.
> > > >
> > > > Also we have control.sh commans for changing cluster state:
> > > >
> > > >- --activate
> > > >- --deactivate
> > > >- --read-only-on
> > > >- --read-only-off
> > > >
> > > > For me current API looks unuseful. My proposal:
> > > >
> > > >1. Create enum ClusterState with values ACTIVE, INACTIVE, READ-ONLY.
> > > >2. Add methods to IgniteCluster:
> > > >   - ClusterState state() returns current cluster state
> > > >   - void state(ClusterState newState) changes cluster state to
> > > >   newState state
> > > >3. Mark as deprecated the following methods in IgniteCluster:
> > boolean
> > > >active(), void active(boolean active),
> > > >4. Add new command to control.sh: control.sh --set-state
> > > >(ACTIVE|INACTIVE|READ-ONLY)
> > > >5. Add warn message that command is depricated in control.sh.
> > > >Commands: --activate, --deactivate, --read-only-on, --read-only-off
> > > >
> > > >
> > > > I created ticket [1] in Jira for it.
> > > >
> > > > What do you think about my proposal?
> > > >
> > > > [1] https://issues.apache.org/jira/browse/IGNITE-12225
> > > > --
> > > > BR, Sergey Antonov
> > > >
> > >
> > >
> > > --
> > > BR, Sergey Antonov
> > >
> >
> >
> > --
> > Best regards,
> > Andrey V. Mashenkov
> >
>
>
> --
> BR, Sergey Antonov

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

[Anton Kalashnikov]

Hello, Igniters.

I want to notice one more blocker for release [1]. This bug can lead to some 
incorrect baseline default enabled flag calculation(more details in the ticket).

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

-- 
Best regards,
Anton Kalashnikov


24.09.2019, 17:01, "Andrey Gura" :
> Sergey,
>
> As I know, scope freeze is not announced yet.
>
> On Tue, Sep 24, 2019 at 4:41 PM Sergey Antonov
>  wrote:
>>  Hi, I would add to release scope my ticket [1].
>>
>>  Any objections?
>>
>>  [1] https://issues.apache.org/jira/browse/IGNITE-12225
>>
>>  вт, 24 сент. 2019 г. в 09:21, Nikolay Izhikov :
>>
>>  > > merge to master only fully finished features
>>  >
>>  > It's already true for Ignite master branch.
>>  >
>>  >
>>  > В Вт, 24/09/2019 в 09:03 +0300, Alexey Zinoviev пишет:
>>  > > The planned before 2_3 months release dates are good defender from
>>  > > partially merged features, In my opinion
>>  > >
>>  > > Or we should have Master and dev branch separetely, and merge to master
>>  > > only fully finished features
>>  > >
>>  > > пн, 23 сент. 2019 г., 20:27 Maxim Muzafarov :
>>  > >
>>  > > > Andrey,
>>  > > >
>>  > > > Agree with you. It can affect the user impression.
>>  > > >
>>  > > > Can you advise, how can we guarantee in our case when we complete with
>>  > > > current partially merged features that someone will not partially
>>  > > > merge the new one? Should we monitor the master branch commits for
>>  > > > such purpose?
>>  > > >
>>  > > > On Mon, 23 Sep 2019 at 20:18, Andrey Gura  wrote:
>>  > > > >
>>  > > > > Maxim,
>>  > > > >
>>  > > > > > > From my point, if some components will not be ready by
>>  > > > > > > previously discussed `scope freeze` date it is absolutely OK to
>>  > > > > > > perform the next (e.g. 2.8.1, 2.8.2) releases.
>>  > > > >
>>  > > > > It is good approach if partial implemented features aren't merged to
>>  > > > > master branch. Unfortunately this is not our case.
>>  > > > >
>>  > > > > I don't see any reasons to force new Apache Ignite release. Time is
>>  > > > > not driver for release. If we want release Ignite periodically we
>>  > must
>>  > > > > significantly review the process. And most valuable change in this
>>  > > > > process is feature branches that will not block new release by
>>  > design.
>>  > > > >
>>  > > > > On Mon, Sep 23, 2019 at 8:12 PM Andrey Gura 
>>  > wrote:
>>  > > > > >
>>  > > > > > > > From my point of view monitoring isn't ready for release.
>>  > > > > > > Can you clarify, what exactly is not ready?
>>  > > > > > > Can we track planned changes somehow?
>>  > > > > >
>>  > > > > > We have too many not resolved tickets under IEP-35 label [1]. Also
>>  > it
>>  > > > > > makes sense to do some usability testing: JMX beans interfaces,
>>  > system
>>  > > > > > views, etc.
>>  > > > > >
>>  > > > > >
>>  > > > > > [1]
>>  > https://issues.apache.org/jira/issues/?jql=labels%20%3D%20IEP-35
>>  > > > > >
>>  > > > > > On Mon, Sep 23, 2019 at 6:04 PM Nikolay Izhikov <
>>  > nizhi...@apache.org>
>>  > > >
>>  > > > wrote:
>>  > > > > > >
>>  > > > > > > Hello, Andrey.
>>  > > > > > >
>>  > > > > > > > From my point of view monitoring isn't ready for release.
>>  > > > > > >
>>  > > > > > > Can you clarify, what exactly is not ready?
>>  > > > > > > Can we track planned changes somehow?
>>  > > > > > >
>>  > > > > > >
>>  > > > > > > В Пн, 23/09/2019 в 17:59 +0300, Andrey Gura пишет:
>>  > > > > > > > Igniters,
>>  > > > > > > >
>>  > > > > > > > From my point of view monitoring isn't ready for release. So 
>> it
>>  > > >
>>  > > > would
>>  > > > > > > > be great to return to this discussion later. It seems that
>>  > > >
>>  > > > beginning
>>  > > > > > > > of November is good time for it.
>>  > > > > > > >
>>  > > > > > > > On Mon, Sep 23, 2019 at 5:37 PM Alexey Zinoviev <
>>  > > >
>>  > > > zaleslaw@gmail.com> wrote:
>>  > > > > > > > >
>>  > > > > > > > > Nikolay Izhikov, ok, let's arrange the talk in ASF slack
>>  > between
>>  > > >
>>  > > > 16 and 19
>>  > > > > > > > > MSK, is it possible?
>>  > > > > > > > >
>>  > > > > > > > > пн, 23 сент. 2019 г. в 17:35, Alexey Zinoviev <
>>  > > >
>>  > > > zaleslaw@gmail.com>:
>>  > > > > > > > >
>>  > > > > > > > > > Ok, I'll clarify the situation
>>  > > > > > > > > >
>>  > > > > > > > > > 1. Currently, the ML module is like a black box for me.
>>  > What
>>  > > >
>>  > > > exactly
>>  > > > > > > > > > we are expected to get by the code freeze date? Do we have
>>  > > >
>>  > > > tickets we
>>  > > > > > > > > > should address to?
>>  > > > > > > > > >
>>  > > > > > > > > > - Yes, we have a few epics that are not finished yet, due
>>  > to
>>  > > >
>>  > > > limited free
>>  > > > > > > > > > time the planned dates were written earlier
>>  > > > > > > > > >
>>  > > > > > > > > > 2. I think we can move code freeze date to December 11-th
>>  > but,
>>  > > >
>>  > > > from
>>  > > > > > > > > > your side, do you think that 2-weeks of stabilization and

[jira] [Created] (IGNITE-12227) Default auto-adjust baseline enabled flag calculated incorrectly in some cases

[Anton Kalashnikov (Jira)]

Anton Kalashnikov created IGNITE-12227:
--

 Summary: Default auto-adjust baseline enabled flag calculated 
incorrectly in some cases
 Key: IGNITE-12227
 URL: https://issues.apache.org/jira/browse/IGNITE-12227
 Project: Ignite
  Issue Type: Bug
Reporter: Anton Kalashnikov
Assignee: Anton Kalashnikov


baselineAutoAdjustEnabled can be been different on different nodes because of 
the calculation of default value happening locally on each node and including 
only local configuration. It issue can happen by the following reasons:
*  If IGNITE_BASELINE_AUTO_ADJUST_ENABLED flag set to a different value on 
different nodes it leads to cluster hanging due to baseline calculation 
finishing with the unpredictable state on each node.
* if cluster in mixed mode(included in-memory and persistent nodes) sometimes 
flag is set to a different value due to calculation doesn't consider remote 
nodes configuration.

Possible solution(both points required):
* Get rid of IGNITE_BASELINE_AUTO_ADJUST_ENABLED and replace it by the explicit 
call of IgniteCluster#baselineAutoAdjustEnabled where it required(test only).
* Calculating default value on the first started node as early as 
possible(instead of activation) and this value always should be set to 
distributed metastorage(unlike it happening now). It means that instead of 
awaiting activation, the default value would be calculated by the first started 
node.




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

[jira] [Created] (IGNITE-12226) Improve BinaryObjectException message

[Kirill Tkalenko (Jira)]

Kirill Tkalenko created IGNITE-12226:


 Summary: Improve BinaryObjectException message
 Key: IGNITE-12226
 URL: https://issues.apache.org/jira/browse/IGNITE-12226
 Project: Ignite
  Issue Type: Improvement
Reporter: Kirill Tkalenko
Assignee: Kirill Tkalenko
 Fix For: 2.8


We are getting the following exception in case of different type IDs:
{noformat}
org.apache.ignite.binary.BinaryObjectException: Failed to get field because 
type ID of passed object differs from type ID this BinaryField belongs to 
[expected=-635374417, actual=1778229603]
 at 
org.apache.ignite.internal.binary.BinaryFieldImpl.fieldOrder(BinaryFieldImpl.java:287)
 at 
org.apache.ignite.internal.binary.BinaryFieldImpl.value(BinaryFieldImpl.java:109)
 at 
org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.fieldValue(QueryBinaryProperty.java:220)
 at 
org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.value(QueryBinaryProperty.java:116)
 at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2RowDescriptor.columnValue(GridH2RowDescriptor.java:331)
 at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue0(GridH2KeyValueRowOnheap.java:122)
 at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue(GridH2KeyValueRowOnheap.java:106)
 at 
org.apache.ignite.internal.processors.query.h2.database.H2Tree.compare(H2Tree.java:350)
 at 
org.apache.ignite.internal.processors.query.h2.database.H2Tree.compare(H2Tree.java:56)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.compare(BPlusTree.java:4614)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findInsertionPoint(BPlusTree.java:4534)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$1300(BPlusTree.java:92)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run0(BPlusTree.java:296)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:4967)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run(BPlusTree.java:276)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:4952)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readPage(PageHandler.java:161)
 at 
org.apache.ignite.internal.processors.cache.persistence.DataStructure.read(DataStructure.java:348)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putDown(BPlusTree.java:2450)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2203)
{noformat}

This message isn't informative. We should print more detailes about types, for 
example classname, class structure (if applicable), which field in class we 
tried to read.



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

Please grant jira-user privilege to me.

[Ken Cheng]

Hi dev,

Right now I am working on

https://issues.apache.org/jira/browse/IGNITE-11008
https://issues.apache.org/jira/browse/IGNITE-11868
https://issues.apache.org/jira/browse/IGNITE-12088
https://issues.apache.org/jira/browse/IGNITE-11976



most of them are ready for review.

Can someone grant me 'jira-user' privilege to me. As I need to change the
status to "patchable" for further processing.

Thanks

[image: image.png]

Thanks,
Ken Cheng

Re: [IEP-35] Monitoring & Profiling. Phase 2

[Andrey Gura]

Alexey,

Yes, system view must be enabled by default and must not have any
enable/disable features. As I told early, system views is on demand
feature and views don't consume any resources while not requested.

On Wed, Sep 18, 2019 at 4:10 PM Alex Plehanov  wrote:
>
> One more point to discuss: Wouldn't it be better to have enabled system
> views by default?
> To enable views admin must restart the node, sometimes it's an issue.
> Views cost almost nothing in terms of performance until they are explicitly
> requested, so is their a reason to disable views by default?
>
> вт, 17 сент. 2019 г. в 12:48, Alexey Goncharuk :
>
> > Folks,
> >
> > I honestly tried to follow the discussion, but I think that I lost the
> > point of the debate. Should we try to exploit the newly introduced slack to
> > discuss the change and then send a follow-up here?
> >
> > --AG
> >

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

[Andrey Gura]

Sergey,

As I know, scope freeze is not announced yet.

On Tue, Sep 24, 2019 at 4:41 PM Sergey Antonov
 wrote:
>
> Hi, I would add to release scope my ticket [1].
>
> Any objections?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12225
>
> вт, 24 сент. 2019 г. в 09:21, Nikolay Izhikov :
>
> > > merge to master only fully finished features
> >
> > It's already true for Ignite master branch.
> >
> >
> > В Вт, 24/09/2019 в 09:03 +0300, Alexey Zinoviev пишет:
> > > The planned before 2_3 months release dates are good defender from
> > > partially merged features, In my opinion
> > >
> > > Or we should have Master and dev branch separetely, and merge to master
> > > only fully finished features
> > >
> > > пн, 23 сент. 2019 г., 20:27 Maxim Muzafarov :
> > >
> > > > Andrey,
> > > >
> > > > Agree with you. It can affect the user impression.
> > > >
> > > > Can you advise, how can we guarantee in our case when we complete with
> > > > current partially merged features that someone will not partially
> > > > merge the new one? Should we monitor the master branch commits for
> > > > such purpose?
> > > >
> > > > On Mon, 23 Sep 2019 at 20:18, Andrey Gura  wrote:
> > > > >
> > > > > Maxim,
> > > > >
> > > > > > > From my point, if some components will not be ready by
> > > > > > > previously discussed `scope freeze` date it is absolutely OK to
> > > > > > > perform the next (e.g. 2.8.1, 2.8.2) releases.
> > > > >
> > > > > It is good approach if partial implemented features aren't merged to
> > > > > master branch. Unfortunately this is not our case.
> > > > >
> > > > > I don't see any reasons to force new Apache Ignite release. Time is
> > > > > not driver for release. If we want release Ignite periodically we
> > must
> > > > > significantly review the process. And most valuable change in this
> > > > > process is feature branches that will not block new release by
> > design.
> > > > >
> > > > > On Mon, Sep 23, 2019 at 8:12 PM Andrey Gura 
> > wrote:
> > > > > >
> > > > > > > > From my point of view monitoring isn't ready for release.
> > > > > > > Can you clarify, what exactly is not ready?
> > > > > > > Can we track planned changes somehow?
> > > > > >
> > > > > > We have too many not resolved tickets under IEP-35 label [1]. Also
> > it
> > > > > > makes sense to do some usability testing: JMX beans interfaces,
> > system
> > > > > > views, etc.
> > > > > >
> > > > > >
> > > > > > [1]
> > https://issues.apache.org/jira/issues/?jql=labels%20%3D%20IEP-35
> > > > > >
> > > > > > On Mon, Sep 23, 2019 at 6:04 PM Nikolay Izhikov <
> > nizhi...@apache.org>
> > > >
> > > > wrote:
> > > > > > >
> > > > > > > Hello, Andrey.
> > > > > > >
> > > > > > > > From my point of view monitoring isn't ready for release.
> > > > > > >
> > > > > > > Can you clarify, what exactly is not ready?
> > > > > > > Can we track planned changes somehow?
> > > > > > >
> > > > > > >
> > > > > > > В Пн, 23/09/2019 в 17:59 +0300, Andrey Gura пишет:
> > > > > > > > Igniters,
> > > > > > > >
> > > > > > > > From my point of view monitoring isn't ready for release. So it
> > > >
> > > > would
> > > > > > > > be great to return to this discussion later. It seems that
> > > >
> > > > beginning
> > > > > > > > of November is good time for it.
> > > > > > > >
> > > > > > > > On Mon, Sep 23, 2019 at 5:37 PM Alexey Zinoviev <
> > > >
> > > > zaleslaw@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Nikolay Izhikov, ok, let's arrange the talk in ASF slack
> > between
> > > >
> > > > 16 and 19
> > > > > > > > > MSK, is it possible?
> > > > > > > > >
> > > > > > > > > пн, 23 сент. 2019 г. в 17:35, Alexey Zinoviev <
> > > >
> > > > zaleslaw@gmail.com>:
> > > > > > > > >
> > > > > > > > > > Ok, I'll clarify the situation
> > > > > > > > > >
> > > > > > > > > > 1. Currently, the ML module is like a black box for me.
> > What
> > > >
> > > > exactly
> > > > > > > > > > we are expected to get by the code freeze date? Do we have
> > > >
> > > > tickets we
> > > > > > > > > > should address to?
> > > > > > > > > >
> > > > > > > > > > - Yes, we have a few epics that are not finished yet, due
> > to
> > > >
> > > > limited free
> > > > > > > > > > time the planned dates were written earlier
> > > > > > > > > >
> > > > > > > > > > 2. I think we can move code freeze date to December 11-th
> > but,
> > > >
> > > > from
> > > > > > > > > > your side, do you think that 2-weeks of stabilization and
> > > >
> > > > regression
> > > > > > > > > > will be enough for the master branch living without release
> > > >
> > > > for a
> > > > > > > > > > year?
> > > > > > > > > >
> > > > > > > > > > Ok, I've ready to move code freeze to your dates but not
> > to 1
> > > >
> > > > November, it
> > > > > > > > > > sounds weird (why we should go so fast if haven't released
> > > >
> > > > during the year)
> > > > > > > > > > I'm against fast releasing without planned dates.
> > > > > > > > > >
> > > > > > > > > > 3. What do you think about that we will make the huge 

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

[Andrey Gura]

Alexey,

> The planned before 2_3 months release dates are good defender from
> partially merged features, In my opinion

Agree. But it doesn't protect from cases when we have something in
progress and partially merged to the master branch.

> Or we should have Master and dev branch separetely, and merge to master
> only fully finished features

Definitely agree. But... Yes, BUT again :) We need some process for
agreement about feature readiness.

On Tue, Sep 24, 2019 at 9:04 AM Alexey Zinoviev  wrote:
>
> The planned before 2_3 months release dates are good defender from
> partially merged features, In my opinion
>
> Or we should have Master and dev branch separetely, and merge to master
> only fully finished features
>
> пн, 23 сент. 2019 г., 20:27 Maxim Muzafarov :
>
> > Andrey,
> >
> > Agree with you. It can affect the user impression.
> >
> > Can you advise, how can we guarantee in our case when we complete with
> > current partially merged features that someone will not partially
> > merge the new one? Should we monitor the master branch commits for
> > such purpose?
> >
> > On Mon, 23 Sep 2019 at 20:18, Andrey Gura  wrote:
> > >
> > > Maxim,
> > >
> > > >> From my point, if some components will not be ready by
> > > >> previously discussed `scope freeze` date it is absolutely OK to
> > > >> perform the next (e.g. 2.8.1, 2.8.2) releases.
> > >
> > > It is good approach if partial implemented features aren't merged to
> > > master branch. Unfortunately this is not our case.
> > >
> > > I don't see any reasons to force new Apache Ignite release. Time is
> > > not driver for release. If we want release Ignite periodically we must
> > > significantly review the process. And most valuable change in this
> > > process is feature branches that will not block new release by design.
> > >
> > > On Mon, Sep 23, 2019 at 8:12 PM Andrey Gura  wrote:
> > > >
> > > > >> From my point of view monitoring isn't ready for release.
> > > >
> > > > > Can you clarify, what exactly is not ready?
> > > > > Can we track planned changes somehow?
> > > >
> > > > We have too many not resolved tickets under IEP-35 label [1]. Also it
> > > > makes sense to do some usability testing: JMX beans interfaces, system
> > > > views, etc.
> > > >
> > > >
> > > > [1] https://issues.apache.org/jira/issues/?jql=labels%20%3D%20IEP-35
> > > >
> > > > On Mon, Sep 23, 2019 at 6:04 PM Nikolay Izhikov 
> > wrote:
> > > > >
> > > > > Hello, Andrey.
> > > > >
> > > > > > From my point of view monitoring isn't ready for release.
> > > > >
> > > > > Can you clarify, what exactly is not ready?
> > > > > Can we track planned changes somehow?
> > > > >
> > > > >
> > > > > В Пн, 23/09/2019 в 17:59 +0300, Andrey Gura пишет:
> > > > > > Igniters,
> > > > > >
> > > > > > From my point of view monitoring isn't ready for release. So it
> > would
> > > > > > be great to return to this discussion later. It seems that
> > beginning
> > > > > > of November is good time for it.
> > > > > >
> > > > > > On Mon, Sep 23, 2019 at 5:37 PM Alexey Zinoviev <
> > zaleslaw@gmail.com> wrote:
> > > > > > >
> > > > > > > Nikolay Izhikov, ok, let's arrange the talk in ASF slack between
> > 16 and 19
> > > > > > > MSK, is it possible?
> > > > > > >
> > > > > > > пн, 23 сент. 2019 г. в 17:35, Alexey Zinoviev <
> > zaleslaw@gmail.com>:
> > > > > > >
> > > > > > > > Ok, I'll clarify the situation
> > > > > > > >
> > > > > > > > 1. Currently, the ML module is like a black box for me. What
> > exactly
> > > > > > > > we are expected to get by the code freeze date? Do we have
> > tickets we
> > > > > > > > should address to?
> > > > > > > >
> > > > > > > > - Yes, we have a few epics that are not finished yet, due to
> > limited free
> > > > > > > > time the planned dates were written earlier
> > > > > > > >
> > > > > > > > 2. I think we can move code freeze date to December 11-th but,
> > from
> > > > > > > > your side, do you think that 2-weeks of stabilization and
> > regression
> > > > > > > > will be enough for the master branch living without release
> > for a
> > > > > > > > year?
> > > > > > > >
> > > > > > > > Ok, I've ready to move code freeze to your dates but not to 1
> > November, it
> > > > > > > > sounds weird (why we should go so fast if haven't released
> > during the year)
> > > > > > > > I'm against fast releasing without planned dates.
> > > > > > > >
> > > > > > > > 3. What do you think about that we will make the huge 2.8
> > release in
> > > > > > > > November with long period of branch stabilization and an
> > additional
> > > > > > > > 2.8.1 release with ML component in January? Such an approach
> > have some
> > > > > > > > advantages like we will not rush the development of ML
> > components.
> > > > > > > >
> > > > > > > > The best idea here is ability to merge the last ML changes
> > during
> > > > > > > > stabilization period (bug fixing, tests and so on), is it ok
> > for you?
> > > > > > > >
> > > > > > > > 2.8.1 could be a good point, but 

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

[Andrey Gura]

Maxim,

We can't do it because there is no strong rules about the process.

But I have an idea how we can release 2.8 faster (but I still don't
see any reasons for forcing release).

We can create release branch before first IEP-35 related commit and
cherry-pick all commits from master branch to release branch. Note, it
is just idea. In previous post Alexey Zinoviev asked to postpone the
release.

About new big features... I suggest introducing a new process which is
similar to JDK in some aspects: only fully completed feature can be
merged to master. If feature is not ready for release time it should
be moved to the next release.

On Mon, Sep 23, 2019 at 8:27 PM Maxim Muzafarov  wrote:
>
> Andrey,
>
> Agree with you. It can affect the user impression.
>
> Can you advise, how can we guarantee in our case when we complete with
> current partially merged features that someone will not partially
> merge the new one? Should we monitor the master branch commits for
> such purpose?
>
> On Mon, 23 Sep 2019 at 20:18, Andrey Gura  wrote:
> >
> > Maxim,
> >
> > >> From my point, if some components will not be ready by
> > >> previously discussed `scope freeze` date it is absolutely OK to
> > >> perform the next (e.g. 2.8.1, 2.8.2) releases.
> >
> > It is good approach if partial implemented features aren't merged to
> > master branch. Unfortunately this is not our case.
> >
> > I don't see any reasons to force new Apache Ignite release. Time is
> > not driver for release. If we want release Ignite periodically we must
> > significantly review the process. And most valuable change in this
> > process is feature branches that will not block new release by design.
> >
> > On Mon, Sep 23, 2019 at 8:12 PM Andrey Gura  wrote:
> > >
> > > >> From my point of view monitoring isn't ready for release.
> > >
> > > > Can you clarify, what exactly is not ready?
> > > > Can we track planned changes somehow?
> > >
> > > We have too many not resolved tickets under IEP-35 label [1]. Also it
> > > makes sense to do some usability testing: JMX beans interfaces, system
> > > views, etc.
> > >
> > >
> > > [1] https://issues.apache.org/jira/issues/?jql=labels%20%3D%20IEP-35
> > >
> > > On Mon, Sep 23, 2019 at 6:04 PM Nikolay Izhikov  
> > > wrote:
> > > >
> > > > Hello, Andrey.
> > > >
> > > > > From my point of view monitoring isn't ready for release.
> > > >
> > > > Can you clarify, what exactly is not ready?
> > > > Can we track planned changes somehow?
> > > >
> > > >
> > > > В Пн, 23/09/2019 в 17:59 +0300, Andrey Gura пишет:
> > > > > Igniters,
> > > > >
> > > > > From my point of view monitoring isn't ready for release. So it would
> > > > > be great to return to this discussion later. It seems that beginning
> > > > > of November is good time for it.
> > > > >
> > > > > On Mon, Sep 23, 2019 at 5:37 PM Alexey Zinoviev 
> > > > >  wrote:
> > > > > >
> > > > > > Nikolay Izhikov, ok, let's arrange the talk in ASF slack between 16 
> > > > > > and 19
> > > > > > MSK, is it possible?
> > > > > >
> > > > > > пн, 23 сент. 2019 г. в 17:35, Alexey Zinoviev 
> > > > > > :
> > > > > >
> > > > > > > Ok, I'll clarify the situation
> > > > > > >
> > > > > > > 1. Currently, the ML module is like a black box for me. What 
> > > > > > > exactly
> > > > > > > we are expected to get by the code freeze date? Do we have 
> > > > > > > tickets we
> > > > > > > should address to?
> > > > > > >
> > > > > > > - Yes, we have a few epics that are not finished yet, due to 
> > > > > > > limited free
> > > > > > > time the planned dates were written earlier
> > > > > > >
> > > > > > > 2. I think we can move code freeze date to December 11-th but, 
> > > > > > > from
> > > > > > > your side, do you think that 2-weeks of stabilization and 
> > > > > > > regression
> > > > > > > will be enough for the master branch living without release for a
> > > > > > > year?
> > > > > > >
> > > > > > > Ok, I've ready to move code freeze to your dates but not to 1 
> > > > > > > November, it
> > > > > > > sounds weird (why we should go so fast if haven't released during 
> > > > > > > the year)
> > > > > > > I'm against fast releasing without planned dates.
> > > > > > >
> > > > > > > 3. What do you think about that we will make the huge 2.8 release 
> > > > > > > in
> > > > > > > November with long period of branch stabilization and an 
> > > > > > > additional
> > > > > > > 2.8.1 release with ML component in January? Such an approach have 
> > > > > > > some
> > > > > > > advantages like we will not rush the development of ML components.
> > > > > > >
> > > > > > > The best idea here is ability to merge the last ML changes during
> > > > > > > stabilization period (bug fixing, tests and so on), is it ok for 
> > > > > > > you?
> > > > > > >
> > > > > > > 2.8.1 could be a good point, but remind you guys, the normal 
> > > > > > > practice to
> > > > > > > plan release for 2 months and ask another maintainers about 
> > > > > > > another modules
> > > > > > > maybe the need 

Re: [DISCUSSION] Single point in API for changing cluster state.

[Sergey Antonov]

Andrey,

> What are state transitions valid?
Now all transitions are valid, except INACTIVE -> READ-ONLY. This
transition will be fixed under [1]

> Regarding state names, as I understand, all transitions are valid from
any to any of 3 states.
Yes, see my comment above.

> But, regarding on console.sh command it is not obvious.
Yes. It's one of points why we should have single command in control.sh.

> What effect will --read-only-on and --read-only-off commands have if
current state is INACTIVE ?
--read-only-on - cluster will be activated in read-only mode
--read-only-off - cluster will be activated. I.e --read-only-off will have
the same effect as --activate
[1] https://issues.apache.org/jira/browse/IGNITE-11866

вт, 24 сент. 2019 г. в 16:40, Andrey Mashenkov :

> Sergey,
>
> What are state transitions valid?
> For now we have only 2 states (active and inactive) and possible
> transitions are obvious Active <--> Inactive.
>
> Regarding state names, as I understand, all transitions are valid from any
> to any of 3 states.
> But, regarding on console.sh command it is not obvious.
> What effect will --read-only-on and --read-only-off commands have if
> current state is INACTIVE ?
>
>
> On Tue, Sep 24, 2019 at 4:23 PM Sergey Antonov 
> wrote:
>
> > Also, I would add IGNITE-12225
> >  ticket to 2.8
> release
> > scope.
> >
> > вт, 24 сент. 2019 г. в 16:18, Sergey Antonov  >:
> >
> > > Hi, Igniters!
> > >
> > > We have 3 cluster states at the moment: inactive, active, read-only.
> > >
> > > For getting current cluster state and changing them IgniteCluster has
> > > methods:
> > >
> > >- boolean active(), void active(boolean active) - for cluster
> > >activation/deactivation
> > >- boolean readOnly(), void readOnly(boolean readOnly) - for
> > >enabling/disabling read-only mode.
> > >
> > > Also we have control.sh commans for changing cluster state:
> > >
> > >- --activate
> > >- --deactivate
> > >- --read-only-on
> > >- --read-only-off
> > >
> > > For me current API looks unuseful. My proposal:
> > >
> > >1. Create enum ClusterState with values ACTIVE, INACTIVE, READ-ONLY.
> > >2. Add methods to IgniteCluster:
> > >   - ClusterState state() returns current cluster state
> > >   - void state(ClusterState newState) changes cluster state to
> > >   newState state
> > >3. Mark as deprecated the following methods in IgniteCluster:
> boolean
> > >active(), void active(boolean active),
> > >4. Add new command to control.sh: control.sh --set-state
> > >(ACTIVE|INACTIVE|READ-ONLY)
> > >5. Add warn message that command is depricated in control.sh.
> > >Commands: --activate, --deactivate, --read-only-on, --read-only-off
> > >
> > >
> > > I created ticket [1] in Jira for it.
> > >
> > > What do you think about my proposal?
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-12225
> > > --
> > > BR, Sergey Antonov
> > >
> >
> >
> > --
> > BR, Sergey Antonov
> >
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>


-- 
BR, Sergey Antonov

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

[Sergey Antonov]

Hi, I would add to release scope my ticket [1].

Any objections?

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

вт, 24 сент. 2019 г. в 09:21, Nikolay Izhikov :

> > merge to master only fully finished features
>
> It's already true for Ignite master branch.
>
>
> В Вт, 24/09/2019 в 09:03 +0300, Alexey Zinoviev пишет:
> > The planned before 2_3 months release dates are good defender from
> > partially merged features, In my opinion
> >
> > Or we should have Master and dev branch separetely, and merge to master
> > only fully finished features
> >
> > пн, 23 сент. 2019 г., 20:27 Maxim Muzafarov :
> >
> > > Andrey,
> > >
> > > Agree with you. It can affect the user impression.
> > >
> > > Can you advise, how can we guarantee in our case when we complete with
> > > current partially merged features that someone will not partially
> > > merge the new one? Should we monitor the master branch commits for
> > > such purpose?
> > >
> > > On Mon, 23 Sep 2019 at 20:18, Andrey Gura  wrote:
> > > >
> > > > Maxim,
> > > >
> > > > > > From my point, if some components will not be ready by
> > > > > > previously discussed `scope freeze` date it is absolutely OK to
> > > > > > perform the next (e.g. 2.8.1, 2.8.2) releases.
> > > >
> > > > It is good approach if partial implemented features aren't merged to
> > > > master branch. Unfortunately this is not our case.
> > > >
> > > > I don't see any reasons to force new Apache Ignite release. Time is
> > > > not driver for release. If we want release Ignite periodically we
> must
> > > > significantly review the process. And most valuable change in this
> > > > process is feature branches that will not block new release by
> design.
> > > >
> > > > On Mon, Sep 23, 2019 at 8:12 PM Andrey Gura 
> wrote:
> > > > >
> > > > > > > From my point of view monitoring isn't ready for release.
> > > > > > Can you clarify, what exactly is not ready?
> > > > > > Can we track planned changes somehow?
> > > > >
> > > > > We have too many not resolved tickets under IEP-35 label [1]. Also
> it
> > > > > makes sense to do some usability testing: JMX beans interfaces,
> system
> > > > > views, etc.
> > > > >
> > > > >
> > > > > [1]
> https://issues.apache.org/jira/issues/?jql=labels%20%3D%20IEP-35
> > > > >
> > > > > On Mon, Sep 23, 2019 at 6:04 PM Nikolay Izhikov <
> nizhi...@apache.org>
> > >
> > > wrote:
> > > > > >
> > > > > > Hello, Andrey.
> > > > > >
> > > > > > > From my point of view monitoring isn't ready for release.
> > > > > >
> > > > > > Can you clarify, what exactly is not ready?
> > > > > > Can we track planned changes somehow?
> > > > > >
> > > > > >
> > > > > > В Пн, 23/09/2019 в 17:59 +0300, Andrey Gura пишет:
> > > > > > > Igniters,
> > > > > > >
> > > > > > > From my point of view monitoring isn't ready for release. So it
> > >
> > > would
> > > > > > > be great to return to this discussion later. It seems that
> > >
> > > beginning
> > > > > > > of November is good time for it.
> > > > > > >
> > > > > > > On Mon, Sep 23, 2019 at 5:37 PM Alexey Zinoviev <
> > >
> > > zaleslaw@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Nikolay Izhikov, ok, let's arrange the talk in ASF slack
> between
> > >
> > > 16 and 19
> > > > > > > > MSK, is it possible?
> > > > > > > >
> > > > > > > > пн, 23 сент. 2019 г. в 17:35, Alexey Zinoviev <
> > >
> > > zaleslaw@gmail.com>:
> > > > > > > >
> > > > > > > > > Ok, I'll clarify the situation
> > > > > > > > >
> > > > > > > > > 1. Currently, the ML module is like a black box for me.
> What
> > >
> > > exactly
> > > > > > > > > we are expected to get by the code freeze date? Do we have
> > >
> > > tickets we
> > > > > > > > > should address to?
> > > > > > > > >
> > > > > > > > > - Yes, we have a few epics that are not finished yet, due
> to
> > >
> > > limited free
> > > > > > > > > time the planned dates were written earlier
> > > > > > > > >
> > > > > > > > > 2. I think we can move code freeze date to December 11-th
> but,
> > >
> > > from
> > > > > > > > > your side, do you think that 2-weeks of stabilization and
> > >
> > > regression
> > > > > > > > > will be enough for the master branch living without release
> > >
> > > for a
> > > > > > > > > year?
> > > > > > > > >
> > > > > > > > > Ok, I've ready to move code freeze to your dates but not
> to 1
> > >
> > > November, it
> > > > > > > > > sounds weird (why we should go so fast if haven't released
> > >
> > > during the year)
> > > > > > > > > I'm against fast releasing without planned dates.
> > > > > > > > >
> > > > > > > > > 3. What do you think about that we will make the huge 2.8
> > >
> > > release in
> > > > > > > > > November with long period of branch stabilization and an
> > >
> > > additional
> > > > > > > > > 2.8.1 release with ML component in January? Such an
> approach
> > >
> > > have some
> > > > > > > > > advantages like we will not rush the development of ML
> > >
> > > components.
> > > > > > > > >
> > > > > > > > > The best idea here is ability to 

Re: [DISCUSSION] Single point in API for changing cluster state.

[Andrey Mashenkov]

Sergey,

What are state transitions valid?
For now we have only 2 states (active and inactive) and possible
transitions are obvious Active <--> Inactive.

Regarding state names, as I understand, all transitions are valid from any
to any of 3 states.
But, regarding on console.sh command it is not obvious.
What effect will --read-only-on and --read-only-off commands have if
current state is INACTIVE ?


On Tue, Sep 24, 2019 at 4:23 PM Sergey Antonov 
wrote:

> Also, I would add IGNITE-12225
>  ticket to 2.8 release
> scope.
>
> вт, 24 сент. 2019 г. в 16:18, Sergey Antonov :
>
> > Hi, Igniters!
> >
> > We have 3 cluster states at the moment: inactive, active, read-only.
> >
> > For getting current cluster state and changing them IgniteCluster has
> > methods:
> >
> >- boolean active(), void active(boolean active) - for cluster
> >activation/deactivation
> >- boolean readOnly(), void readOnly(boolean readOnly) - for
> >enabling/disabling read-only mode.
> >
> > Also we have control.sh commans for changing cluster state:
> >
> >- --activate
> >- --deactivate
> >- --read-only-on
> >- --read-only-off
> >
> > For me current API looks unuseful. My proposal:
> >
> >1. Create enum ClusterState with values ACTIVE, INACTIVE, READ-ONLY.
> >2. Add methods to IgniteCluster:
> >   - ClusterState state() returns current cluster state
> >   - void state(ClusterState newState) changes cluster state to
> >   newState state
> >3. Mark as deprecated the following methods in IgniteCluster: boolean
> >active(), void active(boolean active),
> >4. Add new command to control.sh: control.sh --set-state
> >(ACTIVE|INACTIVE|READ-ONLY)
> >5. Add warn message that command is depricated in control.sh.
> >Commands: --activate, --deactivate, --read-only-on, --read-only-off
> >
> >
> > I created ticket [1] in Jira for it.
> >
> > What do you think about my proposal?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-12225
> > --
> > BR, Sergey Antonov
> >
>
>
> --
> BR, Sergey Antonov
>


-- 
Best regards,
Andrey V. Mashenkov

Re: [DISCUSSION] Single point in API for changing cluster state.

[Sergey Antonov]

Also, I would add IGNITE-12225
 ticket to 2.8 release
scope.

вт, 24 сент. 2019 г. в 16:18, Sergey Antonov :

> Hi, Igniters!
>
> We have 3 cluster states at the moment: inactive, active, read-only.
>
> For getting current cluster state and changing them IgniteCluster has
> methods:
>
>- boolean active(), void active(boolean active) - for cluster
>activation/deactivation
>- boolean readOnly(), void readOnly(boolean readOnly) - for
>enabling/disabling read-only mode.
>
> Also we have control.sh commans for changing cluster state:
>
>- --activate
>- --deactivate
>- --read-only-on
>- --read-only-off
>
> For me current API looks unuseful. My proposal:
>
>1. Create enum ClusterState with values ACTIVE, INACTIVE, READ-ONLY.
>2. Add methods to IgniteCluster:
>   - ClusterState state() returns current cluster state
>   - void state(ClusterState newState) changes cluster state to
>   newState state
>3. Mark as deprecated the following methods in IgniteCluster: boolean
>active(), void active(boolean active),
>4. Add new command to control.sh: control.sh --set-state
>(ACTIVE|INACTIVE|READ-ONLY)
>5. Add warn message that command is depricated in control.sh.
>Commands: --activate, --deactivate, --read-only-on, --read-only-off
>
>
> I created ticket [1] in Jira for it.
>
> What do you think about my proposal?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12225
> --
> BR, Sergey Antonov
>


-- 
BR, Sergey Antonov

[DISCUSSION] Single point in API for changing cluster state.

[Sergey Antonov]

Hi, Igniters!

We have 3 cluster states at the moment: inactive, active, read-only.

For getting current cluster state and changing them IgniteCluster has
methods:

   - boolean active(), void active(boolean active) - for cluster
   activation/deactivation
   - boolean readOnly(), void readOnly(boolean readOnly) - for
   enabling/disabling read-only mode.

Also we have control.sh commans for changing cluster state:

   - --activate
   - --deactivate
   - --read-only-on
   - --read-only-off

For me current API looks unuseful. My proposal:

   1. Create enum ClusterState with values ACTIVE, INACTIVE, READ-ONLY.
   2. Add methods to IgniteCluster:
  - ClusterState state() returns current cluster state
  - void state(ClusterState newState) changes cluster state to newState
   state
   3. Mark as deprecated the following methods in IgniteCluster: boolean
   active(), void active(boolean active),
   4. Add new command to control.sh: control.sh --set-state
   (ACTIVE|INACTIVE|READ-ONLY)
   5. Add warn message that command is depricated in control.sh. Commands:
   --activate, --deactivate, --read-only-on, --read-only-off


I created ticket [1] in Jira for it.

What do you think about my proposal?

[1] https://issues.apache.org/jira/browse/IGNITE-12225
-- 
BR, Sergey Antonov

[jira] [Created] (IGNITE-12225) Add enum for cluster state

[Sergey Antonov (Jira)]

Sergey Antonov created IGNITE-12225:
---

 Summary: Add enum for cluster state
 Key: IGNITE-12225
 URL: https://issues.apache.org/jira/browse/IGNITE-12225
 Project: Ignite
  Issue Type: Improvement
Reporter: Sergey Antonov
Assignee: Sergey Antonov
 Fix For: 2.8


We have 3 cluster states at the moment: inactive, active, read-only. 

For getting current cluster state and changing them {{IgniteCluster}} has 
methods:
* {{boolean active()}}, {{void active(boolean active)}} - for cluster 
activation/deactivation 
* {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for 
enabling/disabling read-only mode.

Also we have control.sh commans for changing cluster state:
* {{--activate}}
* {{--deactivate}}
* {{--read-only-on}}
* {{--read-only-off}}

For me current API looks unuseful. My proposal:
# Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}}, 
{{READ-ONLY}}.
# Add methods to {{IgniteCluster}}:
## {{ClusterState state()}} returns current cluster state
## {{void state(ClusterState newState)}} changes cluster state to {{newState}} 
state
## Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean 
active()}}, {{void active(boolean active)}}, 
## Add new command to control.sh: {{control.sh --set-state 
(ACTIVE|INACTIVE|READ-ONLY)}}
## Add warn message that command is depricated in control.sh. Commands: 
{{--activate}}, {{--deactivate}}, {{--read-only-on}}, {{--read-only-off}}




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

JavaDoc for Event's subjectId methods

[Denis Garus]

Hello, Igniters!

Some events contain the subjectId method, for example, TaskEvent#subjectId.
The JavaDoc for this method is:
"Gets security subject ID initiated this task event, if available.
This property is not available for GridEventType#EVT_TASK_SESSION_ATTR_SET
task event.
Subject ID will be set either to node ID or client ID initiated task
execution."

I think It's wrong. The main point is a subject id doesn't have any sense
if IgniteSecurity is disabled.
However, if IgniteSecurity is enabled, the method must return the subject
id from the current security context.
Thus, the description (and behavior) of the method should be the following:
Gets security subject ID initiated this task event if IgniteSecurity is
enabled, otherwise returns null.

The same is actual for CacheEvent, CacheQueryExecutedEvent and
CacheQueryReadEvent.

If there are no objections, I am going to create a relevant issue in Jira.

Improvements for P2P class loading

[Denis Garus]

Igniters!

I would like to propose a few improvements for the P2P class loading
feature in Ignite.
These improvements have the aim to reduce the number of requests that may
be needing to get a class on a remote node.

a. We should send a request for a class to the node initiator firstly.
Currently, GridDeploymentClassLoader sends a request for a class to all
participated nodes one by one until it gets a successful response. However,
in most cases, the required byte code would be loaded from the node that
initiates execution. To find out what is the node initiator, we can use the
way that we use to determine a security context to execute a user-defined
code (see GridIoManager#invokeListener). If the node initiator doesn't have
a required class, we should ask other participated nodes as it is currently.

b. Some classes in a single response.
When a required class contains anonymous and/or inner classes, Ignite tries
to get these classes using separate requests. However, we can determine
that case and send data, that we send anyway, in a single response as an
answer for the first request. In this way, we may significantly reduce the
number of communications required for a class loading.

What do you think?

I would like to create a separate task for a. and b.

[jira] [Created] (IGNITE-12224) SQL query system view

[Nikolay Izhikov (Jira)]

Nikolay Izhikov created IGNITE-12224:


 Summary: SQL query system view
 Key: IGNITE-12224
 URL: https://issues.apache.org/jira/browse/IGNITE-12224
 Project: Ignite
  Issue Type: Sub-task
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov


We need to add system view for a SQL queries



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

[jira] [Created] (IGNITE-12223) Create text query, scan query system view

[Nikolay Izhikov (Jira)]

Nikolay Izhikov created IGNITE-12223:


 Summary: Create text query, scan query system view
 Key: IGNITE-12223
 URL: https://issues.apache.org/jira/browse/IGNITE-12223
 Project: Ignite
  Issue Type: Sub-task
Affects Versions: 2.7.6
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov
 Fix For: 2.8


We need to add a system views for 
* Scan queries
* Text queries



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

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

[Nikolay Izhikov]

> merge to master only fully finished features

It's already true for Ignite master branch.


В Вт, 24/09/2019 в 09:03 +0300, Alexey Zinoviev пишет:
> The planned before 2_3 months release dates are good defender from
> partially merged features, In my opinion
> 
> Or we should have Master and dev branch separetely, and merge to master
> only fully finished features
> 
> пн, 23 сент. 2019 г., 20:27 Maxim Muzafarov :
> 
> > Andrey,
> > 
> > Agree with you. It can affect the user impression.
> > 
> > Can you advise, how can we guarantee in our case when we complete with
> > current partially merged features that someone will not partially
> > merge the new one? Should we monitor the master branch commits for
> > such purpose?
> > 
> > On Mon, 23 Sep 2019 at 20:18, Andrey Gura  wrote:
> > > 
> > > Maxim,
> > > 
> > > > > From my point, if some components will not be ready by
> > > > > previously discussed `scope freeze` date it is absolutely OK to
> > > > > perform the next (e.g. 2.8.1, 2.8.2) releases.
> > > 
> > > It is good approach if partial implemented features aren't merged to
> > > master branch. Unfortunately this is not our case.
> > > 
> > > I don't see any reasons to force new Apache Ignite release. Time is
> > > not driver for release. If we want release Ignite periodically we must
> > > significantly review the process. And most valuable change in this
> > > process is feature branches that will not block new release by design.
> > > 
> > > On Mon, Sep 23, 2019 at 8:12 PM Andrey Gura  wrote:
> > > > 
> > > > > > From my point of view monitoring isn't ready for release.
> > > > > Can you clarify, what exactly is not ready?
> > > > > Can we track planned changes somehow?
> > > > 
> > > > We have too many not resolved tickets under IEP-35 label [1]. Also it
> > > > makes sense to do some usability testing: JMX beans interfaces, system
> > > > views, etc.
> > > > 
> > > > 
> > > > [1] https://issues.apache.org/jira/issues/?jql=labels%20%3D%20IEP-35
> > > > 
> > > > On Mon, Sep 23, 2019 at 6:04 PM Nikolay Izhikov 
> > 
> > wrote:
> > > > > 
> > > > > Hello, Andrey.
> > > > > 
> > > > > > From my point of view monitoring isn't ready for release.
> > > > > 
> > > > > Can you clarify, what exactly is not ready?
> > > > > Can we track planned changes somehow?
> > > > > 
> > > > > 
> > > > > В Пн, 23/09/2019 в 17:59 +0300, Andrey Gura пишет:
> > > > > > Igniters,
> > > > > > 
> > > > > > From my point of view monitoring isn't ready for release. So it
> > 
> > would
> > > > > > be great to return to this discussion later. It seems that
> > 
> > beginning
> > > > > > of November is good time for it.
> > > > > > 
> > > > > > On Mon, Sep 23, 2019 at 5:37 PM Alexey Zinoviev <
> > 
> > zaleslaw@gmail.com> wrote:
> > > > > > > 
> > > > > > > Nikolay Izhikov, ok, let's arrange the talk in ASF slack between
> > 
> > 16 and 19
> > > > > > > MSK, is it possible?
> > > > > > > 
> > > > > > > пн, 23 сент. 2019 г. в 17:35, Alexey Zinoviev <
> > 
> > zaleslaw@gmail.com>:
> > > > > > > 
> > > > > > > > Ok, I'll clarify the situation
> > > > > > > > 
> > > > > > > > 1. Currently, the ML module is like a black box for me. What
> > 
> > exactly
> > > > > > > > we are expected to get by the code freeze date? Do we have
> > 
> > tickets we
> > > > > > > > should address to?
> > > > > > > > 
> > > > > > > > - Yes, we have a few epics that are not finished yet, due to
> > 
> > limited free
> > > > > > > > time the planned dates were written earlier
> > > > > > > > 
> > > > > > > > 2. I think we can move code freeze date to December 11-th but,
> > 
> > from
> > > > > > > > your side, do you think that 2-weeks of stabilization and
> > 
> > regression
> > > > > > > > will be enough for the master branch living without release
> > 
> > for a
> > > > > > > > year?
> > > > > > > > 
> > > > > > > > Ok, I've ready to move code freeze to your dates but not to 1
> > 
> > November, it
> > > > > > > > sounds weird (why we should go so fast if haven't released
> > 
> > during the year)
> > > > > > > > I'm against fast releasing without planned dates.
> > > > > > > > 
> > > > > > > > 3. What do you think about that we will make the huge 2.8
> > 
> > release in
> > > > > > > > November with long period of branch stabilization and an
> > 
> > additional
> > > > > > > > 2.8.1 release with ML component in January? Such an approach
> > 
> > have some
> > > > > > > > advantages like we will not rush the development of ML
> > 
> > components.
> > > > > > > > 
> > > > > > > > The best idea here is ability to merge the last ML changes
> > 
> > during
> > > > > > > > stabilization period (bug fixing, tests and so on), is it ok
> > 
> > for you?
> > > > > > > > 
> > > > > > > > 2.8.1 could be a good point, but remind you guys, the normal
> > 
> > practice to
> > > > > > > > plan release for 2 months and ask another maintainers about
> > 
> > another modules
> > > > > > > > maybe the need additional clarification from another
> > 
> > 

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

[Alexey Zinoviev]

The planned before 2_3 months release dates are good defender from
partially merged features, In my opinion

Or we should have Master and dev branch separetely, and merge to master
only fully finished features

пн, 23 сент. 2019 г., 20:27 Maxim Muzafarov :

> Andrey,
>
> Agree with you. It can affect the user impression.
>
> Can you advise, how can we guarantee in our case when we complete with
> current partially merged features that someone will not partially
> merge the new one? Should we monitor the master branch commits for
> such purpose?
>
> On Mon, 23 Sep 2019 at 20:18, Andrey Gura  wrote:
> >
> > Maxim,
> >
> > >> From my point, if some components will not be ready by
> > >> previously discussed `scope freeze` date it is absolutely OK to
> > >> perform the next (e.g. 2.8.1, 2.8.2) releases.
> >
> > It is good approach if partial implemented features aren't merged to
> > master branch. Unfortunately this is not our case.
> >
> > I don't see any reasons to force new Apache Ignite release. Time is
> > not driver for release. If we want release Ignite periodically we must
> > significantly review the process. And most valuable change in this
> > process is feature branches that will not block new release by design.
> >
> > On Mon, Sep 23, 2019 at 8:12 PM Andrey Gura  wrote:
> > >
> > > >> From my point of view monitoring isn't ready for release.
> > >
> > > > Can you clarify, what exactly is not ready?
> > > > Can we track planned changes somehow?
> > >
> > > We have too many not resolved tickets under IEP-35 label [1]. Also it
> > > makes sense to do some usability testing: JMX beans interfaces, system
> > > views, etc.
> > >
> > >
> > > [1] https://issues.apache.org/jira/issues/?jql=labels%20%3D%20IEP-35
> > >
> > > On Mon, Sep 23, 2019 at 6:04 PM Nikolay Izhikov 
> wrote:
> > > >
> > > > Hello, Andrey.
> > > >
> > > > > From my point of view monitoring isn't ready for release.
> > > >
> > > > Can you clarify, what exactly is not ready?
> > > > Can we track planned changes somehow?
> > > >
> > > >
> > > > В Пн, 23/09/2019 в 17:59 +0300, Andrey Gura пишет:
> > > > > Igniters,
> > > > >
> > > > > From my point of view monitoring isn't ready for release. So it
> would
> > > > > be great to return to this discussion later. It seems that
> beginning
> > > > > of November is good time for it.
> > > > >
> > > > > On Mon, Sep 23, 2019 at 5:37 PM Alexey Zinoviev <
> zaleslaw@gmail.com> wrote:
> > > > > >
> > > > > > Nikolay Izhikov, ok, let's arrange the talk in ASF slack between
> 16 and 19
> > > > > > MSK, is it possible?
> > > > > >
> > > > > > пн, 23 сент. 2019 г. в 17:35, Alexey Zinoviev <
> zaleslaw@gmail.com>:
> > > > > >
> > > > > > > Ok, I'll clarify the situation
> > > > > > >
> > > > > > > 1. Currently, the ML module is like a black box for me. What
> exactly
> > > > > > > we are expected to get by the code freeze date? Do we have
> tickets we
> > > > > > > should address to?
> > > > > > >
> > > > > > > - Yes, we have a few epics that are not finished yet, due to
> limited free
> > > > > > > time the planned dates were written earlier
> > > > > > >
> > > > > > > 2. I think we can move code freeze date to December 11-th but,
> from
> > > > > > > your side, do you think that 2-weeks of stabilization and
> regression
> > > > > > > will be enough for the master branch living without release
> for a
> > > > > > > year?
> > > > > > >
> > > > > > > Ok, I've ready to move code freeze to your dates but not to 1
> November, it
> > > > > > > sounds weird (why we should go so fast if haven't released
> during the year)
> > > > > > > I'm against fast releasing without planned dates.
> > > > > > >
> > > > > > > 3. What do you think about that we will make the huge 2.8
> release in
> > > > > > > November with long period of branch stabilization and an
> additional
> > > > > > > 2.8.1 release with ML component in January? Such an approach
> have some
> > > > > > > advantages like we will not rush the development of ML
> components.
> > > > > > >
> > > > > > > The best idea here is ability to merge the last ML changes
> during
> > > > > > > stabilization period (bug fixing, tests and so on), is it ok
> for you?
> > > > > > >
> > > > > > > 2.8.1 could be a good point, but remind you guys, the normal
> practice to
> > > > > > > plan release for 2 months and ask another maintainers about
> another modules
> > > > > > > maybe the need additional clarification from another
> committers.
> > > > > > >
> > > > > > > пн, 23 сент. 2019 г. в 13:35, Nikolay Izhikov <
> nizhi...@apache.org>:
> > > > > > >
> > > > > > > > +1 to start releasing 2.8 in November or even in the end of
> October.
> > > > > > > >
> > > > > > > > Alex, can we schedule some quick meetings in the new Ignite
> Slack chat
> > > > > > > > and discuss all release date details?
> > > > > > > > Wendseday, 25 September is good for you?
> > > > > > > >
> > > > > > > >
> > > > > > > > В Пн, 23/09/2019 в 13:31 +0300, Maxim Muzafarov пишет:
> > > > > > >