Re: [TC RELEASES] Problem with assembling a build

[Maxim Muzafarov]

Petr,

Will you fix the issue [1] soon or we can proceed with the 2.9.1
release manually?

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

On Thu, 10 Dec 2020 at 20:59, Yaroslav Molochkov  wrote:
>
> Thanks, Petr!
>
> I've created a ticket  for
> that issue
>
> On Thu, Dec 10, 2020 at 6:35 PM Petr Ivanov  wrote:
>
> > The problem is with mirroring option for TC VCS root.
> >
> > I think for releases we should redesign release build to require native
> > checked out repository, not mirrored one.
> >
> >
> > > On 10 Dec 2020, at 18:20, Yaroslav Molochkov 
> > wrote:
> > >
> > > Igniters, hello!
> > >
> > > Currently I'm experiencing difficulties with an archive that is built by
> > a
> > > TC job.
> > >
> > > I ran a build job (Apache Ignite / Main) and downloaded artifacts. After
> > > that the script to add a tag to the repository throws an error. Problem
> > is
> > > with git folder, git can't fetch anything:
> > >
> > > error: object directory
> > /opt/buildagent/system/git/git-BF1D6845.git/objects
> > > does not exist; check .git/objects/info/alternates
> > >
> > > error: refs/heads/ignite-2.9 does not point to a valid object!
> > >
> > > error: refs/remotes/origin/ignite-2.9 does not point to a valid object!
> > >
> > > error: refs/tags/1.1.3 does not point to a valid object!
> > >
> > >
> > > Not to mention that directory doesn't point anywhere in particular in an
> > > arbitrary system, there is no ref folder inside .git either.
> > >
> > >
> > > Any help?
> >
> >

Make GridEncryptionManager#onWalSegmentRemoved async

[ткаленко кирилл]

Hello to all!

When implementing IGNITE-13831 I was faced with deadlock.

When execute FileWriteAheadLogManager#rollOver, begin to clean WAL archive 
since we have reached the DataStorageConfiguration#maxWalArchiveSize, after 
deleting a segment, execute the GridEncryptionManager#onWalSegmentRemoved that 
wants to write to the metastore, but it will not succeed, since it will wait 
for FileWriteAheadLogManager#rollOver.

I suggest making the GridEncryptionManager#onWalSegmentRemoved asynchronous in 
a separate pool, for example, as a CacheGroupPageScanner#singleExecSvc.

Re: [TC RELEASES] Problem with assembling a build

[Petr Ivanov]

That will require time and some research.

A will try to do it today, in urgent case — can introduce half-hack for now and 
improve later.


> On 11 Dec 2020, at 13:17, Maxim Muzafarov  wrote:
> 
> Petr,
> 
> Will you fix the issue [1] soon or we can proceed with the 2.9.1
> release manually?
> 
> [1] https://issues.apache.org/jira/browse/IGNITE-13839
> 
> On Thu, 10 Dec 2020 at 20:59, Yaroslav Molochkov  
> wrote:
>> 
>> Thanks, Petr!
>> 
>> I've created a ticket  
>> for
>> that issue
>> 
>> On Thu, Dec 10, 2020 at 6:35 PM Petr Ivanov  wrote:
>> 
>>> The problem is with mirroring option for TC VCS root.
>>> 
>>> I think for releases we should redesign release build to require native
>>> checked out repository, not mirrored one.
>>> 
>>> 
 On 10 Dec 2020, at 18:20, Yaroslav Molochkov 
>>> wrote:
 
 Igniters, hello!
 
 Currently I'm experiencing difficulties with an archive that is built by
>>> a
 TC job.
 
 I ran a build job (Apache Ignite / Main) and downloaded artifacts. After
 that the script to add a tag to the repository throws an error. Problem
>>> is
 with git folder, git can't fetch anything:
 
 error: object directory
>>> /opt/buildagent/system/git/git-BF1D6845.git/objects
 does not exist; check .git/objects/info/alternates
 
 error: refs/heads/ignite-2.9 does not point to a valid object!
 
 error: refs/remotes/origin/ignite-2.9 does not point to a valid object!
 
 error: refs/tags/1.1.3 does not point to a valid object!
 
 
 Not to mention that directory doesn't point anywhere in particular in an
 arbitrary system, there is no ref folder inside .git either.
 
 
 Any help?
>>> 
>>> 

Re: Move WAL archive cleanup from checkpoint to rollover

[Данилов Семён]

Hello! I also have an issue in progress regarding WAL archive: 
https://issues.apache.org/jira/browse/IGNITE-12892. In this ticket I tried 
clarifying WAL archive size configuration, removing usage of the deprecated 
walHistSize property. Also, IGNITE_PDS_MAX_CHECKPOINT_MEMORY_HISTORY_SIZE is 
now only used when archive is managed externally and you can set 
maxWalArchiveSize to -1 so WAL truncation is disabled. PR is already submitted 
and approved https://github.com/apache/ignite/pull/8550

Regards,
Semyon.

09.12.2020, 19:17, "ткаленко кирилл" :
> Hi, Andrey!
>
> Users expect DataStorageConfiguration#maxWalArchiveSize to mean that WAL 
> archive will not exceed this value, but it is not.
> It seems that to reduce the chance of getting into a situation when we exceed 
> WAL archive, it will be lowed when we clean it when switching to a new 
> segment than at the end of the checkpoint.
> After that, we can think about and make a hard limit on WAL archive, but for 
> this will need to solve a few more problems.
>
> 09.12.2020, 17:24, "Andrey Gura" :
>>  Kiriill,
>>
>>  Issue description contains the following:
>>
>>>   At the moment, WAL archive is cleared at the end of the checkpoint, which 
>>> does not seem correct and needs to be moved
>>
>>  Could you please explain why existing behavior is not correct. It
>>  seems that it is not enough motivation for change.
>>
>>  On Wed, Dec 9, 2020 at 5:05 PM vbm  wrote:
>>>   Hi Kirill Tkalenko,
>>>
>>>   Is there any relation to rate of ingestion of data to ignite ?
>>>
>>>   We had seen the issue of WAL growing infinitely recently in our K8s 
>>> cluster.
>>>   We were ingesting data at around 2Mbps.
>>>   In other clusters where we did not have such a fast ingestion of data, 
>>> this
>>>   issue was not observed.
>>>
>>>   Regards,
>>>   Vishwas
>>>
>>>   --
>>>   Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: [DISCUSSION] Modules organization in Ignite 3

[Ilya Kasnacheev]

Hello!

I think it is a strong side of Apache Ignite that it has a low number of
JARs and minimal dependencies. It may be less relevant now than 10 years
ago, but it's still a plus.

Not sure how fast it would evaporate as the number of JARs and dependencies
grows.

Regards,
-- 
Ilya Kasnacheev


чт, 10 дек. 2020 г. в 12:28, Anton Kalashnikov :

> Ilya, it is a good point about jar name. If it really unresolvable problem
> we should leave modules name as is(I do not insist on renaming it was just
> a proposal)
>
> I also not really got you point about 'zillion JARs'. Do you think it will
> be a problem if the number of JARs increases a little? If so can you
> clarify it with some specific examples?
>
> --
> Best regards,
> Anton Kalashnikov
>
>
>
> 09.12.2020, 18:12, "Ilya Kasnacheev" :
> > Hello!
> >
> > When you do mvn dependencies:copy, you will now end up with
> > "ignite-core-X.Y.Z.jar", "ignite-indexing-X.Y.Z.jar"
> > But if we remove "ignite" from artifact name, user will end up with
> cryptic
> > "configuration.jar", "raft.jar", etc, etc.
> >
> > Remember that group name is discarded in file names. Therefore, every
> > project out there keeps stuff like "spring-" or "hibernate-" in artifact
> > name.
> >
> > I also hope that our users will not end up with zillion JARs.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> > ср, 9 дек. 2020 г. в 16:16, Anton Kalashnikov :
> >
> >>  Hello,
> >>
> >>  I totally agree that we should start to think about the module
> >>  organization.
> >>  I suggest making the new confluence page where we define new rules on
> how
> >>  to develop modules.
> >>  In my opinion, at least, the following topics should be covered
> there(it
> >>  makes sense to discuss every topic separately, not here):
> >>  * In which cases new modules are required
> >>  * The naming of modules, packages
> >>  * Class dependency management ( inversion of control, no more context)
> >>  * Test organization ( module contains only unit, module tests. All
> >>  integration tests are in the extra module)
> >>  * Feature/Module lifecycle - experimental, stable, unstable, deprecated
> >>
> >>  Let's get back to the original topic. I agree with the package naming
> >>  rule:
> >>  if the module name is configuration the package name should be
> >>  org.apache.ignite.configuration and only after that any other
> subpackages.
> >>  Also, I don't sure that we need ignite- prefix in the module name
> because
> >>  it doesn't have any extra information:
> >>
> >>org.apache.ignite
> >>ignite-configuration
> >>
> >>  we don't lose anything if convert it to
> >>
> >>org.apache.ignite
> >>configuration
> >>
> >>  I also hope that jigsaw can help us somehow with class visibility.
> >>  But if not we can take agreement that for example 'internal' package -
> >>  shouldn't be touched outside of the module -
> >>  of course, using the proper class access level is also the
> solution(where
> >>  it is possible)
> >>  org.apache.ignite.configuration.Configurator // it has access to the
> >>  internal package but it shouldn't return any class from the internal
> >>  package only from the public one.
> >>  org.apache.ignite.configuration.DynamicProperty //interface
> >>  org.apache.ignite.configuration.internal.properties.IntDynamicProperty
> >>
> >>  User API makes sense only for one end module - ignite(or ignite-core)
> >>  which depends on all other modules
> >>  and doing some integration(adapters) and provide final API for the
> user.
> >>  So I agree that separated module Ignite-API with zero dependencies
> will be
> >>  a good solution.
> >>
> >>  configuration module:
> >>Configurator.baseline().enabled() -> DynamicProperties
> >>
> >>  ignite-api module:
> >>BaselineConfiguration.enabled() -> boolean //interface
> >>
> >>  ignite module:
> >>BaselineConfigurationImpl implements BaselineConfiguration{
> >>  Configurator configurator;
> >>  public boolean enabled(){
> >> return configurator.baseline().enabled().value();
> >>  }
> >>}
> >>
> >>  So maybe my example is not so good. But I want to show that end-user
> API
> >>  will be defined only in ignite-api
> >>  and you need to adapt it in ignite module which leads to some
> >>  overhead(especially in my example)
> >>   but it makes development pretty manageable/predictable -
> >>  you can easily implement a new module without any worries that user
> starts
> >>  to use it.
> >>  It will be available only after making changes in ignite-api.
> >>  The major advantage here is the small size of ignite-api which allows
> to
> >>  carefully review every change
> >>  which allows keeping ignite API in better quality(I hope at least)
> >>
> >>  Nikolay, maybe is it better to discuss your question on a separate
> topic?
> >>  Because looks like it is a pretty discussable topic.
> >>
> >>  --
> >>  Best regards,
> >>  Anton Kalashnikov
> >>
> >>  09.12.2020, 10:31, "Nikolay Izhikov" :
> >>  > Hello, Zhenya, Ivan.
> 

[jira] [Created] (IGNITE-13840) Rething API of Init*, change* classes

[Anton Kalashnikov (Jira)]

Anton Kalashnikov created IGNITE-13840:
--

 Summary: Rething API  of Init*, change* classes
 Key: IGNITE-13840
 URL: https://issues.apache.org/jira/browse/IGNITE-13840
 Project: Ignite
  Issue Type: Sub-task
Reporter: Anton Kalashnikov


Right now, API of Init*, change* classes look too heavy and contain a lot of 
code boilerplate. It needs to think about how to simplify it.



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

[jira] [Created] (IGNITE-13841) Cluster bootstrapping

[Anton Kalashnikov (Jira)]

Anton Kalashnikov created IGNITE-13841:
--

 Summary: Cluster bootstrapping 
 Key: IGNITE-13841
 URL: https://issues.apache.org/jira/browse/IGNITE-13841
 Project: Ignite
  Issue Type: Sub-task
Reporter: Anton Kalashnikov


How cluster bootstrapping should look like? Format of files? What is the right 
moment fr applying configuration? What is the state of the cluster before 
applying?



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

[jira] [Created] (IGNITE-13842) Creating the new configuration on old cluster

[Anton Kalashnikov (Jira)]

Anton Kalashnikov created IGNITE-13842:
--

 Summary: Creating the new configuration on old cluster
 Key: IGNITE-13842
 URL: https://issues.apache.org/jira/browse/IGNITE-13842
 Project: Ignite
  Issue Type: Sub-task
Reporter: Anton Kalashnikov


Do we need the ability to create a new configuration/property on the working 
cluster? 



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

[jira] [Created] (IGNITE-13843) Wrapper/Converter for primitive configuration

[Anton Kalashnikov (Jira)]

Anton Kalashnikov created IGNITE-13843:
--

 Summary: Wrapper/Converter for primitive configuration 
 Key: IGNITE-13843
 URL: https://issues.apache.org/jira/browse/IGNITE-13843
 Project: Ignite
  Issue Type: Sub-task
Reporter: Anton Kalashnikov


Do we need the ability to use complex type such InternetAddress as wrapper of 
some string property?



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

Re: Make GridEncryptionManager#onWalSegmentRemoved async

[Pavel Pereslegin]

Hello, Kirill!

Personally, I see no problem with this improvement. Please check my
comment in IGNITE-13831 [1] on the implementation of this change.

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

пт, 11 дек. 2020 г. в 13:23, ткаленко кирилл :
>
> Hello to all!
>
> When implementing IGNITE-13831 I was faced with deadlock.
>
> When execute FileWriteAheadLogManager#rollOver, begin to clean WAL archive 
> since we have reached the DataStorageConfiguration#maxWalArchiveSize, after 
> deleting a segment, execute the GridEncryptionManager#onWalSegmentRemoved 
> that wants to write to the metastore, but it will not succeed, since it will 
> wait for FileWriteAheadLogManager#rollOver.
>
> I suggest making the GridEncryptionManager#onWalSegmentRemoved asynchronous 
> in a separate pool, for example, as a CacheGroupPageScanner#singleExecSvc.

[GitHub] [ignite-3] sergey-chugunov-1985 opened a new pull request #6: IGNITE-13718 Integration module for new Unified Configuration providing REST API to access and manage configuration

[GitBox]

sergey-chugunov-1985 opened a new pull request #6:
URL: https://github.com/apache/ignite-3/pull/6


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Created] (IGNITE-13844) Calcite improvements. Append additional dependencies.

[Stanilovsky Evgeny (Jira)]

Stanilovsky Evgeny created IGNITE-13844:
---

 Summary: Calcite improvements. Append additional dependencies.
 Key: IGNITE-13844
 URL: https://issues.apache.org/jira/browse/IGNITE-13844
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Affects Versions: 2.9
Reporter: Stanilovsky Evgeny
Assignee: Stanilovsky Evgeny


I found that calcite feature-branch started from _ignite.sh_ requires 
additional dependencies: com.esri.geometry and org.javassist



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

[DISCUSSION] Unified CLI tool

[Kirill Gusakov]

Hi, everyone.

I want to propose for discussion the PoC cli tool, which was born to check
and demonstrate approaches explained in [0] and [1].
This tool will be the all-in-one cli tool for ignite cluster management and
ignite installation/update.

One unified tool will:
- lower the entry threshold for Ignite newbies (it should be as simple as
wget ignite && ignite init && ignite node start new-node)
- be the one entry point for any ignite operation
- be used for the smooth automated upgrade of local nodes and modules
- use abstract REST API for communication with nodes in the future. so, you
can implement your own processes around this REST API if needed

Work in progress PR can be found here
https://github.com/apache/ignite-3/pull/4

You can:
- see a small demo here https://asciinema.org/a/378647
- build it from the PR and try it by yourself

For building it from the sources and have a fully working demo setup you
need firstly:
- "mvn install" the root dir here https://github.com/apache/ignite-3/pull/5
- "mvn install" the root dir here https://github.com/apache/ignite-3/pull/6
- "mvn install" tool itself from https://github.com/apache/ignite-3/pull/4


[0]
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=158873958
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration

[DISCUSSION] Unified Configuration for Ignite 3.0

[Sergey Chugunov]

Hello Igniters,

I would like to present two pull requests [1], [2] with basic
implementation of IEP-55 for Unified Configuration [3] and IEP-63 REST API
for Unified Configuration [4].

The main goal of these PRs is to present and discuss a new approach for
preparing and managing Ignite configuration in a more robust and convenient
way than it was before.

These PRs cover basic aspects of configuration but other steps for
developing functionality are already defined; ticket IGNITE-13511 [5]
summarizes work to do.

In a nutshell proposed approach to configuration is as follows:

We want to declare configuration with POJO-based schemas that are concise
and contain all important information about validation and how different
pieces of configuration relate to each other.
When schemas are marked with annotations annotation processor enters the
game and generates most of boilerplate code thus freeing users from writing
it by hand.

REST API module from [2] contains an example of managing configuration and
exposing it to external tools like a Unified CLI tool presented in [6].

[1] https://github.com/apache/ignite-3/pull/5
[2] https://github.com/apache/ignite-3/pull/6
[3]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration
[4]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-63%3A+REST+API+module+to+integrate+new+modular+architecture+and+management
[5] https://issues.apache.org/jira/browse/IGNITE-13511
[6]
http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Unified-CLI-tool-td50618.html

[jira] [Created] (IGNITE-13845) Add checkpoint lock hold metrics

[Amelchev Nikita (Jira)]

Amelchev Nikita created IGNITE-13845:


 Summary: Add checkpoint lock hold metrics
 Key: IGNITE-13845
 URL: https://issues.apache.org/jira/browse/IGNITE-13845
 Project: Ignite
  Issue Type: New Feature
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita


Add last checkpoint lock hold duration and durations histogram metrics.



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

Re: [DISCUSSION] Modules organization in Ignite 3

[Valentin Kulichenko]

Ilya,

I think common sense is our only friend here :) The low number of
dependencies is indeed one of the advantages of Ignite. On the other hand,
the "zero dependency" approach we've been trying to follow for the last
several years sometimes forces us to implement, stabilize and maintain a
whole lot of code that we potentially could reuse from somewhere else.

We should always try to minimize the number of dependencies, especially for
the core part of the product. But we should also reuse existing code where
it is reasonable.

-Val


On Fri, Dec 11, 2020 at 3:26 AM Ilya Kasnacheev 
wrote:

> Hello!
>
> I think it is a strong side of Apache Ignite that it has a low number of
> JARs and minimal dependencies. It may be less relevant now than 10 years
> ago, but it's still a plus.
>
> Not sure how fast it would evaporate as the number of JARs and dependencies
> grows.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 10 дек. 2020 г. в 12:28, Anton Kalashnikov :
>
> > Ilya, it is a good point about jar name. If it really unresolvable
> problem
> > we should leave modules name as is(I do not insist on renaming it was
> just
> > a proposal)
> >
> > I also not really got you point about 'zillion JARs'. Do you think it
> will
> > be a problem if the number of JARs increases a little? If so can you
> > clarify it with some specific examples?
> >
> > --
> > Best regards,
> > Anton Kalashnikov
> >
> >
> >
> > 09.12.2020, 18:12, "Ilya Kasnacheev" :
> > > Hello!
> > >
> > > When you do mvn dependencies:copy, you will now end up with
> > > "ignite-core-X.Y.Z.jar", "ignite-indexing-X.Y.Z.jar"
> > > But if we remove "ignite" from artifact name, user will end up with
> > cryptic
> > > "configuration.jar", "raft.jar", etc, etc.
> > >
> > > Remember that group name is discarded in file names. Therefore, every
> > > project out there keeps stuff like "spring-" or "hibernate-" in
> artifact
> > > name.
> > >
> > > I also hope that our users will not end up with zillion JARs.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > > ср, 9 дек. 2020 г. в 16:16, Anton Kalashnikov :
> > >
> > >>  Hello,
> > >>
> > >>  I totally agree that we should start to think about the module
> > >>  organization.
> > >>  I suggest making the new confluence page where we define new rules on
> > how
> > >>  to develop modules.
> > >>  In my opinion, at least, the following topics should be covered
> > there(it
> > >>  makes sense to discuss every topic separately, not here):
> > >>  * In which cases new modules are required
> > >>  * The naming of modules, packages
> > >>  * Class dependency management ( inversion of control, no more
> context)
> > >>  * Test organization ( module contains only unit, module tests. All
> > >>  integration tests are in the extra module)
> > >>  * Feature/Module lifecycle - experimental, stable, unstable,
> deprecated
> > >>
> > >>  Let's get back to the original topic. I agree with the package naming
> > >>  rule:
> > >>  if the module name is configuration the package name should be
> > >>  org.apache.ignite.configuration and only after that any other
> > subpackages.
> > >>  Also, I don't sure that we need ignite- prefix in the module name
> > because
> > >>  it doesn't have any extra information:
> > >>
> > >>org.apache.ignite
> > >>ignite-configuration
> > >>
> > >>  we don't lose anything if convert it to
> > >>
> > >>org.apache.ignite
> > >>configuration
> > >>
> > >>  I also hope that jigsaw can help us somehow with class visibility.
> > >>  But if not we can take agreement that for example 'internal' package
> -
> > >>  shouldn't be touched outside of the module -
> > >>  of course, using the proper class access level is also the
> > solution(where
> > >>  it is possible)
> > >>  org.apache.ignite.configuration.Configurator // it has access to the
> > >>  internal package but it shouldn't return any class from the internal
> > >>  package only from the public one.
> > >>  org.apache.ignite.configuration.DynamicProperty //interface
> > >>
> org.apache.ignite.configuration.internal.properties.IntDynamicProperty
> > >>
> > >>  User API makes sense only for one end module - ignite(or ignite-core)
> > >>  which depends on all other modules
> > >>  and doing some integration(adapters) and provide final API for the
> > user.
> > >>  So I agree that separated module Ignite-API with zero dependencies
> > will be
> > >>  a good solution.
> > >>
> > >>  configuration module:
> > >>Configurator.baseline().enabled() -> DynamicProperties
> > >>
> > >>  ignite-api module:
> > >>BaselineConfiguration.enabled() -> boolean //interface
> > >>
> > >>  ignite module:
> > >>BaselineConfigurationImpl implements BaselineConfiguration{
> > >>  Configurator configurator;
> > >>  public boolean enabled(){
> > >> return configurator.baseline().enabled().value();
> > >>  }
> > >>}
> > >>
> > >>  So maybe my example is not so good. But I want to show that end-user
> > API
> > >>  

[MTCGA]: new failures in builds [5785215] 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.

 *New Critical Failure in master-nightly MVCC Cache 9 
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_MvccCache9?branch=%3Cdefault%3E
 No changes in the build

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

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 01:20:58 12-12-2020 

Re: Pull request for minor fix in index page documentation

[Denis Magda]

Nikita, thanks for fixing the issue:
https://github.com/apache/ignite/pull/8570

I've merged the changes and republished the docs on the website. Thanks for
contributing to our documentation!

-
Denis


On Wed, Dec 9, 2020 at 1:22 AM Sumit Deshinge 
wrote:

> Great, thanks Denis.
>
> On Tue, Dec 8, 2020 at 11:35 PM Denis Magda  wrote:
>
>> Hi Sumit,
>>
>> Thanks for catching the issue and preparing a pull-request! The
>> pull-request merges changes to your Ignite master branch rather than to the
>> Ignite master. Not a bid deal. I see where the problem is. @Nikita
>> Safonov , @Viktor Chemodanov
>> , could any of your correct the broken link on
>> the page?
>>
>> As for the docs contribution process, it's here. There is a step that
>> explains how to build the HTML version of the docs locally before pushing
>> live:
>>
>> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document#HowtoDocument-ContributingtoDocumentation
>>
>> -
>> Denis
>>
>>
>> On Tue, Dec 8, 2020 at 2:21 AM Sumit Deshinge 
>> wrote:
>>
>>> Hi team,
>>>
>>> I just made a minor change in apache ignite index page documentation.
>>> But I am not sure the pull request raised is sufficient or do I need to
>>> follow any additional steps. Please let me know/advice on the same.
>>> Also is there any way to verify these changes as these are related to
>>> documentation being loaded on the ignite website and not related to code?
>>> https://github.com/sumitdeshinge/ignite/pull/1
>>>
>>>
>>> --
>>> Regards,
>>> Sumit Deshinge
>>>
>>
>
> --
> Regards,
> Sumit Deshinge
>
>

Re: [DISCUSSION] Unified CLI tool

[Valentin Kulichenko]

Hi Kirill,

I've played with the tool a little bit and it looks great! I definitely
like the overall approach of a single script responsible for all the
operations. This should significantly improve the usability of the product.

Looks like there is a significant amount of functionality already
implemented. I think we should merge the code to the main branch so that
any other contributors could also participate and build on top of it. What
do you think? Is the PR ready for review?

-Val

On Fri, Dec 11, 2020 at 8:55 AM Kirill Gusakov  wrote:

> Hi, everyone.
>
> I want to propose for discussion the PoC cli tool, which was born to check
> and demonstrate approaches explained in [0] and [1].
> This tool will be the all-in-one cli tool for ignite cluster management and
> ignite installation/update.
>
> One unified tool will:
> - lower the entry threshold for Ignite newbies (it should be as simple as
> wget ignite && ignite init && ignite node start new-node)
> - be the one entry point for any ignite operation
> - be used for the smooth automated upgrade of local nodes and modules
> - use abstract REST API for communication with nodes in the future. so, you
> can implement your own processes around this REST API if needed
>
> Work in progress PR can be found here
> https://github.com/apache/ignite-3/pull/4
>
> You can:
> - see a small demo here https://asciinema.org/a/378647
> - build it from the PR and try it by yourself
>
> For building it from the sources and have a fully working demo setup you
> need firstly:
> - "mvn install" the root dir here
> https://github.com/apache/ignite-3/pull/5
> - "mvn install" the root dir here
> https://github.com/apache/ignite-3/pull/6
> - "mvn install" tool itself from https://github.com/apache/ignite-3/pull/4
>
>
> [0]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=158873958
> [1]
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration
>

Re: [DISCUSSION] Unified Configuration for Ignite 3.0

[Valentin Kulichenko]

Hi Sergey,

Thanks for doing this.

It looks like PR #5 is already under review, so I guess it will be merged
soon. I would really love to see that, because the configuration framework
is one of the foundational components - we need it to continue building
Ignite 3.0.

As for PR #6, it looks a little raw, but I believe we need it to connect
the configuration framework with the CLI tool that is also pending for the
merge, is this correct? If that's the case, I think it's OK to merge this
code as a separate module, with an understanding that it will change
significantly down the road. I would do a couple of changes though:

   1. Get rid of "simplistic-ignite" naming, as it's a little confusing.
   Even though it's more of a prototype at this point, it should be clear what
   the module is responsible for. Can we rename it to "ignite-runner" or
   something along those lines?
   2. Update the output - I don't like that it prints out the
   Javalin's banner and messages. I suggest replacing this with some very
   basic Ignite logging: an entry showing the version of Ignite; an entry
   indicating that the REST protocol is enabled on a certain port; an entry
   that the process is successfully started. This is just to make sure that
   anyone who plays with it understands what's going on.

Any objections?

-Val

On Fri, Dec 11, 2020 at 9:53 AM Sergey Chugunov 
wrote:

> Hello Igniters,
>
> I would like to present two pull requests [1], [2] with basic
> implementation of IEP-55 for Unified Configuration [3] and IEP-63 REST API
> for Unified Configuration [4].
>
> The main goal of these PRs is to present and discuss a new approach for
> preparing and managing Ignite configuration in a more robust and convenient
> way than it was before.
>
> These PRs cover basic aspects of configuration but other steps for
> developing functionality are already defined; ticket IGNITE-13511 [5]
> summarizes work to do.
>
> In a nutshell proposed approach to configuration is as follows:
>
> We want to declare configuration with POJO-based schemas that are concise
> and contain all important information about validation and how different
> pieces of configuration relate to each other.
> When schemas are marked with annotations annotation processor enters the
> game and generates most of boilerplate code thus freeing users from writing
> it by hand.
>
> REST API module from [2] contains an example of managing configuration and
> exposing it to external tools like a Unified CLI tool presented in [6].
>
> [1] https://github.com/apache/ignite-3/pull/5
> [2] https://github.com/apache/ignite-3/pull/6
> [3]
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration
> [4]
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-63%3A+REST+API+module+to+integrate+new+modular+architecture+and+management
> [5] https://issues.apache.org/jira/browse/IGNITE-13511
> [6]
>
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Unified-CLI-tool-td50618.html
>

[MTCGA]: new failures in builds [5785727] 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 Critical Failure in master Cache (Restarts) 1 
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_CacheRestarts1?branch=%3Cdefault%3E
 Changes may lead to failure were done by 
 - ibessonov  
https://ci.ignite.apache.org/viewModification.html?modId=912109
 - kirill tkalenko  
https://ci.ignite.apache.org/viewModification.html?modId=912110
 - zstan  
https://ci.ignite.apache.org/viewModification.html?modId=912133
 - ibessonov  
https://ci.ignite.apache.org/viewModification.html?modId=912096
 - semyon danilov  
https://ci.ignite.apache.org/viewModification.html?modId=912131
 - ibessonov  
https://ci.ignite.apache.org/viewModification.html?modId=912099

 - 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 06:21:00 12-12-2020 

[MTCGA]: new failures in builds [5785704] 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 test failure in master 
TcpDiscoverySslTrustedSelfTest.testDiscoveryEventsDiscard 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=9207551201360772337&branch=%3Cdefault%3E&tab=testDetails
 Changes may lead to failure were done by 
 - ibessonov  
https://ci.ignite.apache.org/viewModification.html?modId=912109
 - kirill tkalenko  
https://ci.ignite.apache.org/viewModification.html?modId=912110
 - zstan  
https://ci.ignite.apache.org/viewModification.html?modId=912133
 - ibessonov  
https://ci.ignite.apache.org/viewModification.html?modId=912096
 - semyon danilov  
https://ci.ignite.apache.org/viewModification.html?modId=912131
 - ibessonov  
https://ci.ignite.apache.org/viewModification.html?modId=912099

 - 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 10:51:00 12-12-2020