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

[Artem Budnikov]

Hi Everyone,

I posted an instruction on how to publish the docs on ignite.apache.org/docs
[1]. When you finish with Ignite 2.9, you can update the docs by following
the instruction. Unfortunately, I won't be able to spend any time on this
project any longer. You can send your pull requests and questions about the
documentation to Denis Magda.

-Artem

[1] : https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document

On Thu, Sep 10, 2020 at 2:45 PM Alexey Goncharuk 
wrote:

> Alexey,
>
> I've tried to play with message factories locally, but unfortunately, I
> cannot spot the difference between old and new implementation in
> distributed benchmarks. I pushed an implementation of MessageFactoryImpl
> with the old switch statement to the ignite-2.9-revert-12568 branch
> (discussed this with Andrey Gura, the change should be compatible with the
> new metrics as we still use the register() mechanics).
>
> Can you check if this change makes any difference performance-wise in your
> environment? If yes, we can go with runtime code generation in the long
> term: register classes and generate a dynamic message factory with a switch
> statement once all messages are registered (not in 2.9 though, obviously).
>
> ср, 9 сент. 2020 г. в 14:53, Alex Plehanov :
>
> > Hello guys,
> >
> > I've tried to optimize tracing implementation (ticket [1]), it reduced
> the
> > drop, but not completely removed it.
> > Ivan Rakov, Alexander Lapin, can you please review the patch?
> > Ivan Artiukhov, can you please benchmark the patch [2] against 2.8.1
> > release on your environment?
> > With this patch on our environment, it's about a 3% drop left, it's close
> > to measurement error and I think such a drop is not a showstopper. Guys,
> > WDYT?
> >
> > Also, I found that compatibility is broken for JDBC thin driver between
> 2.8
> > and 2.9 versions (ticket [3]). I think it's a blocker and should be
> > fixed in 2.9. I've prepared the patch.
> > Taras Ledkov, can you please review this patch?
> >
> > And one more ticket I propose to include into 2.9 [4] (NIO message
> > send problem in some circumstances). I will cherry-pick it if there is no
> > objection.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-13411
> > [2] https://github.com/apache/ignite/pull/8223
> > [3] https://issues.apache.org/jira/browse/IGNITE-13414
> > [4] https://issues.apache.org/jira/browse/IGNITE-13361
> >
> > пн, 7 сент. 2020 г. в 14:14, Maxim Muzafarov :
> >
> > > Alexey,
> > >
> > > I propose to include [1] issue to the 2.9 release. Since this issue is
> > > related to the new master key change functionality which haven't been
> > > released yet I think it will be safe to cherry-pick commit to the
> > > release branch.
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-13390
> > >
> > > On Tue, 1 Sep 2020 at 12:13, Nikolay Izhikov 
> > wrote:
> > > >
> > > > Hello, Igniters.
> > > >
> > > > Alexey, please, include one more Python thin client fix [1] into the
> > 2.9
> > > release
> > > > It fixes kinda major issue - "Python client returns fields in wrong
> > > order since the 2 row when fields_count>10"
> > > >
> > > > [1] https://issues.apache.org/jira/browse/IGNITE-12809
> > > > [2]
> > >
> >
> https://github.com/apache/ignite/commit/38025ee4167f05eaa2d6a2c5c2ab70c83a462cfc
> > > >
> > > > > 31 авг. 2020 г., в 19:23, Alexey Goncharuk <
> > alexey.goncha...@gmail.com>
> > > написал(а):
> > > > >
> > > > > Alexey, thanks, got it. I am not sure we can optimize anything out
> of
> > > the
> > > > > message factory with suppliers (at least I have no ideas right
> now),
> > so
> > > > > most likely the only move here is to switch back to the switch
> > approach
> > > > > somehow preserving the metrics part. Probably, inlining the Ignite
> > > messages
> > > > > to the IgniteMessageFactoryImpl should do the trick. Let me explore
> > the
> > > > > code a bit.
> > > > >
> > > > > P.S. I am surprised by the impact this part makes for the
> > performance.
> > > > > Message creation is indeed on the hot path, but a single virtual
> call
> > > > > should not make that much of a difference given the amount of other
> > > work
> > > > > happening during the message processing.
> > > > >
> > > > > пн, 31 авг. 2020 г. в 18:33, Alex Plehanov <
> plehanov.a...@gmail.com
> > >:
> > > > >
> > > > >> Alexey, sorry, I wrongly interpreted our benchmark results.
> > Actually,
> > > we
> > > > >> were looking for a drop using bi-sect in the range between e6a7f93
> > > (first
> > > > >> commit in the 2.9 branch after 2.8 branch cut) and 6592dfa5 (last
> > > commit in
> > > > >> the 2.9 branch). And we found these two problematic commits.
> > > > >>
> > > > >> Perhaps only IGNITE-13060 (Tracing) is responsible for a drop
> > between
> > > > >> 2.8.1 and 2.9 (we have benchmarked 2.8.1 vs 2.9 with reverted
> > > IGNITE-13060
> > > > >> now and performance looks the same)
> > > > >>
> > > > >> Ticket IGNITE-12568 (MessageFactory refactoring) is not related 

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

[Artem Budnikov]

Hi Ivan,

The documentation for Ignite 2.9 is kept here: 
https://github.com/apache/ignite/tree/IGNITE-7595/docs


There is a readme file with instructions. You can make a pull request to 
this branch. However, the installation instruction for Ignite C++ hasn't 
been created yet. If you want, you can create the "Setting up Ignite for 
C++" page by copying this [1] from readme.io and updating it with your 
changes.


-Artem

[1] 
https://apacheignite-cpp.readme.io/docs/getting-started-1#building-from-source


On 31.08.2020 09:43, Ivan Daschinsky wrote:
Artem, in ignite 2.9 a way to build C++ for linux/mac os x was changed 
(autotools to cmake). As an author of this change, I want to 
contribute in documentation.
As far as I understand, now it should be done through PR to specific 
repository. Could you please help me with this?


пт, 28 авг. 2020 г. в 16:33, Anton Kalashnikov <mailto:kaa@yandex.ru>>:


Hi Guys,

As I understand we will be merging some tickets to release. May I
suggest also add ticket [1] to 2.9 release.

There are not a lot of changes in code but It's a critical fix for
the ability to launch ignite in lamba on Azure(There are not any
workaround).

So if nobody minds let's merge it to 2.9.

[1] https://issues.apache.org/jira/browse/IGNITE-13013
<https://issues.apache.org/jira/browse/IGNITE-13013>

-- 
Best regards,

Anton Kalashnikov



28.08.2020, 11:16, "Alex Plehanov" mailto:plehanov.a...@gmail.com>>:
> Guys,
>
> We have benchmarked 2.9 without IGNITE-13060 and IGNITE-12568
(reverted it
> locally) and got the same performance as on 2.8.1
>
> IGNITE-13060 (Tracing) - some code was added to hot paths, to
trace these
> hot paths, it's clear why we have performance drop here.
>
> IGNITE-12568 (MessageFactory refactoring) - switch/case block was
> refactored to an array of message suppliers. The message factory
is on the
> hot path, which explains why this commit has an impact on total
> performance.
> I've checked JIT assembly output, done some JMH microbenchmarks,
and found
> that old implementation of MessageFactory.create() about 30-35%
faster than
> the new one. The reason - approach with switch/case can
effectively inline
> message creation code, but with an array of suppliers relatively
heavy
> "invokeinterface" cannot be skipped. I've tried to rewrite the
code using
> an abstract class for suppliers instead of an interface (to
> replace "invokeinterface" with the "invokevirtual"), but it
gives back only
> 10% of method performance and in this case, code looks ugly
(lambdas can't
> be used). Currently, I can't find any more ways to optimize the
current
> approach (except return to the switch/case block). Andrey Gura,
as the
> author of IGNITE-12568, maybe you have some ideas about
optimization?
>
> Perhaps we should revert IGNITE-12568, but there are some
metrics already
> created, which can't be rewritten using old message factory
implementation
> (IGNITE-12756). Guys, WDYT?
>
> пт, 28 авг. 2020 г. в 01:52, Denis Magda mailto:dma...@apache.org>>:
>
>>  Looks beautiful and easy to use, thanks, Artem! Could you
please add the
>>  following copyright to the footer of the pages?
>>
>>  *© 2020 The Apache Software Foundation.*
>>  *Apache, Apache Ignite, the Apache feather and the Apache
Ignite logo are
>>  either registered trademarks or trademarks of The Apache Software
>>  Foundation. *
>>  *Privacy Policy*
>>
>>  -
>>  Denis
>>
>>  On Thu, Aug 27, 2020 at 5:20 AM Artem Budnikov <
>> a.budnikov.ign...@gmail.com
<mailto:a.budnikov.ign...@gmail.com>> wrote:
>>
>>>  Hi everyone,
>>>
>>>  We published the draft of Ignite 2.9 documentation on the
Apache Ignite
>>>  web-site. The docs are available via the following link:
>>>
>>>
https://ignite.apache.org/docs/2.9.0/installation/installing-using-docker
<https://ignite.apache.org/docs/2.9.0/installation/installing-using-docker>
>>>
>>>  Alex,
>>>
>>>  Is there an estimate for the release date?
>>>
>>>  -Artem
>>>
>>>  On 26.08.2020 17:47, Alex Plehanov wrote:
>>>  > Denis,
>>>  >
>>>  > Currently, we are running mostly
IgnitePutTxImplicitBenchmark without
>>>  > persi

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

[Artem Budnikov]

Hi everyone,

We published the draft of Ignite 2.9 documentation on the Apache Ignite 
web-site. The docs are available via the following link:


https://ignite.apache.org/docs/2.9.0/installation/installing-using-docker

Alex,

Is there an estimate for the release date?

-Artem

On 26.08.2020 17:47, Alex Plehanov wrote:

Denis,

Currently, we are running mostly IgnitePutTxImplicitBenchmark without
persistence. For other benchmarks drop is lower and it's harder to find
problematic commit.

ср, 26 авг. 2020 г. в 17:34, Denis Magda :


Alex,

Thanks for sending an update. The drop is quite big. What are the types of
benchmarks you are observing the degradation for (atomic puts,
transactions, sql, etc.)?

Let us know if any help by particular committers is required.

-
Denis


On Wed, Aug 26, 2020 at 12:26 AM Alex Plehanov 
wrote:


Hello, guys!

We finally have some benchmark results. Looks like there is more than one
commit with a performance drop. Detected drops for those commits only
slightly higher than measurement error, so it was hard to find them and

we

are not completely sure we found them all and found them right.

Drops detected:
2-3% drop on commit 99b0e0143e0 (IGNITE-13060 Tracing: initial
implementation)
2-3% drop on commit 65c30ec6947 (IGNITE-12568 MessageFactory is

refactored

in order to detect registration of message with the same direct type)

The total drop we have on our environment - 7-8% and perhaps there is
something else here (benchmarks still in progress, I will write if we

find

more suspected commits).

Ivan Artiukhov, can you please recheck mentioned above commits on your
environment?


чт, 20 авг. 2020 г. в 11:43, Ilya Kasnacheev 
Hello!

Readme.io uses blue book :)

https://apacheignite.readme.io/docs/performance-tips

I was thinking of something along a blue circle with `i' in it, for
information items.

Regards,
--
Ilya Kasnacheev


ср, 19 авг. 2020 г. в 18:29, Artem Budnikov <

a.budnikov.ign...@gmail.com

:


Search does not seem to work.

It uses mockups right now, but it should be ready when the docs are
released.


I can see that note blocks are just annotated with "Note." Can we

have

some

image there?

Do you have a preference as to which image you would like to see

there?

-Artem

On 19.08.2020 17:37, Ilya Kasnacheev wrote:

Hello!

Search does not seem to work. Are we going to have a proper search

results

page? It is often the case that there's none.

I can see that note blocks are just annotated with "Note." Can we

have

some

image there? Example is
http://64.227.57.229/docs/2.9.0/persistence/persistence-tuning

Regards,

Re: apache-ignite_2.8.0-1_all.deb package has older version of openjdk as dependency

[Artem Budnikov]

I've created a JIRA issue: 
https://issues.apache.org/jira/browse/IGNITE-13388


-Artem

On 27.08.2020 12:05, Petr Ivanov wrote:

Hi, Artem,


Can you file and issue with description what exactly do not work and 
why, please?



On 27 Aug 2020, at 11:55, Artem Budnikov <mailto:a.budnikov.ign...@gmail.com>> wrote:


Looks like this issue wasn't fixed in 2.8.1. The Ignite deb package 
v. 2.8.1 can't be installed on debian 10:




$ sudo apt-get install apache-ignite
...
The following packages have unmet dependencies:
 apache-ignite : Depends: openjdk-8-jdk but it is not installable or
    oracle-java8-installer but it is not installable
E: Unable to correct problems, you have held broken packages.



Is anyone working on this? I was going to update the Ignite 2.9 
installation instruction for Debian, but if the issue is staying with 
us, I guess I shouldn't bother.


-Artem

On 27.05.2020 11:55, Ilya Kasnacheev wrote:

Hello!

You can build debian package from apache-ignite source deliverable. 
There you can fix the dependency.


Regards,
--
Ilya Kasnacheev


ср, 27 мая 2020 г. в 11:51, rakshita04 
<mailto:rakshita.chaudh...@siemens.com>>:


Can we have the newer debian package for apache ignite with
newer version of
openjdk as dependencies?



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
<http://apache-ignite-users.70518.x6.nabble.com/>

[jira] [Created] (IGNITE-13388) apache-ignite deb package depends on the non-existent package and can't be installed on Debian 10

[Artem Budnikov (Jira)]

Artem Budnikov created IGNITE-13388:
---

 Summary: apache-ignite deb package depends on the non-existent 
package and can't be installed on Debian 10
 Key: IGNITE-13388
 URL: https://issues.apache.org/jira/browse/IGNITE-13388
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.8.1
Reporter: Artem Budnikov


The apache-ignite deb package v. 2.8.1 depends on 'openjdk-8-jdk', which is 
only available in Debian stretch and isn't available in later Debian 
distributions. An attempt to install the package gives this error:
{code:java}
$ sudo apt-get install apache-ignite=2.8.1-1
...
The following packages have unmet dependencies:
 apache-ignite : Depends: openjdk-8-jdk but it is not installable or
  oracle-java8-installer but it is not installable
E: Unable to correct problems, you have held broken packages{code}
 Package information:
{code:java}
$ apt-cache show apache-ignite=2.8.1-1
Package: apache-ignite
Version: 2.8.1-1
Architecture: all
Maintainer: Petr Ivanov 
Installed-Size: 572071
Depends: openjdk-8-jdk | oracle-java8-installer, systemd, passwd
Section: misc
Priority: optional
Homepage: https://ignite.apache.org
Description: Apache Ignite In-Memory Computing, Database and Caching Platform
 Ignite™ is a memory-centric distributed database, caching, and processing
 platform for transactional, analytical, and streaming workloads, delivering
 in-memory speeds at petabyte scale
Description-md5: 6a59db03fa1e142387abef6ef6bb0d83
Filename: pool/main/a/apache-ignite_2.8.1-1_all.deb
SHA1: 67d197a5e582f6ea7c66da26a755f937f8e16fc9
SHA256: fc9a274ecb82716905d4120a715e9c74441dfed67831874eb3c35c4953bfc90d
Size: 399746094

{code}



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

Re: apache-ignite_2.8.0-1_all.deb package has older version of openjdk as dependency

[Artem Budnikov]

Looks like this issue wasn't fixed in 2.8.1. The Ignite deb package v. 
2.8.1 can't be installed on debian 10:



$ sudo apt-get install apache-ignite
...
The following packages have unmet dependencies:
 apache-ignite : Depends: openjdk-8-jdk but it is not installable or
    oracle-java8-installer but it is not installable
E: Unable to correct problems, you have held broken packages.


Is anyone working on this? I was going to update the Ignite 2.9 
installation instruction for Debian, but if the issue is staying with 
us, I guess I shouldn't bother.


-Artem

On 27.05.2020 11:55, Ilya Kasnacheev wrote:

Hello!

You can build debian package from apache-ignite source deliverable. 
There you can fix the dependency.


Regards,
--
Ilya Kasnacheev


ср, 27 мая 2020 г. в 11:51, rakshita04 >:


Can we have the newer debian package for apache ignite with newer
version of
openjdk as dependencies?



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

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

[Artem Budnikov]

Search does not seem to work.
It uses mockups right now, but it should be ready when the docs are 
released.



I can see that note blocks are just annotated with "Note." Can we have some
image there?

Do you have a preference as to which image you would like to see there?

-Artem

On 19.08.2020 17:37, Ilya Kasnacheev wrote:

Hello!

Search does not seem to work. Are we going to have a proper search results
page? It is often the case that there's none.

I can see that note blocks are just annotated with "Note." Can we have some
image there? Example is
http://64.227.57.229/docs/2.9.0/persistence/persistence-tuning

Regards,

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

[Artem Budnikov]

Hi everyone,

We've set up a staging site for the Ignite 2.9 docs: 
http://64.227.57.229/docs/2.9.0/installation/installing-using-docker


user/pass: ignite/apache2020

More content is being added, but that's basically what it will look like.

Your comments are welcome.

-Artem

On 18.08.2020 22:01, Pavel Tupitsyn wrote:

Ok, I'm just asking, there is no rush for this ticket.
If the release is postponed anyway, I thought that we can include more
fixes.

On Tue, Aug 18, 2020 at 8:10 PM Alex Plehanov 
wrote:


Pavel,

We still can't find the root cause of performance drop.

Ticket IGNITE-13369 still in progress. When it will be resolved? Is it
really critical bug? According to the user-list thread attached to the
ticket, there is a workaround exists for this problem and looks like it's
not so critical.

вт, 18 авг. 2020 г. в 12:30, Pavel Tupitsyn :


Alex,

What's the status of the release?
Can we include a bug fix there [1]?

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

On Fri, Aug 14, 2020 at 11:14 AM Alex Plehanov 
wrote:


Hello,


What is the release date for 2.9, from the cwiki it still says

August 7

We have a performance drop on the new release and still trying to find

the

problematic commit. I hope we will find it in a week + there are one or

two

weeks needed for voting and further release steps.

пт, 14 авг. 2020 г. в 11:01, gaurav.ag...@gmail.com <
gaurav.ag...@gmail.com

:
What is the release date for 2.9, from the cwiki it still says August

7 :

https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.9



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

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

[Artem Budnikov]

Hi Everyone,

I looked at the documentation tasks for Ignite 2.9 [1] and noticed that 
some of them were being worked on. I'll take a look at the other tickets 
(unassigned or assigned to me). I hope I'll have enough time to finish 
them by the time of the release.


-Artem

[1]: 
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.9#ApacheIgnite2.9-Documentationtasksforimportantfeaturesimplementedin2.9


On 06.08.2020 15:05, Alex Plehanov wrote:

Ivan,

Thank you. We've got performance drop on our benchmarks too.
We are trying to bisect changes and find problematic commit now.

чт, 6 авг. 2020 г. в 14:51, Ivan Artiukhov :


Hello,

I've compared performances of 2.9 and 2.8.1 using Yardstick and some
atomic/transactional/SQL operations. Ignite 2.9 is up to 7% slower in my
configuration. Please see
https://issues.apache.org/jira/browse/IGNITE-13337 for
details. Is this performance drop a blocker for 2.9 release?

--
Regards,
Ivan Artiukhov

чт, 6 авг. 2020 г. в 11:10, Ivan Daschinsky :


I recently found, that control.sh is broken since 2.8.0 a little bit.
Script returns always 0 code, despite the fact, that CommandHandler

returns

code correctly.

Here is the issue https://issues.apache.org/jira/browse/IGNITE-13328,
patch
is available.

пт, 31 июл. 2020 г. в 14:09, Alex Plehanov :


Ivan,

IGNITE-13306 cherry-picked to 2.9

пт, 31 июл. 2020 г. в 13:43, Ivan Rakov :


Hi Alex,

https://issues.apache.org/jira/browse/IGNITE-13306 is merged to

master.

Can you please cherry-pick to 2.9?

On Thu, Jul 30, 2020 at 7:42 PM Ilya Kasnacheev <

ilya.kasnach...@gmail.com>

wrote:


Hello!

I don't think that IGNITE-13006
 is a blocker

in

any

way. It is a good candidate for 3.0.

ignite-spring will work with 4.x Spring as well as 5.x and the user

is

free
to bump Spring version. I think bumping this dependency explicitly

is

infeasible since it may break existing code.

Regards,
--
Ilya Kasnacheev


ср, 22 июл. 2020 г. в 10:22, Alex Plehanov 
:

Guys,

We are in code-freeze phase now. I've moved almost all non-blocker
unresolved tickets from 2.9 to the next release. If you think that
some ticket is a blocker and should be included into 2.9 release,

please

write a note in this thread.

There are some tickets with "blocker" priority targeted to 2.9,

some

of

them in "open" state and still unassigned, and I'm not sure we

need

all

of

these tickets in 2.9:

IGNITE-13006 [1] (Apache Ignite spring libs upgrade from version

4x

to

spring 5.2 version or later) - Is it really a blocker for 2.9

release?

If

yes, can somebody help with resolving this ticket?

IGNITE-11942 [2] (IGFS and Hadoop Accelerator Discontinuation) -

ticket

in

"Patch available" state. There is a thread on dev-list related to

this

ticket ([6]), but as far as I understand we still don't have

consensus

about version for this patch (2.9, 2.10, 3.0).

IGNITE-12489 [3] (Error during purges by expiration: Unknown page

type)

-

perhaps issue is already resolved by some related tickets, there

is

still

no reproducer, no additional details and no work in progress. I

propose

to

move this ticket to the next release.

IGNITE-12911 [4] (B+Tree Corrupted exception when using a key

extracted

from a BinaryObject value object --- and SQL enabled) - ticket in

"Patch

available" state, but there is no activity since May 2020. Anton
Kalashnikov, Ilya Kasnacheev, do we have any updates on this

ticket?

Is

it

still in progress?

IGNITE-12553 [5] ([IEP-35] public Java metric API) - since the new

metrics

framework is already released in 2.8 and it's still marked with
@IgniteExperemental annotation, I think this ticket is not a

blocker.

I

propose to change the ticket priority and move it to the next

release.


[1]: https://issues.apache.org/jira/browse/IGNITE-13006
[2]: https://issues.apache.org/jira/browse/IGNITE-11942
[3]: https://issues.apache.org/jira/browse/IGNITE-12489
[4]: https://issues.apache.org/jira/browse/IGNITE-12911
[5]: https://issues.apache.org/jira/browse/IGNITE-12553
[6]:


http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Complete-Discontinuation-of-IGFS-and-Hadoop-Accelerator-td42282.html

пт, 17 июл. 2020 г. в 11:50, Alex Plehanov <

plehanov.a...@gmail.com

:

Ivan,

Merged to 2.9.

Thanks

пт, 17 июл. 2020 г. в 01:35, Ivan Rakov :


Alex,

Tracing is merged to master:
https://issues.apache.org/jira/browse/IGNITE-13060

Can you please port it to 2.9?
For you convenience, there's PR versus 2.9 with conflicts

resolved:

https://github.com/apache/ignite/pull/8046/files

--
Best Regards,
Ivan Rakov

On Wed, Jul 15, 2020 at 5:33 PM Alex Plehanov <

plehanov.a...@gmail.com>

wrote:


Ivan,

Looks like master is broken after IGNITE-13246 (but everything

is

ok

in

2.9
branch)

ср, 15 июл. 2020 г. в 18:54, Alex Plehanov <

plehanov.a...@gmail.com

:

Zhenya, Ivan,

I've cherry-picked IGNITE-13229 and IGNITE-13246 to

ignite-2.9

branch.

Tha

Re: Moving Ignite documentation to github

[Artem Budnikov]

Alex,

The documentation source files are still in the IGNITE-7595 branch. I 
haven't pushed them to the master yet, but I can do so if it is 
necessary. Or, you can add your changes to this branch. I added an 
instruction on how to contribute: 
https://github.com/apache/ignite/blob/IGNITE-7595/docs/README.adoc


I suggest we do the first release of the new docs manually (just like we 
do on readme.io) to get a sense of how the process works and how to 
automate it better. Then, I'll document the entire process on our wiki.


Sounds good?

Artem

On 06.08.2020 11:37, Alex Plehanov wrote:

Denis, Artem,

I've marked the "tracing" ticket as important.
Also, I've added a new section to the release page [1] and created
documentation tickets for some features. Now there is a documentation
ticket exists for each important feature implemented in 2.9.
I know that some Igniters are currently working on documentation, but the
question is still unanswered: where to push changes? To GitHub, or to
readme.io? Guys, can you clarify, please?

[1]:
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.9#ApacheIgnite2.9-Documentationtasksforimportantfeaturesimplementedin2.9


вт, 4 авг. 2020 г. в 21:08, Denis Magda :


Hi Alex,

Certainly, the new documentation should not be treated as a showstopper,
and if the code is ready much earlier, then we can release the docs on
readme.io.

But, it's not clear what's the documentation readiness status. As per our
updated release process, the docs need to be ready before the voting is
started [1]. That change was discussed and introduced after our
lessons-learned conversations related to the 2.8 release.

Could you please help to figure out the status by preparing a list of
documentation tasks that must be completed before the voting time (all
significant features and changes)? The "most important tasks" section [2]
already lists most of them, but the list might be incomplete. For example,
the tracing feature should be added in 2.9, but it's not in the important
tasks list. There might be something else profound that we should put on
paper.

Once we get the list, we can start working with the contributors in charge
to get things done. If some documentation pages won't be finished in 2
weeks from now, then it's reasonable to contribute the 2.9 docs to the new
docs repository that will be ready for the release in 3-4 weeks. Just my
thinking.

[1]

https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-4.1EnsureDocumentationReadinessandAccouncementBlogPostActivity
[2]

https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.9#ApacheIgnite2.9-Themostimportantreleasetasks

-
Denis


On Tue, Aug 4, 2020 at 5:54 AM Alex Plehanov 
wrote:


Denis,

We have some performance drop on benchmarks, so we need some time to find
problematic commit and analyze it. I hope this will be completed during

the

current week and we move to the "Vote preparation" phase to the start of
next week.
I think waiting for another month due to documentation it's too much.
Do we have an option to release with documentation on readme.io and then
move documentation in the new format during next month?



пн, 3 авг. 2020 г. в 17:55, Denis Magda :


I would wait for 3-4 weeks and release the new docs in 2.9. It means

that

the release should be announced the first week of September which is

not

a

huge slip. Moreover, it feels like the testing phase and release

procedures

will not be completed sooner.

So, I would suggest contributing 2.9 related page to the new

documentation

repository.


Denis

On Monday, August 3, 2020, Artem Budnikov 
Hi Maxim,

The new docs project is not finished yet. There are still a lot of

pages

to port to the new format, and we are still working on the

integration

with

the web-site. Nevertheless, we can try to publish the Ignite 2.9
documentation on the web-site in the new format. The documentation

will

not

be 100% complete, but it will be updated significantly and will

contain

most of the information our users need. Actually, I would like to do

that,

but it all depends on how much time I have before Ignite 2.9 is

released.

I'd say 2-3 weeks would be enough for me to finish all tasks that are
critical for the publication.

If we can wait with release 2.9 that much time, then I'll prepare the
instruction on how to contribute to the docs.

What do you think?

-Artem

On 03.08.2020 12:24, Maxim Muzafarov wrote:


Artem,

I'd like to submit some documentation changes for 2.9 release.

Should

I update docs on readme.io or publish it on ignite.apache.org?

On Wed, 29 Jul 2020 at 19:06, Artem Budnikov
 wrote:


Hi Alex,

Sorry, I missed this message. There is still a lot of work on the

docs.

When is version 2.9 going to be released?

-Artem

On 22.07.2020 10:35, Alex Plehanov wrote:


Guys,

What about documentation for 2.9 release

Re: Moving Ignite documentation to github

[Artem Budnikov]

Hi Maxim,

The new docs project is not finished yet. There are still a lot of pages 
to port to the new format, and we are still working on the integration 
with the web-site. Nevertheless, we can try to publish the Ignite 2.9 
documentation on the web-site in the new format. The documentation will 
not be 100% complete, but it will be updated significantly and will 
contain most of the information our users need. Actually, I would like 
to do that, but it all depends on how much time I have before Ignite 2.9 
is released. I'd say 2-3 weeks would be enough for me to finish all 
tasks that are critical for the publication.


If we can wait with release 2.9 that much time, then I'll prepare the 
instruction on how to contribute to the docs.


What do you think?

-Artem

On 03.08.2020 12:24, Maxim Muzafarov wrote:

Artem,

I'd like to submit some documentation changes for 2.9 release. Should
I update docs on readme.io or publish it on ignite.apache.org?

On Wed, 29 Jul 2020 at 19:06, Artem Budnikov
 wrote:

Hi Alex,

Sorry, I missed this message. There is still a lot of work on the docs.
When is version 2.9 going to be released?

-Artem

On 22.07.2020 10:35, Alex Plehanov wrote:

Guys,

What about documentation for 2.9 release? Are we going to publish it on
readme.io or publish it on ignite.apache.org?
What about new edits? Should we still edit pages on readme.io or already
make changes in git repository?
Artem, could you please clarify the current documentation workflow?


пн, 20 июл. 2020 г. в 16:42, Artem Budnikov :


Denis,


How about the next step of taking the HTML and committing it to the

website

repository? Did you have a chance to think through this step?

Yes, I'll look into this this week. This shouldn't be very difficult.

-Artem

On 18.07.2020 00:43, Denis Magda wrote:

Worked out well on my end. Thanks for sending the update!

How about the next step of taking the HTML and committing it to the

website

repository? Did you have a chance to think through this step?

-
Denis


On Fri, Jul 17, 2020 at 5:27 AM Artem Budnikov <

a.budnikov.ign...@gmail.com>

wrote:


Hi everyone,

I've prepared the initial set of source files for the Ignite
documentation. If you are interested, you can take a look at
https://github.com/apache/ignite/tree/IGNITE-7595/docs

You can run a local web-server (jekyll) if you want to view the docs in
your browser. Refer to the README.adoc for instructions. Some people had
troubles installing Jekyll locally, so I added an instruction on how to
use jekyll docker image.

If you have any comments on the overall approach, please let me know.
The styles and content are still a work in progress, so please don't
report issues related to that.

-Artem

On 26.06.2020 01:54, Guru Stron wrote:

+1 for migrating docs to github. It will allow an easier contribution

for

docs, I think. As a nice feature - adding an edit link (submit PR for

docs)

to the document page on site.

As for keeping them separate - Microsoft keeps docs for it's products

in

separate repos, for example.

On Thu, 25 Jun 2020 at 15:48, Artem Budnikov <

a.budnikov.ign...@gmail.com>

wrote:


OK, let's give it a try.

The way I see it, the documentation source files will be located in

the

"/docs" folder, including UI templates/styles, asciidoc files, and

build

scripts. I'll start experimenting with this and will let you know when
basic setup is ready.

-Artem

On 23.06.2020 20:19, Denis Magda wrote:

I believe that by keeping the documentation sources in the same

repository

with the source code will help us to prepare and release all the

release

artifacts at the same time. So, +1 for hosting raw documentation

ascii-doc

pages in the main Ignite repo. However, the HTML version needs to

reside

on

the Ignite website, which is similar to the API docs. We can create

tools

to do this in one click.

Post-reviews are not prohibited in Apache, quite the opposite, and

they

suit the documentation contribution process better. It's ok if

committers

to the documentation merge the changes first and ask for a review

later

if

needed.

-
Denis


On Tue, Jun 23, 2020 at 6:53 AM Artem Budnikov <

a.budnikov.ign...@gmail.com>

wrote:


Pavel,


I don't think so: we can't add snippets pointing to new APIs from a
separate repo,

Snippets are kept together with the docs, they /don't need/ to be

stored

in the main repo, although they can. They are compilable and up to

date.

I update the docs and API samples for features that hasn't been

released

in the GridGain docs and never thought it was a problem. I

understand

that you don't want to do extra work when adding code samples, but

it

looks like just an inconvenience. Let me suggest this: Let's think

about

a solution that will be comfortable for you, I'm pretty sure this
inconvenience can be solved technically. But I need time to think 

Re: Moving Ignite documentation to github

[Artem Budnikov]

Hi Alex,

Sorry, I missed this message. There is still a lot of work on the docs. 
When is version 2.9 going to be released?


-Artem

On 22.07.2020 10:35, Alex Plehanov wrote:

Guys,

What about documentation for 2.9 release? Are we going to publish it on
readme.io or publish it on ignite.apache.org?
What about new edits? Should we still edit pages on readme.io or already
make changes in git repository?
Artem, could you please clarify the current documentation workflow?


пн, 20 июл. 2020 г. в 16:42, Artem Budnikov :


Denis,


How about the next step of taking the HTML and committing it to the

website

repository? Did you have a chance to think through this step?

Yes, I'll look into this this week. This shouldn't be very difficult.

-Artem

On 18.07.2020 00:43, Denis Magda wrote:

Worked out well on my end. Thanks for sending the update!

How about the next step of taking the HTML and committing it to the

website

repository? Did you have a chance to think through this step?

-
Denis


On Fri, Jul 17, 2020 at 5:27 AM Artem Budnikov <

a.budnikov.ign...@gmail.com>

wrote:


Hi everyone,

I've prepared the initial set of source files for the Ignite
documentation. If you are interested, you can take a look at
https://github.com/apache/ignite/tree/IGNITE-7595/docs

You can run a local web-server (jekyll) if you want to view the docs in
your browser. Refer to the README.adoc for instructions. Some people had
troubles installing Jekyll locally, so I added an instruction on how to
use jekyll docker image.

If you have any comments on the overall approach, please let me know.
The styles and content are still a work in progress, so please don't
report issues related to that.

-Artem

On 26.06.2020 01:54, Guru Stron wrote:

+1 for migrating docs to github. It will allow an easier contribution

for

docs, I think. As a nice feature - adding an edit link (submit PR for

docs)

to the document page on site.

As for keeping them separate - Microsoft keeps docs for it's products

in

separate repos, for example.

On Thu, 25 Jun 2020 at 15:48, Artem Budnikov <

a.budnikov.ign...@gmail.com>

wrote:


OK, let's give it a try.

The way I see it, the documentation source files will be located in

the

"/docs" folder, including UI templates/styles, asciidoc files, and

build

scripts. I'll start experimenting with this and will let you know when
basic setup is ready.

-Artem

On 23.06.2020 20:19, Denis Magda wrote:

I believe that by keeping the documentation sources in the same

repository

with the source code will help us to prepare and release all the

release

artifacts at the same time. So, +1 for hosting raw documentation

ascii-doc

pages in the main Ignite repo. However, the HTML version needs to

reside

on

the Ignite website, which is similar to the API docs. We can create

tools

to do this in one click.

Post-reviews are not prohibited in Apache, quite the opposite, and

they

suit the documentation contribution process better. It's ok if

committers

to the documentation merge the changes first and ask for a review

later

if

needed.

-
Denis


On Tue, Jun 23, 2020 at 6:53 AM Artem Budnikov <

a.budnikov.ign...@gmail.com>

wrote:


Pavel,


I don't think so: we can't add snippets pointing to new APIs from a
separate repo,

Snippets are kept together with the docs, they /don't need/ to be

stored

in the main repo, although they can. They are compilable and up to

date.

I update the docs and API samples for features that hasn't been

released

in the GridGain docs and never thought it was a problem. I

understand

that you don't want to do extra work when adding code samples, but

it

looks like just an inconvenience. Let me suggest this: Let's think

about

a solution that will be comfortable for you, I'm pretty sure this
inconvenience can be solved technically. But I need time to think it
through.


we can't see the docs when doing global search (and/or replace)

from

the IDE.

I think you can add the docs repo to your IDE as a project. I used

to

do

it in the beginning but then switched to Sublime Text, because it's

more

convenient to me. We are looking at it from different perspectives.

I'm

trying to create a process that is comfortable for tech writers

rather

than developers. And everybody has to accept some kind of a

compromise:)

Well, no one is able to "freely" commit code to Apache master,

there

is a process to follow - CI, reviews, etc.
Same should happen for the docs, separate repo or not.
But a separate repo will require separate ownership/management
(probably?),
but we already have everything in the main repo, why introduce

overhead?

Just think about it from my perspective. That creates a HUUUGE

overhead

for technical writers who work on the docs, and they are the ones

who

provide 90% of updates. I agree about the review process, and I'm

go

Re: Moving Ignite documentation to github

[Artem Budnikov]

Denis,


How about the next step of taking the HTML and committing it to the website
repository? Did you have a chance to think through this step?


Yes, I'll look into this this week. This shouldn't be very difficult.

-Artem

On 18.07.2020 00:43, Denis Magda wrote:

Worked out well on my end. Thanks for sending the update!

How about the next step of taking the HTML and committing it to the website
repository? Did you have a chance to think through this step?

-
Denis


On Fri, Jul 17, 2020 at 5:27 AM Artem Budnikov 
wrote:


Hi everyone,

I've prepared the initial set of source files for the Ignite
documentation. If you are interested, you can take a look at
https://github.com/apache/ignite/tree/IGNITE-7595/docs

You can run a local web-server (jekyll) if you want to view the docs in
your browser. Refer to the README.adoc for instructions. Some people had
troubles installing Jekyll locally, so I added an instruction on how to
use jekyll docker image.

If you have any comments on the overall approach, please let me know.
The styles and content are still a work in progress, so please don't
report issues related to that.

-Artem

On 26.06.2020 01:54, Guru Stron wrote:

+1 for migrating docs to github. It will allow an easier contribution for
docs, I think. As a nice feature - adding an edit link (submit PR for

docs)

to the document page on site.

As for keeping them separate - Microsoft keeps docs for it's products in
separate repos, for example.

On Thu, 25 Jun 2020 at 15:48, Artem Budnikov <

a.budnikov.ign...@gmail.com>

wrote:


OK, let's give it a try.

The way I see it, the documentation source files will be located in the
"/docs" folder, including UI templates/styles, asciidoc files, and build
scripts. I'll start experimenting with this and will let you know when
basic setup is ready.

-Artem

On 23.06.2020 20:19, Denis Magda wrote:

I believe that by keeping the documentation sources in the same

repository

with the source code will help us to prepare and release all the

release

artifacts at the same time. So, +1 for hosting raw documentation

ascii-doc

pages in the main Ignite repo. However, the HTML version needs to

reside

on

the Ignite website, which is similar to the API docs. We can create

tools

to do this in one click.

Post-reviews are not prohibited in Apache, quite the opposite, and they
suit the documentation contribution process better. It's ok if

committers

to the documentation merge the changes first and ask for a review later

if

needed.

-
Denis


On Tue, Jun 23, 2020 at 6:53 AM Artem Budnikov <

a.budnikov.ign...@gmail.com>

wrote:


Pavel,


I don't think so: we can't add snippets pointing to new APIs from a
separate repo,

Snippets are kept together with the docs, they /don't need/ to be

stored

in the main repo, although they can. They are compilable and up to

date.

I update the docs and API samples for features that hasn't been

released

in the GridGain docs and never thought it was a problem. I understand
that you don't want to do extra work when adding code samples, but it
looks like just an inconvenience. Let me suggest this: Let's think

about

a solution that will be comfortable for you, I'm pretty sure this
inconvenience can be solved technically. But I need time to think it
through.


we can't see the docs when doing global search (and/or replace) from
the IDE.

I think you can add the docs repo to your IDE as a project. I used to

do

it in the beginning but then switched to Sublime Text, because it's

more

convenient to me. We are looking at it from different perspectives.

I'm

trying to create a process that is comfortable for tech writers rather
than developers. And everybody has to accept some kind of a

compromise:)

Well, no one is able to "freely" commit code to Apache master, there
is a process to follow - CI, reviews, etc.
Same should happen for the docs, separate repo or not.
But a separate repo will require separate ownership/management
(probably?),
but we already have everything in the main repo, why introduce

overhead?

Just think about it from my perspective. That creates a HUUUGE

overhead

for technical writers who work on the docs, and they are the ones who
provide 90% of updates. I agree about the review process, and I'm

going

to think it over. But now it seems that we don't have to impose any
strict process that impedes preparation of the docs.

-Artem


On 23.06.2020 15:35, Pavel Tupitsyn wrote:

all your pros points work just as well for a separate repository

I don't think so: we can't add snippets pointing to new APIs from a
separate repo,
we can't see the docs when doing global search (and/or replace) from
the IDE.


I am able to freely commit to master

Well, no one is able to "freely" commit code to Apache master, there
is a process to follow - CI, reviews, etc.
Same

Re: Moving Ignite documentation to github

[Artem Budnikov]

Hi everyone,

I've prepared the initial set of source files for the Ignite 
documentation. If you are interested, you can take a look at 
https://github.com/apache/ignite/tree/IGNITE-7595/docs


You can run a local web-server (jekyll) if you want to view the docs in 
your browser. Refer to the README.adoc for instructions. Some people had 
troubles installing Jekyll locally, so I added an instruction on how to 
use jekyll docker image.


If you have any comments on the overall approach, please let me know. 
The styles and content are still a work in progress, so please don't 
report issues related to that.


-Artem

On 26.06.2020 01:54, Guru Stron wrote:

+1 for migrating docs to github. It will allow an easier contribution for
docs, I think. As a nice feature - adding an edit link (submit PR for docs)
to the document page on site.

As for keeping them separate - Microsoft keeps docs for it's products in
separate repos, for example.

On Thu, 25 Jun 2020 at 15:48, Artem Budnikov 
wrote:


OK, let's give it a try.

The way I see it, the documentation source files will be located in the
"/docs" folder, including UI templates/styles, asciidoc files, and build
scripts. I'll start experimenting with this and will let you know when
basic setup is ready.

-Artem

On 23.06.2020 20:19, Denis Magda wrote:

I believe that by keeping the documentation sources in the same

repository

with the source code will help us to prepare and release all the release
artifacts at the same time. So, +1 for hosting raw documentation

ascii-doc

pages in the main Ignite repo. However, the HTML version needs to reside

on

the Ignite website, which is similar to the API docs. We can create tools
to do this in one click.

Post-reviews are not prohibited in Apache, quite the opposite, and they
suit the documentation contribution process better. It's ok if committers
to the documentation merge the changes first and ask for a review later

if

needed.

-
Denis


On Tue, Jun 23, 2020 at 6:53 AM Artem Budnikov <

a.budnikov.ign...@gmail.com>

wrote:


Pavel,


I don't think so: we can't add snippets pointing to new APIs from a
separate repo,

Snippets are kept together with the docs, they /don't need/ to be stored
in the main repo, although they can. They are compilable and up to date.
I update the docs and API samples for features that hasn't been released
in the GridGain docs and never thought it was a problem. I understand
that you don't want to do extra work when adding code samples, but it
looks like just an inconvenience. Let me suggest this: Let's think about
a solution that will be comfortable for you, I'm pretty sure this
inconvenience can be solved technically. But I need time to think it
through.


we can't see the docs when doing global search (and/or replace) from
the IDE.

I think you can add the docs repo to your IDE as a project. I used to do
it in the beginning but then switched to Sublime Text, because it's more
convenient to me. We are looking at it from different perspectives. I'm
trying to create a process that is comfortable for tech writers rather
than developers. And everybody has to accept some kind of a compromise:)


Well, no one is able to "freely" commit code to Apache master, there
is a process to follow - CI, reviews, etc.
Same should happen for the docs, separate repo or not.
But a separate repo will require separate ownership/management
(probably?),
but we already have everything in the main repo, why introduce

overhead?

Just think about it from my perspective. That creates a HUUUGE overhead
for technical writers who work on the docs, and they are the ones who
provide 90% of updates. I agree about the review process, and I'm going
to think it over. But now it seems that we don't have to impose any
strict process that impedes preparation of the docs.

-Artem


On 23.06.2020 15:35, Pavel Tupitsyn wrote:

all your pros points work just as well for a separate repository

I don't think so: we can't add snippets pointing to new APIs from a
separate repo,
we can't see the docs when doing global search (and/or replace) from
the IDE.


I am able to freely commit to master

Well, no one is able to "freely" commit code to Apache master, there
is a process to follow - CI, reviews, etc.
Same should happen for the docs, separate repo or not.
But a separate repo will require separate ownership/management
(probably?),
but we already have everything in the main repo, why introduce

overhead?

On Tue, Jun 23, 2020 at 2:59 PM Artem Budnikov
mailto:a.budnikov.ign...@gmail.com>>

wrote:

  Pavel,

  As far as I can see, all your pros points work just as well for a
  separate repository (except for "everybody knows about it"). I

don't

  mind keeping the docs in Ignite repo as long as I am able to

freely

  commit to master. Will I be able

Re: New committer: Artem Budnikov

[Artem Budnikov]

Thanks, guys.

-Artem

On 16.07.2020 15:47, Вячеслав Коптилин wrote:

Hello Artem,

Congratulations! You definitely deserve it.

Thanks,
S.

чт, 16 июл. 2020 г. в 15:26, Ivan Pavlukhin :


Artem, my congratulations!

2020-07-16 15:10 GMT+03:00, Roman Kondakov :

Congrats, Artem!

--
Roman Kondakov

On 16.07.2020 14:19, Ilya Kasnacheev wrote:

Hello!

The Project Management Committee for Apache Ignite project has invited
Artem Budnikov to become a committer and we are pleased to announce that
he
has accepted.

He is the person behind a monumental effort to keep Apache Ignite
documentation neat and tidy, which he does by writing, reviewing and
versioning most of docs on apacheignite.readme.io.

Being a committer enables easier contribution to the project since it
makes
possible to merge your own, or other contributors', changes after the
review. This should enable better productivity.

On behalf of Apache Ignite PMC,



--

Best regards,
Ivan Pavlukhin

Re: Moving Ignite documentation to github

[Artem Budnikov]

OK, let's give it a try.

The way I see it, the documentation source files will be located in the 
"/docs" folder, including UI templates/styles, asciidoc files, and build 
scripts. I'll start experimenting with this and will let you know when 
basic setup is ready.


-Artem

On 23.06.2020 20:19, Denis Magda wrote:

I believe that by keeping the documentation sources in the same repository
with the source code will help us to prepare and release all the release
artifacts at the same time. So, +1 for hosting raw documentation ascii-doc
pages in the main Ignite repo. However, the HTML version needs to reside on
the Ignite website, which is similar to the API docs. We can create tools
to do this in one click.

Post-reviews are not prohibited in Apache, quite the opposite, and they
suit the documentation contribution process better. It's ok if committers
to the documentation merge the changes first and ask for a review later if
needed.

-
Denis


On Tue, Jun 23, 2020 at 6:53 AM Artem Budnikov 
wrote:


Pavel,


I don't think so: we can't add snippets pointing to new APIs from a
separate repo,

Snippets are kept together with the docs, they /don't need/ to be stored
in the main repo, although they can. They are compilable and up to date.
I update the docs and API samples for features that hasn't been released
in the GridGain docs and never thought it was a problem. I understand
that you don't want to do extra work when adding code samples, but it
looks like just an inconvenience. Let me suggest this: Let's think about
a solution that will be comfortable for you, I'm pretty sure this
inconvenience can be solved technically. But I need time to think it
through.


we can't see the docs when doing global search (and/or replace) from
the IDE.

I think you can add the docs repo to your IDE as a project. I used to do
it in the beginning but then switched to Sublime Text, because it's more
convenient to me. We are looking at it from different perspectives. I'm
trying to create a process that is comfortable for tech writers rather
than developers. And everybody has to accept some kind of a compromise:)


Well, no one is able to "freely" commit code to Apache master, there
is a process to follow - CI, reviews, etc.
Same should happen for the docs, separate repo or not.
But a separate repo will require separate ownership/management
(probably?),
but we already have everything in the main repo, why introduce overhead?

Just think about it from my perspective. That creates a HUUUGE overhead
for technical writers who work on the docs, and they are the ones who
provide 90% of updates. I agree about the review process, and I'm going
to think it over. But now it seems that we don't have to impose any
strict process that impedes preparation of the docs.

-Artem


On 23.06.2020 15:35, Pavel Tupitsyn wrote:

all your pros points work just as well for a separate repository

I don't think so: we can't add snippets pointing to new APIs from a
separate repo,
we can't see the docs when doing global search (and/or replace) from
the IDE.


I am able to freely commit to master

Well, no one is able to "freely" commit code to Apache master, there
is a process to follow - CI, reviews, etc.
Same should happen for the docs, separate repo or not.
But a separate repo will require separate ownership/management
(probably?),
but we already have everything in the main repo, why introduce overhead?

On Tue, Jun 23, 2020 at 2:59 PM Artem Budnikov
mailto:a.budnikov.ign...@gmail.com>>

wrote:

 Pavel,

 As far as I can see, all your pros points work just as well for a
 separate repository (except for "everybody knows about it"). I don't
 mind keeping the docs in Ignite repo as long as I am able to freely
 commit to master. Will I be able to do that?

 -Artem

 On 23.06.2020 14:04, Pavel Tupitsyn wrote:
 > Ilya, Artem,
 >
 > "Separate repo just because we can't finish docs before release"
 > does not make sense to me. My proposal is:
 >
 > - Working version is in the master branch
 > - When a release branch is created, e.g. ignite-2.9, we create
 > ignite-2.9-docs and update it as long as we want.
 >
 > Pros (compared to a separate repo):
 > - Docs can be updated along with the code, same review process
 > - Visibility - everyone knows about main repo, docs are
 searchable together
 > with code in the IDE
 > - Code snippets can reference the actual code and we make sure
 they compile
 > - Code snippets can be tested on TC
 >
 > GridGain uses a separate repo for their docs, and it proved to
 be less than
 > optimal.
 > Especially when adding samples for new APIs which are not yet
 released.
 >
 >
 >
 

Re: Moving Ignite documentation to github

[Artem Budnikov]

Pavel,

I don't think so: we can't add snippets pointing to new APIs from a 
separate repo,
Snippets are kept together with the docs, they /don't need/ to be stored 
in the main repo, although they can. They are compilable and up to date. 
I update the docs and API samples for features that hasn't been released 
in the GridGain docs and never thought it was a problem. I understand 
that you don't want to do extra work when adding code samples, but it 
looks like just an inconvenience. Let me suggest this: Let's think about 
a solution that will be comfortable for you, I'm pretty sure this 
inconvenience can be solved technically. But I need time to think it 
through.


we can't see the docs when doing global search (and/or replace) from 
the IDE.
I think you can add the docs repo to your IDE as a project. I used to do 
it in the beginning but then switched to Sublime Text, because it's more 
convenient to me. We are looking at it from different perspectives. I'm 
trying to create a process that is comfortable for tech writers rather 
than developers. And everybody has to accept some kind of a compromise:)


Well, no one is able to "freely" commit code to Apache master, there 
is a process to follow - CI, reviews, etc.

Same should happen for the docs, separate repo or not.
But a separate repo will require separate ownership/management 
(probably?),

but we already have everything in the main repo, why introduce overhead?
Just think about it from my perspective. That creates a HUUUGE overhead 
for technical writers who work on the docs, and they are the ones who 
provide 90% of updates. I agree about the review process, and I'm going 
to think it over. But now it seems that we don't have to impose any 
strict process that impedes preparation of the docs.


-Artem


On 23.06.2020 15:35, Pavel Tupitsyn wrote:

> all your pros points work just as well for a separate repository
I don't think so: we can't add snippets pointing to new APIs from a 
separate repo,
we can't see the docs when doing global search (and/or replace) from 
the IDE.


> I am able to freely commit to master
Well, no one is able to "freely" commit code to Apache master, there 
is a process to follow - CI, reviews, etc.

Same should happen for the docs, separate repo or not.
But a separate repo will require separate ownership/management 
(probably?),

but we already have everything in the main repo, why introduce overhead?

On Tue, Jun 23, 2020 at 2:59 PM Artem Budnikov 
mailto:a.budnikov.ign...@gmail.com>> wrote:


Pavel,

As far as I can see, all your pros points work just as well for a
separate repository (except for "everybody knows about it"). I don't
mind keeping the docs in Ignite repo as long as I am able to freely
commit to master. Will I be able to do that?

-Artem

On 23.06.2020 14:04, Pavel Tupitsyn wrote:
> Ilya, Artem,
>
> "Separate repo just because we can't finish docs before release"
> does not make sense to me. My proposal is:
>
> - Working version is in the master branch
> - When a release branch is created, e.g. ignite-2.9, we create
> ignite-2.9-docs and update it as long as we want.
>
> Pros (compared to a separate repo):
> - Docs can be updated along with the code, same review process
> - Visibility - everyone knows about main repo, docs are
searchable together
> with code in the IDE
> - Code snippets can reference the actual code and we make sure
they compile
> - Code snippets can be tested on TC
>
> GridGain uses a separate repo for their docs, and it proved to
be less than
> optimal.
> Especially when adding samples for new APIs which are not yet
released.
>
>
>
> On Tue, Jun 23, 2020 at 1:19 PM Artem Budnikov
mailto:a.budnikov.ign...@gmail.com>>
> wrote:
>
>> Pavel,
>>
>> Yes, I mean a separate repository. The reason is that
documentation is
>> usually updated after the product version is released. As Ilya
pointed
>> out, keeping the docs in the main Ignite repository would entail
>> completing the docs before the release date, which is not
possible under
>> current circumstances.
>>
>> Ilya,
>>
>> You can look at your company's documentation for a working
prototype
>> turned production-ready approach. The approach has been tested
for a
>> while and proved to be successful, at least with respect to our
goals here.
>>
>> -Artem
>>
>> On 23.06.2020 12:48, Ilya Kasnacheev wrote:
>>> Hello!
>>>
>>> I'm not really sold o

Re: Moving Ignite documentation to github

[Artem Budnikov]

Pavel,

As far as I can see, all your pros points work just as well for a 
separate repository (except for "everybody knows about it"). I don't 
mind keeping the docs in Ignite repo as long as I am able to freely 
commit to master. Will I be able to do that?


-Artem

On 23.06.2020 14:04, Pavel Tupitsyn wrote:

Ilya, Artem,

"Separate repo just because we can't finish docs before release"
does not make sense to me. My proposal is:

- Working version is in the master branch
- When a release branch is created, e.g. ignite-2.9, we create
ignite-2.9-docs and update it as long as we want.

Pros (compared to a separate repo):
- Docs can be updated along with the code, same review process
- Visibility - everyone knows about main repo, docs are searchable together
with code in the IDE
- Code snippets can reference the actual code and we make sure they compile
- Code snippets can be tested on TC

GridGain uses a separate repo for their docs, and it proved to be less than
optimal.
Especially when adding samples for new APIs which are not yet released.



On Tue, Jun 23, 2020 at 1:19 PM Artem Budnikov 
wrote:


Pavel,

Yes, I mean a separate repository. The reason is that documentation is
usually updated after the product version is released. As Ilya pointed
out, keeping the docs in the main Ignite repository would entail
completing the docs before the release date, which is not possible under
current circumstances.

Ilya,

You can look at your company's documentation for a working prototype
turned production-ready approach. The approach has been tested for a
while and proved to be successful, at least with respect to our goals here.

-Artem

On 23.06.2020 12:48, Ilya Kasnacheev wrote:

Hello!

I'm not really sold on the github version yet, I would like to see a
prototype of such documentation before deciding, so for me it'w
0

Pavel, we don't have enough discipline to make sure that all

documentation

is ready at the time of release, and we may need to add notices here and
there after a release is already out. This means, separate git

repository,

or at least separate git tag on that repository, is needed.

Regards,

Re: Moving Ignite documentation to github

[Artem Budnikov]

Pavel,

Yes, I mean a separate repository. The reason is that documentation is 
usually updated after the product version is released. As Ilya pointed 
out, keeping the docs in the main Ignite repository would entail 
completing the docs before the release date, which is not possible under 
current circumstances.


Ilya,

You can look at your company's documentation for a working prototype 
turned production-ready approach. The approach has been tested for a 
while and proved to be successful, at least with respect to our goals here.


-Artem

On 23.06.2020 12:48, Ilya Kasnacheev wrote:

Hello!

I'm not really sold on the github version yet, I would like to see a
prototype of such documentation before deciding, so for me it'w
0

Pavel, we don't have enough discipline to make sure that all documentation
is ready at the time of release, and we may need to add notices here and
there after a release is already out. This means, separate git repository,
or at least separate git tag on that repository, is needed.

Regards,

Moving Ignite documentation to github

[Artem Budnikov]

Hello Igniters,

I'd like to return to the discussion about migrating the Ignite 
documentation from readme.io to github. The idea emerged long time ago 
[1] but hasn't been implemented. I think now is the time to make it happen.


Here are the technical details of the proposed solution:

 * docs are written in asciidoc format and stored in a github repository
 * jekyll is used to generate HTML pages out of the adoc files
 * HTML pages are published on ignite.apache.org in the documentation
   section

This approach is very flexible and allows us to implement any feature 
that we need (as opposed to readme.io, which is very limited).


Also, as part of this plan, it makes sense to unite the documentation 
for different platforms (java, .NET, c++).


I'm interested in what you have to say about this. Please share your 
thoughts.


-Artem

[1]: 
http://apache-ignite-developers.2346864.n4.nabble.com/Move-documentation-from-readme-io-to-GitHub-pages-td16409.html

Re: Ignite 2.8 documentation

[Artem Budnikov]

Correct. This page shouldn't be published.

-Artem

On Thu, Mar 19, 2020 at 5:35 PM 18624049226 <18624049...@163.com> wrote:

> Hi Artem,
>
> https://apacheignite.readme.io/docs/partition-map-exchange-27
>
> This page has no corresponding menu link, is it correct?
>
> 在 2020/3/17 上午12:47, Denis Magda 写道:
> > Artem,
> >
> > I'll create a ticket for the IGFS docs replacement once we publish the
> new
> > website that we'll have all the references needed to create new pages
> that
> > will replace the IGFS content.
> >
> > @Yuriy Gerzhedovich , could you please help
> > with the SQL questions?
> >
> > -
> > Denis
> >
> >
> > On Mon, Mar 16, 2020 at 12:22 AM Artem Budnikov <
> a.budnikov.ign...@gmail.com>
> > wrote:
> >
> >> Can anyone give some details about those missing features so I can
> >> document them?
> >>
> >> -Artem
> >>
> >> On 15.03.2020 05:31, 18624049226 wrote:
> >>> Hi,
> >>>
> >>> I don't know the missing part. Is there any developer willing to add
> it?
> >>>
> >>> In addition, as far as I know, IGFS and Hadoop accelerator related
> >>> components of ignite have been discarded, should related documents
> >>> also be deleted?
> >>>
> >>> 在 2020/3/13 上午6:08, Ivan Pavlukhin 写道:
> >>>> Hi,
> >>>>
> >>>>> There are the following functions. I haven't found the related
> >>>>> documents. Please confirm again?
> >>>> Thank you for checking this thoroughly! I looked into SQL and JDBC
> >>>> items.
> >>>>
> >>>>> 1.SQL:Added KILL QUERY command
> >>>> Here it is https://apacheignite-sql.readme.io/docs/kill-query but it
> >>>> seems no link from a parent page [1]
> >>>>
> >>>>> 4.JDBC:Added cache expiry policies
> >>>> Sounds strange because I an not sure that this feature was
> implemented.
> >>>>
> >>>> All other pointed SQL and JDBS items seems to be missing =(
> >>>>
> >>>> Best regards,
> >>>> Ivan Pavlukhin
> >>>>
> >>>> чт, 12 мар. 2020 г. в 15:04, 18624049226 <18624049...@163.com>:
> >>>>> Hi igniters,
> >>>>>
> >>>>> There are the following functions. I haven't found the related
> >>>>> documents. Please confirm again?
> >>>>>
> >>>>> 1.SQL:Added KILL QUERY command
> >>>>>
> >>>>> 2.SQL:Added ability to specify query parallelism in CREATE TABLE's
> WITH
> >>>>> "" clause
> >>>>>
> >>>>> 3.SQL:Added default query timeout
> >>>>>
> >>>>> 4.JDBC:Added cache expiry policies
> >>>>>
> >>>>> 5.JDBC:Added support JDBC thin driver: connection timeout
> >>>>>
> >>>>> 6.JDBC:Added support query cancel
> >>>>>
> >>>>> 7.JDBC:Added support query timeout
> >>>>>
> >>>>> 8.REST:Added "caches" param for "top" command
> >>>>>
> >>>>> 9.REST:Added baseline topology commands to REST API
> >>>>>
> >>>>> 10.REST:Added memory policy metrics via REST
> >>>>>
> >>>>> These are great improvements, and without documentation, developers
> may
> >>>>> not know how to use them.
> >>>>>
> >>>>>
> >>>>> 在 2020/3/12 上午1:40, Artem Budnikov 写道:
> >>>>>> Denis,
> >>>>>>
> >>>>>> I made version 2.8 the main version on readme.io. Everybody can see
> >>>>>> it now.
> >>>>>>
> >>>>>> -Artem
> >>>>>>
> >>>>>> On Wed, Mar 11, 2020 at 7:35 PM Denis Magda 
> >> wrote:
> >>>>>>> Artem,
> >>>>>>>
> >>>>>>> Understood, let's see what Alexey says. As of now, I would suggest
> we
> >>>>>>> publishing the existing ML pages and improve the content with no
> >>>>>>> rush.
> >>>>>>> Could you also make a 2.8 version the default one? 2.7.6 is still
> >>>>>>> selected
&g

Re: About readme.io's latest docs

[Artem Budnikov]

Hi,

I didn't include those sections because they had not changed since the last
version (2.7).

-Artem

On Thu, Mar 19, 2020 at 1:01 PM 18624049226 <18624049...@163.com> wrote:

> Hi Artem,
>
> *apacheignite-fs,apacheignite-mix,apacheignite-tools*
>
> these three parts, is it missing?confirm again?
>
> thank you very much!
>
> 在 2020/3/19 下午3:41, Artem Budnikov 写道:
> > Hi,
> >
> > Please find the archive with the latest docs attached.
> >
> > -Artem
> >
> > On Thu, Mar 19, 2020 at 6:32 AM 18624049226 <18624049...@163.com
> > <mailto:18624049...@163.com>> wrote:
> >
> > Hi Artem,
> >
> > Can you help to export all the latest version of all documents to me?
> > I am ready to make a synchronization of the chinese version of the
> > document.
> >
> > thanks!
> >
> > 在 2018/12/20 上午8:49, 李玉珏@163 写道:
> > >
> > > Received，thanks!
> > >
> > >
> > > 在 2018/12/20 上午12:55, Prachi Garg 写道:
> > >> Hi
> > >>
> > >> Please see attached.
> > >>
> > >> -Prachi
> > >>
> > >> On Wed, Dec 19, 2018 at 1:47 AM 李玉珏@163 <18624049...@163.com
> > <mailto:18624049...@163.com>
> > >> <mailto:18624049...@163.com <mailto:18624049...@163.com>>> wrote:
> > >>
> > >> Hi,Prachi:
> > >>
> > >> Can you help me?
> > >>
> > >> Previous email have not been answered.
> > >>
> > >> Thank you very much!
> > >>
> > >> 在 2018/12/10 下午7:33, 李玉珏@163 写道:
> > >>>
> > >>> Prachi,
> > >>>
> > >>>
> > >>> Can you help to export all the latest version of all
> documents
> > >>> to me?
> > >>> I am ready to make a synchronization of the chinese version
> of
> > >>> the document.
> > >>>
> > >>> thanks!
> > >>>
> > >>>
> > >>> 在 2018/6/2 上午4:38, Prachi Garg 写道:
> > >>>> Please see attached.
> > >>>>
> > >>>> On Fri, Jun 1, 2018 at 9:22 AM, 李玉珏@163
> > <18624049...@163.com <mailto:18624049...@163.com>
> > >>>> <mailto:18624049...@163.com
> > <mailto:18624049...@163.com>>> wrote:
> > >>>>
> > >>>> Prachi,
> > >>>>
> > >>>>
> > >>>> Can you help to export all the latest version of all
> > >>>> documents to me?
> > >>>> I am ready to make a synchronization of the chinese
> > version
> > >>>> of the document.
> > >>>>
> > >>>> thanks!
> > >>>>
> > >>>>
> > >>>> 在 2017/11/24 下午1:33, Prachi Garg 写道:
> > >>>>> Attached.
> > >>>>>
> > >>>>> On Wed, Nov 15, 2017 at 4:41 AM, 李玉珏@163
> > >>>>> <18624049...@163.com <mailto:18624049...@163.com>
> > <mailto:18624049...@163.com <mailto:18624049...@163.com>>> wrote:
> > >>>>>
> > >>>>> Prachi,
> > >>>>>
> > >>>>>
> > >>>>> Can you help me to export all the latest version of
> > >>>>> all documents to me?
> > >>>>> I am ready to make a synchronization of the chinese
> > >>>>> version of the document.
> > >>>>>
> > >>>>> thanks!
> > >>>>>
> > >>>>> 在 2017/8/17 上午2:05, Prachi Garg 写道:
> > >>>>>> Please see attached.
> > >>>>>>
> > >>>>>> -P
> > >>>>>>
> > >>>>>> On Wed, Aug 9, 2017 at 11:19 AM, Denis Magda
> > >>>>>> 

Re: [DISCUSSION] Changes in Ignite release process related to documentation

[Artem Budnikov]

Denis,

Both yours and Andrey's proposal are important. You should start to vote
after the documentation is ready, just like you start to vote after all
features are ready, and documentation is just another feature. However, the
documentation can't be prepared if there is no information on the features.
Implementing the feature and working on the docs should go in tandem. As
Andrey pointed out it brings some benefits, and makes you more
conscious about the "user" aspect of the feature, which is generally a good
thing.

-Artem

On Tue, Mar 17, 2020 at 11:59 PM Denis Magda  wrote:

> Hi Pavel,
>
> We're thinking about the same in regards to the future of Ignite
> documentation :) Artem and I had some kitchen talks recently and we'll
> restart that activity. Ignite definitely deserves and requires next-gen
> docs. Artem promised to share his thoughts soon.
>
> Btw, check out How to write effective documentation for your open-source
> projec t article that I
> found in one of my newsletters today. It feels like it can be used as a
> reference by Igniters on some best practices.
>
> Denis Magda
>
>
> On Tue, Mar 17, 2020 at 1:03 PM Pavel Tupitsyn 
> wrote:
>
> > I agree with Andrey.
> >
> > And I'd like to reopen the discussion on "moving docs from readme.io to
> > git" [1] [2]
> > Looks like we reached some agreement there but never moved on with the
> > migration.
> >
> >
> > [1]
> >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Move-documentation-from-readme-io-to-GitHub-pages-td16409.html
> > [2] https://issues.apache.org/jira/browse/IGNITE-7595
> >
> > On Tue, Mar 17, 2020 at 9:48 PM Denis Magda  wrote:
> >
> > > Andrey,
> > >
> > > Thanks for sharing your thoughts. Your second point made me recall
> > several
> > > occasions when only after a release of some public APIs we had a chance
> > to
> > > complete documentation and discovered the APIs' ineffectiveness and
> > oddness
> > > from the user usage perspective. But it was already late.
> > >
> > > Generally, if to move incrementally with documentation process changes,
> > > "documentation readiness before the vote" should work as the first step
> > for
> > > us. There will be delays with the vote for sure because we have to get
> > used
> > > to this change, but over time we should get to the point when
> > documentation
> > > will be prepared upon overall task resolution. Andrey, Artem, do you
> > agree
> > > with that?
> > >
> > > Other community members, please share your thoughts. If we don't hear
> any
> > > opposite opinions, then I would update our release procedures with this
> > > change.
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Mon, Mar 16, 2020 at 9:44 AM Andrey Gura  wrote:
> > >
> > > > Denis,
> > > >
> > > > I agree with you.
> > > >
> > > > Also I think that we should move to process which will require
> > > > documentation updates during work on issue/feature and will part of
> > > > code review process. Such approach has some useful benefits:
> > > >
> > > > - Documentation readiness at the same time when fix/implementation is
> > > > ready (remember, documentation is part of a product).
> > > > - Work on documentation and review could discover incompleteness of a
> > > > fix or a feature on earlier stage (It is usual situation when some
> > > > aspects were just forgotten, but documentation writing could
> spotlight
> > > > such things).
> > > >
> > > > On Thu, Mar 12, 2020 at 7:49 PM Denis Magda 
> wrote:
> > > > >
> > > > > Igniters,
> > > > >
> > > > > With the final 2.8 release steps checked out today by announcing
> the
> > > > > version globally (congrats!), it's a proper time to consider and
> > tweak
> > > > our
> > > > > release process, making completion of some phases more predictable
> > and
> > > > > aligned. I would like to dedicate this thread solely to changes
> > related
> > > > to
> > > > > the documentation.
> > > > >
> > > > > If to do a recap, Ignite 2.8 announcement went out of sync with the
> > > > > publication of binaries, Maven and other artifacts because our
> > > technical
> > > > > documentation was completed long after the vote had been closed.
> > > > >
> > > > > We can easily eliminate such glitches for future releases if agree
> to
> > > > start
> > > > > a vote only if Ignite docs are ready and can be published the same
> > day
> > > > with
> > > > > other release artifacts. If the docs are completed and available
> > > > > internally while the vote goes then we can work on a release blog
> > post
> > > > > (referring to docs details) and announce the release the same day
> > when
> > > > the
> > > > > binaries/docs availability.
> > > > >
> > > > > Thoughts? Let's change the process ensuring that the vote can be
> > > started
> > > > > only if technical documentation is ready to be released?
> > > > >
> > > > > -
> > > > > Denis
> > > >
> > >
> >
>

Re: Ignite 2.8 documentation

[Artem Budnikov]

Can anyone give some details about those missing features so I can 
document them?


-Artem

On 15.03.2020 05:31, 18624049226 wrote:

Hi,

I don't know the missing part. Is there any developer willing to add it?

In addition, as far as I know, IGFS and Hadoop accelerator related 
components of ignite have been discarded, should related documents 
also be deleted?


在 2020/3/13 上午6:08, Ivan Pavlukhin 写道:

Hi,

There are the following functions. I haven't found the related 
documents. Please confirm again?
Thank you for checking this thoroughly! I looked into SQL and JDBC 
items.



1.SQL:Added KILL QUERY command

Here it is https://apacheignite-sql.readme.io/docs/kill-query but it
seems no link from a parent page [1]


4.JDBC:Added cache expiry policies

Sounds strange because I an not sure that this feature was implemented.

All other pointed SQL and JDBS items seems to be missing =(

Best regards,
Ivan Pavlukhin

чт, 12 мар. 2020 г. в 15:04, 18624049226 <18624049...@163.com>:

Hi igniters,

There are the following functions. I haven't found the related
documents. Please confirm again?

1.SQL:Added KILL QUERY command

2.SQL:Added ability to specify query parallelism in CREATE TABLE's WITH
"" clause

3.SQL:Added default query timeout

4.JDBC:Added cache expiry policies

5.JDBC:Added support JDBC thin driver: connection timeout

6.JDBC:Added support query cancel

7.JDBC:Added support query timeout

8.REST:Added "caches" param for "top" command

9.REST:Added baseline topology commands to REST API

10.REST:Added memory policy metrics via REST

These are great improvements, and without documentation, developers may
not know how to use them.


在 2020/3/12 上午1:40, Artem Budnikov 写道:

Denis,

I made version 2.8 the main version on readme.io. Everybody can see 
it now.


-Artem

On Wed, Mar 11, 2020 at 7:35 PM Denis Magda  wrote:


Artem,

Understood, let's see what Alexey says. As of now, I would suggest we
publishing the existing ML pages and improve the content with no 
rush.
Could you also make a 2.8 version the default one? 2.7.6 is still 
selected

by default when I navigate to the documentation website.


-
Denis


On Wed, Mar 11, 2020 at 9:33 AM Artem Budnikov <
a.budnikov.ign...@gmail.com>
wrote:


Denis,

I'm waiting for answers from Alexey. I can't really tell how lont 
it will

take. Of couse, we can publish everything right now and improve some

pages

later.

-Artem

On Wed, Mar 11, 2020 at 7:13 PM Denis Magda  
wrote:


Artem, thanks! How much time should it take to roll out the ML 
pages?

Can
we release what's available right now and continue improving the 
pages

in

parallel?

Maxim, please let me publish the blog post [1] on the apache 
website

before
sending you'll send an announcement email. The article will 
refer to

many

documentation pages including ML. You'll include a reference to the

blog

post in the email.

[1]


http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-2-8-announcement-plan-td46238.html 


-
Denis


On Wed, Mar 11, 2020 at 8:43 AM Maxim Muzafarov 

wrote:

Artem, Folks


Thank you all.
I'll do announce the release tomorrow in the middle of the day

(~16.00

MSK

TZ).

On Wed, 11 Mar 2020 at 16:06, Artem Budnikov
 wrote:

I created the Apache Ignite Documentation 2.8 with all the new

pages
except for ML, which I and Alexey are still working on. The 
docs are

not

published yet, but you can see them under version 2.8.0 if you log

into
readme.io. The ML pages could take a while, but other than that 
the
initial plan on creating the docs is accomplished, so it's no 
longer

an

obstacle to announcing the release.

-Artem

On Wed, Mar 11, 2020 at 11:50 AM Artem Budnikov <

a.budnikov.ign...@gmail.com> wrote:

OK, I'm going to create the 2.8 version on readme.io for all
documentation pages. If anyone is still working on the docs 
version

2.7.6,
please let me know. I'll post an update in this thread when I 
finish.

Further changes should be made in version 2.8.

-Artem

On Wed, Mar 11, 2020 at 10:16 AM Anton Vinogradov 


wrote:

Artem,
I've updated the Read Repair page

On Thu, Mar 5, 2020 at 3:51 PM Artem Budnikov <

a.budnikov.ign...@gmail.com>

wrote:


Anton,

Could you please review the page about Read Rapair?

https://apacheignite.readme.io/docs/read-repair

-Artem

On 05.03.2020 12:20, Artem Budnikov wrote:

OK, I'll recreate it.

Nikolay, please let me know when you are finished with the

Metrics

and

system views documentation. I'm done with the list of docs we
identified in this thread and want to publish v. 2.8.

-Artem

On 05.03.2020 11:55, Maxim Muzafarov wrote:

Artem,

I've created that. It is not public and can be safely

removed

since

it's a full copy of 2.7.6 (at that moment)

On Thu, 5 Mar 2020 at 11:53, Artem Budnikov
 wrote:

Guys,

I see that there is already version 2.8 for Ignite do

Re: Ignite 2.8 documentation

[Artem Budnikov]

Denis,

I made version 2.8 the main version on readme.io. Everybody can see it now.

-Artem

On Wed, Mar 11, 2020 at 7:35 PM Denis Magda  wrote:

> Artem,
>
> Understood, let's see what Alexey says. As of now, I would suggest we
> publishing the existing ML pages and improve the content with no rush.
> Could you also make a 2.8 version the default one? 2.7.6 is still selected
> by default when I navigate to the documentation website.
>
>
> -
> Denis
>
>
> On Wed, Mar 11, 2020 at 9:33 AM Artem Budnikov <
> a.budnikov.ign...@gmail.com>
> wrote:
>
> > Denis,
> >
> > I'm waiting for answers from Alexey. I can't really tell how lont it will
> > take. Of couse, we can publish everything right now and improve some
> pages
> > later.
> >
> > -Artem
> >
> > On Wed, Mar 11, 2020 at 7:13 PM Denis Magda  wrote:
> >
> > > Artem, thanks! How much time should it take to roll out the ML pages?
> Can
> > > we release what's available right now and continue improving the pages
> in
> > > parallel?
> > >
> > > Maxim, please let me publish the blog post [1] on the apache website
> > before
> > > sending you'll send an announcement email. The article will refer to
> many
> > > documentation pages including ML. You'll include a reference to the
> blog
> > > post in the email.
> > >
> > > [1]
> > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-2-8-announcement-plan-td46238.html
> > >
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Wed, Mar 11, 2020 at 8:43 AM Maxim Muzafarov 
> > wrote:
> > >
> > > > Artem, Folks
> > > >
> > > >
> > > > Thank you all.
> > > > I'll do announce the release tomorrow in the middle of the day
> (~16.00
> > > MSK
> > > > TZ).
> > > >
> > > > On Wed, 11 Mar 2020 at 16:06, Artem Budnikov
> > > >  wrote:
> > > > >
> > > > > I created the Apache Ignite Documentation 2.8 with all the new
> pages
> > > > except for ML, which I and Alexey are still working on. The docs are
> > not
> > > > published yet, but you can see them under version 2.8.0 if you log
> into
> > > > readme.io. The ML pages could take a while, but other than that the
> > > > initial plan on creating the docs is accomplished, so it's no longer
> an
> > > > obstacle to announcing the release.
> > > > >
> > > > > -Artem
> > > > >
> > > > > On Wed, Mar 11, 2020 at 11:50 AM Artem Budnikov <
> > > > a.budnikov.ign...@gmail.com> wrote:
> > > > >>
> > > > >> OK, I'm going to create the 2.8 version on readme.io for all
> > > > documentation pages. If anyone is still working on the docs version
> > > 2.7.6,
> > > > please let me know. I'll post an update in this thread when I finish.
> > > > Further changes should be made in version 2.8.
> > > > >>
> > > > >> -Artem
> > > > >>
> > > > >> On Wed, Mar 11, 2020 at 10:16 AM Anton Vinogradov 
> > > > wrote:
> > > > >>>
> > > > >>> Artem,
> > > > >>> I've updated the Read Repair page
> > > > >>>
> > > > >>> On Thu, Mar 5, 2020 at 3:51 PM Artem Budnikov <
> > > > a.budnikov.ign...@gmail.com>
> > > > >>> wrote:
> > > > >>>
> > > > >>> > Anton,
> > > > >>> >
> > > > >>> > Could you please review the page about Read Rapair?
> > > > >>> >
> > > > >>> > https://apacheignite.readme.io/docs/read-repair
> > > > >>> >
> > > > >>> > -Artem
> > > > >>> >
> > > > >>> > On 05.03.2020 12:20, Artem Budnikov wrote:
> > > > >>> > > OK, I'll recreate it.
> > > > >>> > >
> > > > >>> > > Nikolay, please let me know when you are finished with the
> > > Metrics
> > > > and
> > > > >>> > > system views documentation. I'm done with the list of docs we
> > > > >>> > > identified in this thread and want to publish v. 2.8.
&

Re: Ignite 2.8 documentation

[Artem Budnikov]

Denis,

I'm waiting for answers from Alexey. I can't really tell how lont it will
take. Of couse, we can publish everything right now and improve some pages
later.

-Artem

On Wed, Mar 11, 2020 at 7:13 PM Denis Magda  wrote:

> Artem, thanks! How much time should it take to roll out the ML pages? Can
> we release what's available right now and continue improving the pages in
> parallel?
>
> Maxim, please let me publish the blog post [1] on the apache website before
> sending you'll send an announcement email. The article will refer to many
> documentation pages including ML. You'll include a reference to the blog
> post in the email.
>
> [1]
>
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-2-8-announcement-plan-td46238.html
>
>
> -
> Denis
>
>
> On Wed, Mar 11, 2020 at 8:43 AM Maxim Muzafarov  wrote:
>
> > Artem, Folks
> >
> >
> > Thank you all.
> > I'll do announce the release tomorrow in the middle of the day (~16.00
> MSK
> > TZ).
> >
> > On Wed, 11 Mar 2020 at 16:06, Artem Budnikov
> >  wrote:
> > >
> > > I created the Apache Ignite Documentation 2.8 with all the new pages
> > except for ML, which I and Alexey are still working on. The docs are not
> > published yet, but you can see them under version 2.8.0 if you log into
> > readme.io. The ML pages could take a while, but other than that the
> > initial plan on creating the docs is accomplished, so it's no longer an
> > obstacle to announcing the release.
> > >
> > > -Artem
> > >
> > > On Wed, Mar 11, 2020 at 11:50 AM Artem Budnikov <
> > a.budnikov.ign...@gmail.com> wrote:
> > >>
> > >> OK, I'm going to create the 2.8 version on readme.io for all
> > documentation pages. If anyone is still working on the docs version
> 2.7.6,
> > please let me know. I'll post an update in this thread when I finish.
> > Further changes should be made in version 2.8.
> > >>
> > >> -Artem
> > >>
> > >> On Wed, Mar 11, 2020 at 10:16 AM Anton Vinogradov 
> > wrote:
> > >>>
> > >>> Artem,
> > >>> I've updated the Read Repair page
> > >>>
> > >>> On Thu, Mar 5, 2020 at 3:51 PM Artem Budnikov <
> > a.budnikov.ign...@gmail.com>
> > >>> wrote:
> > >>>
> > >>> > Anton,
> > >>> >
> > >>> > Could you please review the page about Read Rapair?
> > >>> >
> > >>> > https://apacheignite.readme.io/docs/read-repair
> > >>> >
> > >>> > -Artem
> > >>> >
> > >>> > On 05.03.2020 12:20, Artem Budnikov wrote:
> > >>> > > OK, I'll recreate it.
> > >>> > >
> > >>> > > Nikolay, please let me know when you are finished with the
> Metrics
> > and
> > >>> > > system views documentation. I'm done with the list of docs we
> > >>> > > identified in this thread and want to publish v. 2.8.
> > >>> > >
> > >>> > > -Artem
> > >>> > >
> > >>> > > On 05.03.2020 11:55, Maxim Muzafarov wrote:
> > >>> > >> Artem,
> > >>> > >>
> > >>> > >> I've created that. It is not public and can be safely removed
> > since
> > >>> > >> it's a full copy of 2.7.6 (at that moment)
> > >>> > >>
> > >>> > >> On Thu, 5 Mar 2020 at 11:53, Artem Budnikov
> > >>> > >>  wrote:
> > >>> > >>> Guys,
> > >>> > >>>
> > >>> > >>> I see that there is already version 2.8 for Ignite docs on
> > readme.io.
> > >>> > >>> Who created it and when? I've changed some pages under 2.7.6
> > version
> > >>> > >>> without knowing that there is a newer version.
> > >>> > >>>
> > >>> > >>> -Artem
> > >>> > >>>
> > >>> > >>> On 05.03.2020 11:45, Artem Budnikov wrote:
> > >>> > >>>> I'm confused. Igor, could you please double check?
> > >>> > >>>>
> > >>> > >>>> -Artem
> > >>> > >>>>
> > >>> > >>>

Re: Ignite 2.8 documentation

[Artem Budnikov]

I created the Apache Ignite Documentation 2.8 with all the new pages except
for ML, which I and Alexey are still working on. The docs are not published
yet, but you can see them under version 2.8.0 if you log into readme.io.
The ML pages could take a while, but other than that the initial plan on
creating the docs is accomplished, so it's no longer an obstacle to
announcing the release.

-Artem

On Wed, Mar 11, 2020 at 11:50 AM Artem Budnikov 
wrote:

> OK, I'm going to create the 2.8 version on readme.io for all
> documentation pages. If anyone is still working on the docs version 2.7.6,
> please let me know. I'll post an update in this thread when I finish.
> Further changes should be made in version 2.8.
>
> -Artem
>
> On Wed, Mar 11, 2020 at 10:16 AM Anton Vinogradov  wrote:
>
>> Artem,
>> I've updated the Read Repair page
>>
>> On Thu, Mar 5, 2020 at 3:51 PM Artem Budnikov <
>> a.budnikov.ign...@gmail.com>
>> wrote:
>>
>> > Anton,
>> >
>> > Could you please review the page about Read Rapair?
>> >
>> > https://apacheignite.readme.io/docs/read-repair
>> >
>> > -Artem
>> >
>> > On 05.03.2020 12:20, Artem Budnikov wrote:
>> > > OK, I'll recreate it.
>> > >
>> > > Nikolay, please let me know when you are finished with the Metrics and
>> > > system views documentation. I'm done with the list of docs we
>> > > identified in this thread and want to publish v. 2.8.
>> > >
>> > > -Artem
>> > >
>> > > On 05.03.2020 11:55, Maxim Muzafarov wrote:
>> > >> Artem,
>> > >>
>> > >> I've created that. It is not public and can be safely removed since
>> > >> it's a full copy of 2.7.6 (at that moment)
>> > >>
>> > >> On Thu, 5 Mar 2020 at 11:53, Artem Budnikov
>> > >>  wrote:
>> > >>> Guys,
>> > >>>
>> > >>> I see that there is already version 2.8 for Ignite docs on
>> readme.io.
>> > >>> Who created it and when? I've changed some pages under 2.7.6 version
>> > >>> without knowing that there is a newer version.
>> > >>>
>> > >>> -Artem
>> > >>>
>> > >>> On 05.03.2020 11:45, Artem Budnikov wrote:
>> > >>>> I'm confused. Igor, could you please double check?
>> > >>>>
>> > >>>> -Artem
>> > >>>>
>> > >>>> On 05.03.2020 04:15, Ivan Pavlukhin wrote:
>> > >>>>>> That's right, only C++ and .NET clients have partition awareness
>> > >>>>> Are your sure? Was not the feature implemented for java thin
>> client
>> > >>>>> in [1]?
>> > >>>>>
>> > >>>>> [1] https://issues.apache.org/jira/browse/IGNITE-11898
>> > >>>>>
>> > >>>>> Best regards,
>> > >>>>> Ivan Pavlukhin
>> > >>>>>
>> > >>>>> ср, 4 мар. 2020 г. в 18:18, Denis Magda :
>> > >>>>>> Maxim,
>> > >>>>>>
>> > >>>>>> Yes, it's preferable to have metrics pages fully completed even
>> > >>>>>> though the
>> > >>>>>> feature is an experimental state. We want to encourage to try it
>> out
>> > >>>>>> and
>> > >>>>>> switch to the new APIs eventually. Without technical instructions
>> > >>>>>> available
>> > >>>>>> our users will have a hard time checking the new capabilities.
>> > >>>>>>
>> > >>>>>> Nikolay, thanks a lot!
>> > >>>>>>
>> > >>>>>> -
>> > >>>>>> Denis
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> On Wed, Mar 4, 2020 at 8:52 AM Nikolay Izhikov <
>> nizhi...@apache.org
>> > >
>> > >>>>>> wrote:
>> > >>>>>>
>> > >>>>>>> I think yes.
>> > >>>>>>>
>> > >>>>>>> I will prepare documentation shortly.
>> > >>>>>>>
>> > >>>>>>>> 4 марта 2020 г., в 17:50, Maxim Muzafarov 
&

Re: Ignite 2.8 documentation

[Artem Budnikov]

OK, I'm going to create the 2.8 version on readme.io for all documentation
pages. If anyone is still working on the docs version 2.7.6, please let me
know. I'll post an update in this thread when I finish. Further changes
should be made in version 2.8.

-Artem

On Wed, Mar 11, 2020 at 10:16 AM Anton Vinogradov  wrote:

> Artem,
> I've updated the Read Repair page
>
> On Thu, Mar 5, 2020 at 3:51 PM Artem Budnikov  >
> wrote:
>
> > Anton,
> >
> > Could you please review the page about Read Rapair?
> >
> > https://apacheignite.readme.io/docs/read-repair
> >
> > -Artem
> >
> > On 05.03.2020 12:20, Artem Budnikov wrote:
> > > OK, I'll recreate it.
> > >
> > > Nikolay, please let me know when you are finished with the Metrics and
> > > system views documentation. I'm done with the list of docs we
> > > identified in this thread and want to publish v. 2.8.
> > >
> > > -Artem
> > >
> > > On 05.03.2020 11:55, Maxim Muzafarov wrote:
> > >> Artem,
> > >>
> > >> I've created that. It is not public and can be safely removed since
> > >> it's a full copy of 2.7.6 (at that moment)
> > >>
> > >> On Thu, 5 Mar 2020 at 11:53, Artem Budnikov
> > >>  wrote:
> > >>> Guys,
> > >>>
> > >>> I see that there is already version 2.8 for Ignite docs on readme.io
> .
> > >>> Who created it and when? I've changed some pages under 2.7.6 version
> > >>> without knowing that there is a newer version.
> > >>>
> > >>> -Artem
> > >>>
> > >>> On 05.03.2020 11:45, Artem Budnikov wrote:
> > >>>> I'm confused. Igor, could you please double check?
> > >>>>
> > >>>> -Artem
> > >>>>
> > >>>> On 05.03.2020 04:15, Ivan Pavlukhin wrote:
> > >>>>>> That's right, only C++ and .NET clients have partition awareness
> > >>>>> Are your sure? Was not the feature implemented for java thin client
> > >>>>> in [1]?
> > >>>>>
> > >>>>> [1] https://issues.apache.org/jira/browse/IGNITE-11898
> > >>>>>
> > >>>>> Best regards,
> > >>>>> Ivan Pavlukhin
> > >>>>>
> > >>>>> ср, 4 мар. 2020 г. в 18:18, Denis Magda :
> > >>>>>> Maxim,
> > >>>>>>
> > >>>>>> Yes, it's preferable to have metrics pages fully completed even
> > >>>>>> though the
> > >>>>>> feature is an experimental state. We want to encourage to try it
> out
> > >>>>>> and
> > >>>>>> switch to the new APIs eventually. Without technical instructions
> > >>>>>> available
> > >>>>>> our users will have a hard time checking the new capabilities.
> > >>>>>>
> > >>>>>> Nikolay, thanks a lot!
> > >>>>>>
> > >>>>>> -
> > >>>>>> Denis
> > >>>>>>
> > >>>>>>
> > >>>>>> On Wed, Mar 4, 2020 at 8:52 AM Nikolay Izhikov <
> nizhi...@apache.org
> > >
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> I think yes.
> > >>>>>>>
> > >>>>>>> I will prepare documentation shortly.
> > >>>>>>>
> > >>>>>>>> 4 марта 2020 г., в 17:50, Maxim Muzafarov 
> > >>>>>>> написал(а):
> > >>>>>>>> Folks,
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> Do we need a fully complete public documentation for metrics
> > >>>>>>>> marked
> > >>>>>>>> with @ExperimentalFeature? The API can significantly be changed.
> > >>>>>>>>
> > >>>>>>>> On Wed, 4 Mar 2020 at 17:10, Artem Budnikov
> > >>>>>>>> 
> > >>>>>>> wrote:
> > >>>>>>>>> The only feature that is left is "WAL page compression"
> > >>>>>>>>>
> > >>>>>>>>&g

Re: Ignite 2.8 documentation

[Artem Budnikov]

Hi Nikolay,

I looked through the metrics pages and found a couple of minor issues:

 * Looks like this sentence should contain a link to somewhere:
   "Please, see XXX as an example and OpenCensus documentation for
   additional information."
 * Please mention that for the OpenCensus exporter to work, the module
   should be enabled.
 * Also, there is no information on how to specify a filter via
   configuration.

-Artem

On 10.03.2020 12:50, Maxim Muzafarov wrote:

Folks,

It seems everything is ready to go and only minor issues left with
documentation.
Are we ready to announce 2.8 release widely?


On Tue, 10 Mar 2020 at 12:10, Nikolay Izhikov  wrote:

Hello, Igniters.

I rewrote pages about new metrics and system views.
Please, take a look.

https://apacheignite.readme.io/docs/new-metrics
https://apacheignite.readme.io/docs/system-views

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



6 марта 2020 г., в 16:40, Artem Budnikov  
написал(а):

Anton,

Thanks for the feedback. I updated the page.

-Artem

On 05.03.2020 16:32, Anton Vinogradov wrote:

Artem, great!

Some minors:


read operations become more costly for caches with backup copies.

Since it makes sense only for cache with backups, can we say something like
"read operations become at least 2 times costly since backups checked as
well"


for atomic caches, a consistency violation exception is thrown.

... after N checks, where N is 3 by default and can be set by
"IGNITE_NEAR_GET_MAX_REMAPS" system property.

Also, need to mention that each found violation triggers event with type ==
org.apache.ignite.events.EventType#EVT_CONSISTENCY_VIOLATION includes
org.apache.ignite.events.CacheConsistencyViolationEvent which should be
used for rechecking of repait results.

On Thu, Mar 5, 2020 at 3:51 PM Artem Budnikov
wrote:


Anton,

Could you please review the page about Read Rapair?

https://apacheignite.readme.io/docs/read-repair

-Artem

On 05.03.2020 12:20, Artem Budnikov wrote:

OK, I'll recreate it.

Nikolay, please let me know when you are finished with the Metrics and
system views documentation. I'm done with the list of docs we
identified in this thread and want to publish v. 2.8.

-Artem

On 05.03.2020 11:55, Maxim Muzafarov wrote:

Artem,

I've created that. It is not public and can be safely removed since
it's a full copy of 2.7.6 (at that moment)

On Thu, 5 Mar 2020 at 11:53, Artem Budnikov
  wrote:

Guys,

I see that there is already version 2.8 for Ignite docs on readme.io.
Who created it and when? I've changed some pages under 2.7.6 version
without knowing that there is a newer version.

-Artem

On 05.03.2020 11:45, Artem Budnikov wrote:

I'm confused. Igor, could you please double check?

-Artem

On 05.03.2020 04:15, Ivan Pavlukhin wrote:

That's right, only C++ and .NET clients have partition awareness

Are your sure? Was not the feature implemented for java thin client
in [1]?

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

Best regards,
Ivan Pavlukhin

ср, 4 мар. 2020 г. в 18:18, Denis Magda:

Maxim,

Yes, it's preferable to have metrics pages fully completed even
though the
feature is an experimental state. We want to encourage to try it out
and
switch to the new APIs eventually. Without technical instructions
available
our users will have a hard time checking the new capabilities.

Nikolay, thanks a lot!

-
Denis


On Wed, Mar 4, 2020 at 8:52 AM Nikolay Izhikov 
I think yes.

I will prepare documentation shortly.


4 марта 2020 г., в 17:50, Maxim Muzafarov

написал(а):

Folks,


Do we need a fully complete public documentation for metrics
marked
with @ExperimentalFeature? The API can significantly be changed.

On Wed, 4 Mar 2020 at 17:10, Artem Budnikov


wrote:

The only feature that is left is "WAL page compression"

The three other features are  limitations that were present in
Ignite
2.7 and now they are removed. Since they were never mentioned
in the
docs, there is nothing to do.

-Artem

On 04.03.2020 17:02, Denis Magda wrote:

I'll work on the following items today and tomorrow:

  - JDBC: Support for query cancellation


  - JDBC: Support for query timeout


  - suspend/resume for pessimistic transactions


  - WAL page compression



Artem, are these the only tickets left apart from the metrics &
monitoring? @Nikolay
Izhikov  how soon will you be able to
finish the
metrics documentation pages?

-
Denis


On Wed, Mar 4, 2020 at 2:55 AM Artem Budnikov

wrote:


Hi everyone,

I have created the docs for the following items so far:

  -Default Ignite work dir location



https://apacheignite.readme.io/docs/getting-started-28#section-setting-up-work-directory

  - Baseline auto-adjust feature



https://apacheignite.readme.io/docs/baseline-topology-28#section-baseline-topology-autoadjustment

  - Cluster (de)activation events documentation



https://apach

Re: Ignite 2.8 documentation

[Artem Budnikov]

Anton,

Thanks for the feedback. I updated the page.

-Artem

On 05.03.2020 16:32, Anton Vinogradov wrote:

Artem, great!

Some minors:


read operations become more costly for caches with backup copies.

Since it makes sense only for cache with backups, can we say something like
"read operations become at least 2 times costly since backups checked as
well"


for atomic caches, a consistency violation exception is thrown.

... after N checks, where N is 3 by default and can be set by
"IGNITE_NEAR_GET_MAX_REMAPS" system property.

Also, need to mention that each found violation triggers event with type ==
org.apache.ignite.events.EventType#EVT_CONSISTENCY_VIOLATION includes
org.apache.ignite.events.CacheConsistencyViolationEvent which should be
used for rechecking of repait results.

On Thu, Mar 5, 2020 at 3:51 PM Artem Budnikov 
wrote:


Anton,

Could you please review the page about Read Rapair?

https://apacheignite.readme.io/docs/read-repair

-Artem

On 05.03.2020 12:20, Artem Budnikov wrote:

OK, I'll recreate it.

Nikolay, please let me know when you are finished with the Metrics and
system views documentation. I'm done with the list of docs we
identified in this thread and want to publish v. 2.8.

-Artem

On 05.03.2020 11:55, Maxim Muzafarov wrote:

Artem,

I've created that. It is not public and can be safely removed since
it's a full copy of 2.7.6 (at that moment)

On Thu, 5 Mar 2020 at 11:53, Artem Budnikov
 wrote:

Guys,

I see that there is already version 2.8 for Ignite docs on readme.io.
Who created it and when? I've changed some pages under 2.7.6 version
without knowing that there is a newer version.

-Artem

On 05.03.2020 11:45, Artem Budnikov wrote:

I'm confused. Igor, could you please double check?

-Artem

On 05.03.2020 04:15, Ivan Pavlukhin wrote:

That's right, only C++ and .NET clients have partition awareness

Are your sure? Was not the feature implemented for java thin client
in [1]?

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

Best regards,
Ivan Pavlukhin

ср, 4 мар. 2020 г. в 18:18, Denis Magda :

Maxim,

Yes, it's preferable to have metrics pages fully completed even
though the
feature is an experimental state. We want to encourage to try it out
and
switch to the new APIs eventually. Without technical instructions
available
our users will have a hard time checking the new capabilities.

Nikolay, thanks a lot!

-
Denis


On Wed, Mar 4, 2020 at 8:52 AM Nikolay Izhikov 
I think yes.

I will prepare documentation shortly.


4 марта 2020 г., в 17:50, Maxim Muzafarov 

написал(а):

Folks,


Do we need a fully complete public documentation for metrics
marked
with @ExperimentalFeature? The API can significantly be changed.

On Wed, 4 Mar 2020 at 17:10, Artem Budnikov


wrote:

The only feature that is left is "WAL page compression"

The three other features are  limitations that were present in
Ignite
2.7 and now they are removed. Since they were never mentioned
in the
docs, there is nothing to do.

-Artem

On 04.03.2020 17:02, Denis Magda wrote:

I'll work on the following items today and tomorrow:

  - JDBC: Support for query cancellation


  - JDBC: Support for query timeout


  - suspend/resume for pessimistic transactions


  - WAL page compression



Artem, are these the only tickets left apart from the metrics &
monitoring? @Nikolay
Izhikov  how soon will you be able to
finish the
metrics documentation pages?

-
Denis


On Wed, Mar 4, 2020 at 2:55 AM Artem Budnikov

wrote:


Hi everyone,

I have created the docs for the following items so far:

  -Default Ignite work dir location



https://apacheignite.readme.io/docs/getting-started-28#section-setting-up-work-directory



  - Baseline auto-adjust feature



https://apacheignite.readme.io/docs/baseline-topology-28#section-baseline-topology-autoadjustment



  - Cluster (de)activation events documentation



https://apacheignite.readme.io/docs/baseline-topology-28#section-cluster-activationdeactivation-events



  - Remove SqlQuery documentation
  done

  - Partition awareness for thin clients



https://apacheignite-net.readme.io/docs/thin-client-28#section-partition-awareness




https://apacheignite-cpp.readme.io/docs/thin-client-28#section-partition-awareness



  - Transactions support in java thin client



https://apacheignite.readme.io/docs/key-value-28#section-client-transactions



  - KILL QUERY command



https://dash.readme.io/project/apacheignite-sql/v2.7.6/docs/kill-query

  - Move rebalance configuration properties to the
  IgniteConfiguration level



https://apacheignite.readme.io/docs/data-rebalancing-28#section-configuration



  - Renamed IGNITE schema to SYS
  done

I'll work on the following items today and tomorrow:

  - JDBC: Support for query cancellation
  - JDB

Re: Ignite 2.8 documentation

[Artem Budnikov]

Anton,

Could you please review the page about Read Rapair?

https://apacheignite.readme.io/docs/read-repair

-Artem

On 05.03.2020 12:20, Artem Budnikov wrote:

OK, I'll recreate it.

Nikolay, please let me know when you are finished with the Metrics and 
system views documentation. I'm done with the list of docs we 
identified in this thread and want to publish v. 2.8.


-Artem

On 05.03.2020 11:55, Maxim Muzafarov wrote:

Artem,

I've created that. It is not public and can be safely removed since
it's a full copy of 2.7.6 (at that moment)

On Thu, 5 Mar 2020 at 11:53, Artem Budnikov 
 wrote:

Guys,

I see that there is already version 2.8 for Ignite docs on readme.io.
Who created it and when? I've changed some pages under 2.7.6 version
without knowing that there is a newer version.

-Artem

On 05.03.2020 11:45, Artem Budnikov wrote:

I'm confused. Igor, could you please double check?

-Artem

On 05.03.2020 04:15, Ivan Pavlukhin wrote:

That's right, only C++ and .NET clients have partition awareness

Are your sure? Was not the feature implemented for java thin client
in [1]?

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

Best regards,
Ivan Pavlukhin

ср, 4 мар. 2020 г. в 18:18, Denis Magda :

Maxim,

Yes, it's preferable to have metrics pages fully completed even
though the
feature is an experimental state. We want to encourage to try it out
and
switch to the new APIs eventually. Without technical instructions
available
our users will have a hard time checking the new capabilities.

Nikolay, thanks a lot!

-
Denis


On Wed, Mar 4, 2020 at 8:52 AM Nikolay Izhikov 
wrote:


I think yes.

I will prepare documentation shortly.


4 марта 2020 г., в 17:50, Maxim Muzafarov 

написал(а):

Folks,


Do we need a fully complete public documentation for metrics 
marked

with @ExperimentalFeature? The API can significantly be changed.

On Wed, 4 Mar 2020 at 17:10, Artem Budnikov


wrote:

The only feature that is left is "WAL page compression"

The three other features are  limitations that were present in
Ignite
2.7 and now they are removed. Since they were never mentioned 
in the

docs, there is nothing to do.

-Artem

On 04.03.2020 17:02, Denis Magda wrote:

I'll work on the following items today and tomorrow:

 - JDBC: Support for query cancellation


 - JDBC: Support for query timeout


 - suspend/resume for pessimistic transactions


 - WAL page compression



Artem, are these the only tickets left apart from the metrics &
monitoring? @Nikolay
Izhikov  how soon will you be able to
finish the
metrics documentation pages?

-
Denis


On Wed, Mar 4, 2020 at 2:55 AM Artem Budnikov

wrote:


Hi everyone,

I have created the docs for the following items so far:

 -    Default Ignite work dir location


https://apacheignite.readme.io/docs/getting-started-28#section-setting-up-work-directory 




 - Baseline auto-adjust feature


https://apacheignite.readme.io/docs/baseline-topology-28#section-baseline-topology-autoadjustment 




 - Cluster (de)activation events documentation


https://apacheignite.readme.io/docs/baseline-topology-28#section-cluster-activationdeactivation-events 




 - Remove SqlQuery documentation
 done

 - Partition awareness for thin clients


https://apacheignite-net.readme.io/docs/thin-client-28#section-partition-awareness 



https://apacheignite-cpp.readme.io/docs/thin-client-28#section-partition-awareness 




 - Transactions support in java thin client


https://apacheignite.readme.io/docs/key-value-28#section-client-transactions 




 - KILL QUERY command


https://dash.readme.io/project/apacheignite-sql/v2.7.6/docs/kill-query 


 - Move rebalance configuration properties to the
 IgniteConfiguration level


https://apacheignite.readme.io/docs/data-rebalancing-28#section-configuration 




 - Renamed IGNITE schema to SYS
 done

I'll work on the following items today and tomorrow:

 - JDBC: Support for query cancellation
 - JDBC: Support for query timeout
 - suspend/resume for pessimistic transactions
 - WAL page compression


Nikolay,

How is your progress with the Metrics and System Views
documentation?


Artem Budnikov
Technical Writergridgain.com

On 03.03.2020 19:06, Maxim Muzafarov wrote:

Folks,

This is in the `Ignite Core` section, so I think mostly 
related to

java functionality and thin client protocol extension [1].
Sorry for
not being too accurate with this statement
.
The same change is mentioned for C++ and .NET sections of the
release
notes (but not for other thin clients).


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

On Tue, 3 Mar 2020 at 17:33, Igor Sapego  <

isap...@apache.org> wrote:
That's right, only C++ and .NET clients have partition 
awareness


Best Regards,
Igor


On Tue, Mar 3, 2020 at 5:02 PM Artem Budnikov

Re: Ignite 2.8 documentation

[Artem Budnikov]

OK, I'll recreate it.

Nikolay, please let me know when you are finished with the Metrics and 
system views documentation. I'm done with the list of docs we identified 
in this thread and want to publish v. 2.8.


-Artem

On 05.03.2020 11:55, Maxim Muzafarov wrote:

Artem,

I've created that. It is not public and can be safely removed since
it's a full copy of 2.7.6 (at that moment)

On Thu, 5 Mar 2020 at 11:53, Artem Budnikov  wrote:

Guys,

I see that there is already version 2.8 for Ignite docs on readme.io.
Who created it and when? I've changed some pages under 2.7.6 version
without knowing that there is a newer version.

-Artem

On 05.03.2020 11:45, Artem Budnikov wrote:

I'm confused. Igor, could you please double check?

-Artem

On 05.03.2020 04:15, Ivan Pavlukhin wrote:

That's right, only C++ and .NET clients have partition awareness

Are your sure? Was not the feature implemented for java thin client
in [1]?

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

Best regards,
Ivan Pavlukhin

ср, 4 мар. 2020 г. в 18:18, Denis Magda :

Maxim,

Yes, it's preferable to have metrics pages fully completed even
though the
feature is an experimental state. We want to encourage to try it out
and
switch to the new APIs eventually. Without technical instructions
available
our users will have a hard time checking the new capabilities.

Nikolay, thanks a lot!

-
Denis


On Wed, Mar 4, 2020 at 8:52 AM Nikolay Izhikov 
wrote:


I think yes.

I will prepare documentation shortly.


4 марта 2020 г., в 17:50, Maxim Muzafarov 

написал(а):

Folks,


Do we need a fully complete public documentation for metrics marked
with @ExperimentalFeature? The API can significantly be changed.

On Wed, 4 Mar 2020 at 17:10, Artem Budnikov


wrote:

The only feature that is left is "WAL page compression"

The three other features are  limitations that were present in
Ignite
2.7 and now they are removed. Since they were never mentioned in the
docs, there is nothing to do.

-Artem

On 04.03.2020 17:02, Denis Magda wrote:

I'll work on the following items today and tomorrow:

 - JDBC: Support for query cancellation


 - JDBC: Support for query timeout


 - suspend/resume for pessimistic transactions


 - WAL page compression



Artem, are these the only tickets left apart from the metrics &
monitoring? @Nikolay
Izhikov  how soon will you be able to
finish the
metrics documentation pages?

-
Denis


On Wed, Mar 4, 2020 at 2:55 AM Artem Budnikov

wrote:


Hi everyone,

I have created the docs for the following items so far:

 -Default Ignite work dir location



https://apacheignite.readme.io/docs/getting-started-28#section-setting-up-work-directory


 - Baseline auto-adjust feature



https://apacheignite.readme.io/docs/baseline-topology-28#section-baseline-topology-autoadjustment


 - Cluster (de)activation events documentation



https://apacheignite.readme.io/docs/baseline-topology-28#section-cluster-activationdeactivation-events


 - Remove SqlQuery documentation
 done

 - Partition awareness for thin clients



https://apacheignite-net.readme.io/docs/thin-client-28#section-partition-awareness

https://apacheignite-cpp.readme.io/docs/thin-client-28#section-partition-awareness


 - Transactions support in java thin client



https://apacheignite.readme.io/docs/key-value-28#section-client-transactions


 - KILL QUERY command



https://dash.readme.io/project/apacheignite-sql/v2.7.6/docs/kill-query

 - Move rebalance configuration properties to the
 IgniteConfiguration level



https://apacheignite.readme.io/docs/data-rebalancing-28#section-configuration


 - Renamed IGNITE schema to SYS
 done

I'll work on the following items today and tomorrow:

 - JDBC: Support for query cancellation
 - JDBC: Support for query timeout
 - suspend/resume for pessimistic transactions
 - WAL page compression


Nikolay,

How is your progress with the Metrics and System Views
documentation?


Artem Budnikov
Technical Writergridgain.com

On 03.03.2020 19:06, Maxim Muzafarov wrote:

Folks,

This is in the `Ignite Core` section, so I think mostly related to
java functionality and thin client protocol extension [1].
Sorry for
not being too accurate with this statement
.
The same change is mentioned for C++ and .NET sections of the
release
notes (but not for other thin clients).


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

On Tue, 3 Mar 2020 at 17:33, Igor Sapego  <

isap...@apache.org> wrote:

That's right, only C++ and .NET clients have partition awareness

Best Regards,
Igor


On Tue, Mar 3, 2020 at 5:02 PM Artem Budnikov




wrote:


Hi everyone,

Looks like the following line from the Ignite 2.8 release notes
is a

bit

of an overstatement and should be removed:


Added support best effort affinity for thin 

Re: Ignite 2.8 documentation

[Artem Budnikov]

Guys,

I see that there is already version 2.8 for Ignite docs on readme.io. 
Who created it and when? I've changed some pages under 2.7.6 version 
without knowing that there is a newer version.


-Artem

On 05.03.2020 11:45, Artem Budnikov wrote:

I'm confused. Igor, could you please double check?

-Artem

On 05.03.2020 04:15, Ivan Pavlukhin wrote:

That's right, only C++ and .NET clients have partition awareness
Are your sure? Was not the feature implemented for java thin client 
in [1]?


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

Best regards,
Ivan Pavlukhin

ср, 4 мар. 2020 г. в 18:18, Denis Magda :

Maxim,

Yes, it's preferable to have metrics pages fully completed even 
though the
feature is an experimental state. We want to encourage to try it out 
and
switch to the new APIs eventually. Without technical instructions 
available

our users will have a hard time checking the new capabilities.

Nikolay, thanks a lot!

-
Denis


On Wed, Mar 4, 2020 at 8:52 AM Nikolay Izhikov  
wrote:



I think yes.

I will prepare documentation shortly.


4 марта 2020 г., в 17:50, Maxim Muzafarov 

написал(а):

Folks,


Do we need a fully complete public documentation for metrics marked
with @ExperimentalFeature? The API can significantly be changed.

On Wed, 4 Mar 2020 at 17:10, Artem Budnikov 


wrote:

The only feature that is left is "WAL page compression"

The three other features are  limitations that were present in 
Ignite

2.7 and now they are removed. Since they were never mentioned in the
docs, there is nothing to do.

-Artem

On 04.03.2020 17:02, Denis Magda wrote:

I'll work on the following items today and tomorrow:

    - JDBC: Support for query cancellation


    - JDBC: Support for query timeout


    - suspend/resume for pessimistic transactions


    - WAL page compression



Artem, are these the only tickets left apart from the metrics &
monitoring? @Nikolay
Izhikov  how soon will you be able to 
finish the

metrics documentation pages?

-
Denis


On Wed, Mar 4, 2020 at 2:55 AM Artem Budnikov 


wrote:


Hi everyone,

I have created the docs for the following items so far:

    -    Default Ignite work dir location


https://apacheignite.readme.io/docs/getting-started-28#section-setting-up-work-directory 


    - Baseline auto-adjust feature


https://apacheignite.readme.io/docs/baseline-topology-28#section-baseline-topology-autoadjustment 


    - Cluster (de)activation events documentation


https://apacheignite.readme.io/docs/baseline-topology-28#section-cluster-activationdeactivation-events 


    - Remove SqlQuery documentation
    done

    - Partition awareness for thin clients


https://apacheignite-net.readme.io/docs/thin-client-28#section-partition-awareness 



https://apacheignite-cpp.readme.io/docs/thin-client-28#section-partition-awareness 


    - Transactions support in java thin client


https://apacheignite.readme.io/docs/key-value-28#section-client-transactions 


    - KILL QUERY command



https://dash.readme.io/project/apacheignite-sql/v2.7.6/docs/kill-query

    - Move rebalance configuration properties to the
    IgniteConfiguration level


https://apacheignite.readme.io/docs/data-rebalancing-28#section-configuration 


    - Renamed IGNITE schema to SYS
    done

I'll work on the following items today and tomorrow:

    - JDBC: Support for query cancellation
    - JDBC: Support for query timeout
    - suspend/resume for pessimistic transactions
    - WAL page compression


Nikolay,

How is your progress with the Metrics and System Views 
documentation?



Artem Budnikov
Technical Writergridgain.com

On 03.03.2020 19:06, Maxim Muzafarov wrote:

Folks,

This is in the `Ignite Core` section, so I think mostly related to
java functionality and thin client protocol extension [1]. 
Sorry for

not being too accurate with this statement
.
The same change is mentioned for C++ and .NET sections of the 
release

notes (but not for other thin clients).


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

On Tue, 3 Mar 2020 at 17:33, Igor Sapego  <

isap...@apache.org> wrote:

That's right, only C++ and .NET clients have partition awareness

Best Regards,
Igor


On Tue, Mar 3, 2020 at 5:02 PM Artem Budnikov 




wrote:


Hi everyone,

Looks like the following line from the Ignite 2.8 release notes 
is a

bit

of an overstatement and should be removed:


Added support best effort affinity for thin clients (partition

awareness)

Java thin client does not support partition awareness. Nodejs and

python
thin clients from the distribution package do not have signs of 
this

feature as well.

Igor,

Could you please confirm or deny this?

-Artem

Artem Budnikov
Technical Writergridgain.com

On 03.03.2020 01:47, Denis Magda wrote:

Hi Alexey,

Thanks for updating the documentation. The update process is

cumbersome as
of now. What will happen is

Re: Ignite 2.8 documentation

[Artem Budnikov]

I'm confused. Igor, could you please double check?

-Artem

On 05.03.2020 04:15, Ivan Pavlukhin wrote:

That's right, only C++ and .NET clients have partition awareness

Are your sure? Was not the feature implemented for java thin client in [1]?

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

Best regards,
Ivan Pavlukhin

ср, 4 мар. 2020 г. в 18:18, Denis Magda :

Maxim,

Yes, it's preferable to have metrics pages fully completed even though the
feature is an experimental state. We want to encourage to try it out and
switch to the new APIs eventually. Without technical instructions available
our users will have a hard time checking the new capabilities.

Nikolay, thanks a lot!

-
Denis


On Wed, Mar 4, 2020 at 8:52 AM Nikolay Izhikov  wrote:


I think yes.

I will prepare documentation shortly.


4 марта 2020 г., в 17:50, Maxim Muzafarov 

написал(а):

Folks,


Do we need a fully complete public documentation for metrics marked
with @ExperimentalFeature? The API can significantly be changed.

On Wed, 4 Mar 2020 at 17:10, Artem Budnikov 

wrote:

The only feature that is left is "WAL page compression"

The three other features are  limitations that were present in Ignite
2.7 and now they are removed. Since they were never mentioned in the
docs, there is nothing to do.

-Artem

On 04.03.2020 17:02, Denis Magda wrote:

I'll work on the following items today and tomorrow:

- JDBC: Support for query cancellation


- JDBC: Support for query timeout


- suspend/resume for pessimistic transactions


- WAL page compression



Artem, are these the only tickets left apart from the metrics &
monitoring? @Nikolay
Izhikov  how soon will you be able to finish the
metrics documentation pages?

-
Denis


On Wed, Mar 4, 2020 at 2:55 AM Artem Budnikov 
wrote:


Hi everyone,

I have created the docs for the following items so far:

-Default Ignite work dir location



https://apacheignite.readme.io/docs/getting-started-28#section-setting-up-work-directory

- Baseline auto-adjust feature



https://apacheignite.readme.io/docs/baseline-topology-28#section-baseline-topology-autoadjustment

- Cluster (de)activation events documentation



https://apacheignite.readme.io/docs/baseline-topology-28#section-cluster-activationdeactivation-events

- Remove SqlQuery documentation
done

- Partition awareness for thin clients



https://apacheignite-net.readme.io/docs/thin-client-28#section-partition-awareness



https://apacheignite-cpp.readme.io/docs/thin-client-28#section-partition-awareness

- Transactions support in java thin client



https://apacheignite.readme.io/docs/key-value-28#section-client-transactions

- KILL QUERY command



https://dash.readme.io/project/apacheignite-sql/v2.7.6/docs/kill-query

- Move rebalance configuration properties to the
IgniteConfiguration level



https://apacheignite.readme.io/docs/data-rebalancing-28#section-configuration

- Renamed IGNITE schema to SYS
done

I'll work on the following items today and tomorrow:

- JDBC: Support for query cancellation
- JDBC: Support for query timeout
- suspend/resume for pessimistic transactions
- WAL page compression


Nikolay,

How is your progress with the Metrics and System Views documentation?


Artem Budnikov
Technical Writergridgain.com

On 03.03.2020 19:06, Maxim Muzafarov wrote:

Folks,

This is in the `Ignite Core` section, so I think mostly related to
java functionality and thin client protocol extension [1]. Sorry for
not being too accurate with this statement
.
The same change is mentioned for C++ and .NET sections of the release
notes (but not for other thin clients).


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

On Tue, 3 Mar 2020 at 17:33, Igor Sapego  <

isap...@apache.org> wrote:

That's right, only C++ and .NET clients have partition awareness

Best Regards,
Igor


On Tue, Mar 3, 2020 at 5:02 PM Artem Budnikov 



wrote:


Hi everyone,

Looks like the following line from the Ignite 2.8 release notes is a

bit

of an overstatement and should be removed:


Added support best effort affinity for thin clients (partition

awareness)

Java thin client does not support partition awareness. Nodejs and

python

thin clients from the distribution package do not have signs of this
feature as well.

Igor,

Could you please confirm or deny this?

-Artem

Artem Budnikov
Technical Writergridgain.com

On 03.03.2020 01:47, Denis Magda wrote:

Hi Alexey,

Thanks for updating the documentation. The update process is

cumbersome as

of now. What will happen is that we will be replacing the content of

the

current pages (pre 2.8 pages) with the content from the 2.8 versions.

Once

the text is copied manually, a 2.8 version of the page will be

deleted. I

would advise Artem to do that this time and update the wiki page with

more

det

Re: Ignite 2.8 documentation

[Artem Budnikov]

The only feature that is left is "WAL page compression"

The three other features are  limitations that were present in Ignite 
2.7 and now they are removed. Since they were never mentioned in the 
docs, there is nothing to do.


-Artem

On 04.03.2020 17:02, Denis Magda wrote:

I'll work on the following items today and tomorrow:

- JDBC: Support for query cancellation


- JDBC: Support for query timeout


- suspend/resume for pessimistic transactions


- WAL page compression



Artem, are these the only tickets left apart from the metrics &
monitoring? @Nikolay
Izhikov  how soon will you be able to finish the
metrics documentation pages?

-
Denis


On Wed, Mar 4, 2020 at 2:55 AM Artem Budnikov 
wrote:


Hi everyone,

I have created the docs for the following items so far:

-Default Ignite work dir location


https://apacheignite.readme.io/docs/getting-started-28#section-setting-up-work-directory

- Baseline auto-adjust feature


https://apacheignite.readme.io/docs/baseline-topology-28#section-baseline-topology-autoadjustment

- Cluster (de)activation events documentation


https://apacheignite.readme.io/docs/baseline-topology-28#section-cluster-activationdeactivation-events

- Remove SqlQuery documentation
done

- Partition awareness for thin clients


https://apacheignite-net.readme.io/docs/thin-client-28#section-partition-awareness


https://apacheignite-cpp.readme.io/docs/thin-client-28#section-partition-awareness

- Transactions support in java thin client

https://apacheignite.readme.io/docs/key-value-28#section-client-transactions

- KILL QUERY command

https://dash.readme.io/project/apacheignite-sql/v2.7.6/docs/kill-query

- Move rebalance configuration properties to the
IgniteConfiguration level


https://apacheignite.readme.io/docs/data-rebalancing-28#section-configuration

- Renamed IGNITE schema to SYS
done

I'll work on the following items today and tomorrow:

- JDBC: Support for query cancellation
- JDBC: Support for query timeout
- suspend/resume for pessimistic transactions
- WAL page compression


Nikolay,

How is your progress with the Metrics and System Views documentation?


Artem Budnikov
Technical Writergridgain.com

On 03.03.2020 19:06, Maxim Muzafarov wrote:

Folks,

This is in the `Ignite Core` section, so I think mostly related to
java functionality and thin client protocol extension [1]. Sorry for
not being too accurate with this statement
.
The same change is mentioned for C++ and .NET sections of the release
notes (but not for other thin clients).


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

On Tue, 3 Mar 2020 at 17:33, Igor Sapego  
 wrote:

That's right, only C++ and .NET clients have partition awareness

Best Regards,
Igor


On Tue, Mar 3, 2020 at 5:02 PM Artem Budnikov  

wrote:


Hi everyone,

Looks like the following line from the Ignite 2.8 release notes is a bit
of an overstatement and should be removed:


Added support best effort affinity for thin clients (partition awareness)

Java thin client does not support partition awareness. Nodejs and python
thin clients from the distribution package do not have signs of this
feature as well.

Igor,

Could you please confirm or deny this?

-Artem

Artem Budnikov
Technical Writergridgain.com

On 03.03.2020 01:47, Denis Magda wrote:

Hi Alexey,

Thanks for updating the documentation. The update process is cumbersome as
of now. What will happen is that we will be replacing the content of the
current pages (pre 2.8 pages) with the content from the 2.8 versions. Once
the text is copied manually, a 2.8 version of the page will be deleted. I
would advise Artem to do that this time and update the wiki page with more
details:https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document

Also, why should we release this 
page?https://dash.readme.io/project/apacheignite/v2.7.6/docs/genetic-algorithms

-
Denis


On Sun, Mar 1, 2020 at 7:59 AM Alexey Zinoviev  

wrote:


Hi, Igniters, I've finished the ML documentation.

I have the issue that, for example I've created a new version of page with
postfix -2.8 and the page name contains this postfix.
How are we going to replace the URL? Or we will replace the content from
initial page?

For example, I've created the new version of 
pagehttps://dash.readme.io/project/apacheignite/v2.7.6/docs/decision-trees
and
moved it under new 
pagehttps://dash.readme.io/project/apacheignite/v2.7.6/docs/decision-trees-28
How it will be processed to obtain the  decision-trees url for the new
page?


In all case the full list of removed/replaced pages for ML is next:

In the release 2.8, please remove the pages

1.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/genetic-algorithms

2.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/svm-mul

Re: Ignite 2.8 documentation

[Artem Budnikov]

Anton,

Yes, I can add this feature to the docs. I have a couple of questions, 
though:


 * Are there any downsides to using this feature?
 * When users should use it? What are the recommendations?


-Artem

On 04.03.2020 13:46, Anton Vinogradov wrote:

Artem,
Is it possible to create documentation for ReadRepair feature [1] [2]?
Feature marked as @IgnireExperimenta but ready to be used.
Javadoc [3] explains the details.

[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-31+Consistency+check+and+fix
[2] https://issues.apache.org/jira/browse/IGNITE-10663
[3] https://issues.apache.org/jira/browse/IGNITE-11978

On Wed, Mar 4, 2020 at 1:15 PM Artem Budnikov 
wrote:


Hi everyone,

I have created the docs for the following items so far:

   * Default Ignite work dir location

https://apacheignite.readme.io/docs/getting-started-28#section-setting-up-work-directory


   *  Baseline auto-adjust feature

https://apacheignite.readme.io/docs/baseline-topology-28#section-baseline-topology-autoadjustment

   *  Cluster (de)activation events documentation

https://apacheignite.readme.io/docs/baseline-topology-28#section-cluster-activationdeactivation-events

   *  Remove SqlQuery documentation
  done

   *  Partition awareness for thin clients

https://apacheignite-net.readme.io/docs/thin-client-28#section-partition-awareness


https://apacheignite-cpp.readme.io/docs/thin-client-28#section-partition-awareness

   *  Transactions support in java thin client

https://apacheignite.readme.io/docs/key-value-28#section-client-transactions


   *  KILL QUERY command
 https://dash.readme.io/project/apacheignite-sql/v2.7.6/docs/kill-query

   *  Move rebalance configuration properties to the
 IgniteConfiguration level

https://apacheignite.readme.io/docs/data-rebalancing-28#section-configuration

   *  Renamed IGNITE schema to SYS
  done

I'll work on the following items today and tomorrow:

   *  JDBC: Support for query cancellation
   *  JDBC: Support for query timeout
   *  suspend/resume for pessimistic transactions
   *  WAL page compression


Nikolay,

How is your progress with the Metrics and System Views documentation?


Artem Budnikov
Technical Writer
gridgain.com

On 03.03.2020 19:06, Maxim Muzafarov wrote:

Folks,

This is in the `Ignite Core` section, so I think mostly related to
java functionality and thin client protocol extension [1]. Sorry for
not being too accurate with this statement
.
The same change is mentioned for C++ and .NET sections of the release
notes (but not for other thin clients).


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

On Tue, 3 Mar 2020 at 17:33, Igor Sapego  wrote:

That's right, only C++ and .NET clients have partition awareness

Best Regards,
Igor


On Tue, Mar 3, 2020 at 5:02 PM Artem Budnikov 
wrote:


Hi everyone,

Looks like the following line from the Ignite 2.8 release notes is a

bit

of an overstatement and should be removed:


Added support best effort affinity for thin clients (partition

awareness)

Java thin client does not support partition awareness. Nodejs and

python

thin clients from the distribution package do not have signs of this
feature as well.

Igor,

Could you please confirm or deny this?

-Artem

Artem Budnikov
Technical Writergridgain.com

On 03.03.2020 01:47, Denis Magda wrote:

Hi Alexey,

Thanks for updating the documentation. The update process is

cumbersome as

of now. What will happen is that we will be replacing the content of

the

current pages (pre 2.8 pages) with the content from the 2.8 versions.

Once

the text is copied manually, a 2.8 version of the page will be

deleted. I

would advise Artem to do that this time and update the wiki page with

more

details:
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document

Also, why should we release this page?


https://dash.readme.io/project/apacheignite/v2.7.6/docs/genetic-algorithms

-
Denis


On Sun, Mar 1, 2020 at 7:59 AM Alexey Zinoviev 
Hi, Igniters, I've finished the ML documentation.

I have the issue that, for example I've created a new version of page

with

postfix -2.8 and the page name contains this postfix.
How are we going to replace the URL? Or we will replace the content

from

initial page?

For example, I've created the new version of page


https://dash.readme.io/project/apacheignite/v2.7.6/docs/decision-trees

and
moved it under new page


https://dash.readme.io/project/apacheignite/v2.7.6/docs/decision-trees-28

How it will be processed to obtain the  decision-trees url for the new
page?


In all case the full list of removed/replaced pages for ML is next:

In the release 2.8, please remove the pages

 1.



https://dash.readme.io/project/apacheignite/v2.7.6/docs/genetic-algorithms

 2.



https://dash.readme.io/project/apacheignite/v2.7.6/docs/svm-multi-class-classification

 3. DeepLearning block with 3 pages
 4.



https

Re: Ignite 2.8 documentation

[Artem Budnikov]

Hi everyone,

I have created the docs for the following items so far:

 *     Default Ignite work dir location
   
https://apacheignite.readme.io/docs/getting-started-28#section-setting-up-work-directory


 *      Baseline auto-adjust feature
   
https://apacheignite.readme.io/docs/baseline-topology-28#section-baseline-topology-autoadjustment

 *      Cluster (de)activation events documentation
   
https://apacheignite.readme.io/docs/baseline-topology-28#section-cluster-activationdeactivation-events

 *      Remove SqlQuery documentation
    done

 *      Partition awareness for thin clients
   
https://apacheignite-net.readme.io/docs/thin-client-28#section-partition-awareness

   
https://apacheignite-cpp.readme.io/docs/thin-client-28#section-partition-awareness

 *      Transactions support in java thin client
   https://apacheignite.readme.io/docs/key-value-28#section-client-transactions


 *      KILL QUERY command
   https://dash.readme.io/project/apacheignite-sql/v2.7.6/docs/kill-query

 *      Move rebalance configuration properties to the
   IgniteConfiguration level
   https://apacheignite.readme.io/docs/data-rebalancing-28#section-configuration

 *      Renamed IGNITE schema to SYS
    done

I'll work on the following items today and tomorrow:

 *      JDBC: Support for query cancellation
 *      JDBC: Support for query timeout
 *      suspend/resume for pessimistic transactions
 *      WAL page compression


Nikolay,

How is your progress with the Metrics and System Views documentation?


Artem Budnikov
Technical Writer
gridgain.com

On 03.03.2020 19:06, Maxim Muzafarov wrote:

Folks,

This is in the `Ignite Core` section, so I think mostly related to
java functionality and thin client protocol extension [1]. Sorry for
not being too accurate with this statement
.
The same change is mentioned for C++ and .NET sections of the release
notes (but not for other thin clients).


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

On Tue, 3 Mar 2020 at 17:33, Igor Sapego  wrote:

That's right, only C++ and .NET clients have partition awareness

Best Regards,
Igor


On Tue, Mar 3, 2020 at 5:02 PM Artem Budnikov 
wrote:


Hi everyone,

Looks like the following line from the Ignite 2.8 release notes is a bit
of an overstatement and should be removed:


Added support best effort affinity for thin clients (partition awareness)

Java thin client does not support partition awareness. Nodejs and python
thin clients from the distribution package do not have signs of this
feature as well.

Igor,

Could you please confirm or deny this?

-Artem

Artem Budnikov
Technical Writergridgain.com

On 03.03.2020 01:47, Denis Magda wrote:

Hi Alexey,

Thanks for updating the documentation. The update process is cumbersome as
of now. What will happen is that we will be replacing the content of the
current pages (pre 2.8 pages) with the content from the 2.8 versions. Once
the text is copied manually, a 2.8 version of the page will be deleted. I
would advise Artem to do that this time and update the wiki page with more
details:
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document

Also, why should we release this page?
https://dash.readme.io/project/apacheignite/v2.7.6/docs/genetic-algorithms

-
Denis


On Sun, Mar 1, 2020 at 7:59 AM Alexey Zinoviev 
wrote:


Hi, Igniters, I've finished the ML documentation.

I have the issue that, for example I've created a new version of page with
postfix -2.8 and the page name contains this postfix.
How are we going to replace the URL? Or we will replace the content from
initial page?

For example, I've created the new version of page
https://dash.readme.io/project/apacheignite/v2.7.6/docs/decision-trees
and
moved it under new page
https://dash.readme.io/project/apacheignite/v2.7.6/docs/decision-trees-28
How it will be processed to obtain the  decision-trees url for the new
page?


In all case the full list of removed/replaced pages for ML is next:

In the release 2.8, please remove the pages

1.

https://dash.readme.io/project/apacheignite/v2.7.6/docs/genetic-algorithms

2.

https://dash.readme.io/project/apacheignite/v2.7.6/docs/svm-multi-class-classification

3. DeepLearning block with 3 pages
4.

https://dash.readme.io/project/apacheignite/v2.7.6/docs/model-cross-validation


Next pages were replaced with postfix 2.8 and grouped under new pages

1.

https://dash.readme.io/project/apacheignite/v2.7.6/docs/machine-learning

2.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/preprocessing

3.

https://dash.readme.io/project/apacheignite/v2.7.6/docs/ols-multiple-linear-regression

4.

https://dash.readme.io/project/apacheignite/v2.7.6/docs/k-means-clustering

5.

https://dash.readme.io/project/apacheignite/v2.7.6/docs/multilayer-perceptron

6.

https://dash.readme.io/project/apacheignite/v2.7.6/docs/knn-classification

7.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/knn-

Re: Ignite 2.8 documentation

[Artem Budnikov]

Hi everyone,


I have created the docs for the following items so far:

   -Default Ignite work dir location

   
https://apacheignite.readme.io/docs/getting-started-28#section-setting-up-work-directory

   - Baseline auto-adjust feature

   
https://apacheignite.readme.io/docs/baseline-topology-28#section-baseline-topology-autoadjustment

   - Cluster (de)activation events documentation

   
https://apacheignite.readme.io/docs/baseline-topology-28#section-cluster-activationdeactivation-events

   - Remove SqlQuery documentation
   done

   - Partition awareness for thin clients

   
https://apacheignite-net.readme.io/docs/thin-client-28#section-partition-awareness

   
https://apacheignite-cpp.readme.io/docs/thin-client-28#section-partition-awareness

   - Transactions support in java thin client

   https://apacheignite.readme.io/docs/key-value-28#section-client-transactions

   - KILL QUERY command

   https://dash.readme.io/project/apacheignite-sql/v2.7.6/docs/kill-query

   - Move rebalance configuration properties to the IgniteConfiguration
   level

   https://apacheignite.readme.io/docs/data-rebalancing-28#section-configuration

   - Renamed IGNITE schema to SYS
   done


Artem Budnikov
Technical Writergridgain.com

On 03.03.2020 19:06, Maxim Muzafarov wrote:

Folks,

This is in the `Ignite Core` section, so I think mostly related to
java functionality and thin client protocol extension [1]. Sorry for
not being too accurate with this statement
.
The same change is mentioned for C++ and .NET sections of the release
notes (but not for other thin clients).


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

On Tue, 3 Mar 2020 at 17:33, Igor Sapego 
 wrote:

That's right, only C++ and .NET clients have partition awareness

Best Regards,
Igor


On Tue, Mar 3, 2020 at 5:02 PM Artem Budnikov 

wrote:


Hi everyone,

Looks like the following line from the Ignite 2.8 release notes is a bit
of an overstatement and should be removed:


Added support best effort affinity for thin clients (partition awareness)

Java thin client does not support partition awareness. Nodejs and python
thin clients from the distribution package do not have signs of this
feature as well.

Igor,

Could you please confirm or deny this?

-Artem

Artem Budnikov
Technical Writergridgain.com

On 03.03.2020 01:47, Denis Magda wrote:

Hi Alexey,

Thanks for updating the documentation. The update process is cumbersome as
of now. What will happen is that we will be replacing the content of the
current pages (pre 2.8 pages) with the content from the 2.8 versions. Once
the text is copied manually, a 2.8 version of the page will be deleted. I
would advise Artem to do that this time and update the wiki page with more
details:https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document

Also, why should we release this
page?https://dash.readme.io/project/apacheignite/v2.7.6/docs/genetic-algorithms

-
Denis


On Sun, Mar 1, 2020 at 7:59 AM Alexey Zinoviev
 
wrote:


Hi, Igniters, I've finished the ML documentation.

I have the issue that, for example I've created a new version of page with
postfix -2.8 and the page name contains this postfix.
How are we going to replace the URL? Or we will replace the content from
initial page?

For example, I've created the new version of
pagehttps://dash.readme.io/project/apacheignite/v2.7.6/docs/decision-trees
and
moved it under new
pagehttps://dash.readme.io/project/apacheignite/v2.7.6/docs/decision-trees-28
How it will be processed to obtain the  decision-trees url for the new
page?


In all case the full list of removed/replaced pages for ML is next:

In the release 2.8, please remove the pages

   1.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/genetic-algorithms

   2.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/svm-multi-class-classification

   3. DeepLearning block with 3 pages
   4.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/model-cross-validation


Next pages were replaced with postfix 2.8 and grouped under new pages

   1.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/machine-learning

   2.https://dash.readme.io/project/apacheignite/v2.7.6/docs/preprocessing

   3.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/ols-multiple-linear-regression

   4.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/k-means-clustering

   5.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/multilayer-perceptron

   6.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/knn-classification

   7.https://dash.readme.io/project/apacheignite/v2.7.6/docs/knn-regression

   8.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/svm-binary-classification

   9.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/logistic-regression

   10.https://dash.readme.io/project/apacheignite/v2.7.6/docs/random-forest

   11.
https://dash.readme.io/project/apacheignite/v2.7.6/do

Re: Ignite 2.8 documentation

[Artem Budnikov]

Hi everyone,

Looks like the following line from the Ignite 2.8 release notes is a bit 
of an overstatement and should be removed:


> Added support best effort affinity for thin clients (partition awareness)

Java thin client does not support partition awareness. Nodejs and python 
thin clients from the distribution package do not have signs of this 
feature as well.


Igor,

Could you please confirm or deny this?

-Artem

Artem Budnikov
Technical Writer
gridgain.com

On 03.03.2020 01:47, Denis Magda wrote:

Hi Alexey,

Thanks for updating the documentation. The update process is 
cumbersome as of now. What will happen is that we will be replacing 
the content of the current pages (pre 2.8 pages) with the content from 
the 2.8 versions. Once the text is copied manually, a 2.8 version of 
the page will be deleted. I would advise Artem to do that this time 
and update the wiki page with more details:

https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document

Also, why should we release this page?
https://dash.readme.io/project/apacheignite/v2.7.6/docs/genetic-algorithms

-
Denis


On Sun, Mar 1, 2020 at 7:59 AM Alexey Zinoviev <mailto:zaleslaw@gmail.com>> wrote:


Hi, Igniters, I've finished the ML documentation.

I have the issue that, for example I've created a new version of
page with
postfix -2.8 and the page name contains this postfix.
How are we going to replace the URL? Or we will replace the
content from
initial page?

For example, I've created the new version of page
https://dash.readme.io/project/apacheignite/v2.7.6/docs/decision-trees
and
moved it under new page
https://dash.readme.io/project/apacheignite/v2.7.6/docs/decision-trees-28
How it will be processed to obtain the  decision-trees url for the
new page?


In all case the full list of removed/replaced pages for ML is next:

In the release 2.8, please remove the pages

   1.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/genetic-algorithms

   2.

https://dash.readme.io/project/apacheignite/v2.7.6/docs/svm-multi-class-classification

   3. DeepLearning block with 3 pages
   4.

https://dash.readme.io/project/apacheignite/v2.7.6/docs/model-cross-validation


Next pages were replaced with postfix 2.8 and grouped under new pages

   1.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/machine-learning

   2.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/preprocessing

   3.

https://dash.readme.io/project/apacheignite/v2.7.6/docs/ols-multiple-linear-regression

   4.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/k-means-clustering

   5.

https://dash.readme.io/project/apacheignite/v2.7.6/docs/multilayer-perceptron

   6.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/knn-classification

   7.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/knn-regression

   8.

https://dash.readme.io/project/apacheignite/v2.7.6/docs/svm-binary-classification

   9.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/logistic-regression

   10.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/random-forest

   11.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/gradient-boosting

   12.
https://dash.readme.io/project/apacheignite/v2.7.6/docs/model-updating
   13.

https://dash.readme.io/project/apacheignite/v2.7.6/docs/ann-approximate-nearest-neighbor




ср, 26 февр. 2020 г. в 03:32, Denis Magda mailto:dma...@apache.org>>:

> Hi Prasad,
>
> This is odd behavior and before changing the docs I would try to
get to the
> bottom. Let me join the user list conversation.
>
> -
> Denis
>
>
> On Tue, Feb 25, 2020 at 3:46 AM Prasad Bhalerao <
> prasadbhalerao1...@gmail.com
<mailto:prasadbhalerao1...@gmail.com>> wrote:
>
> > Hi,
> >
> > Can we have this behavior documented? This will help user to
design their
> > caches appropriately.
> >
> > *For Replicated Cache:*
> >
> > Reference mail thread:
> >
> >
>

http://apache-ignite-users.70518.x6.nabble.com/Read-through-not-working-as-expected-in-case-of-Replicated-cache-td29990.html
> >
> >  read through for replicated cache would work where there is
either:
> > - writeThrough enabled and all changes do through it.
> > - database contents do not change for already read keys.
> >
> > Thanks,
> > Prasad
> >
> > On Mon, Feb 24, 2020 at 7:31 PM Alexey Zinoviev
mailto:zaleslaw@gmail.com>>
> > wrote:
> >
> > > Please, could you post in this thre

Re: Ignite 2.8 documentation

[Artem Budnikov]

Maxim,

One note from my side, I think we can move disk page compression [1]
> to the 2-nd priority, but definitely must document WAL page
> compression first [2]


OK, good to know.

On Wed, Feb 19, 2020 at 6:48 PM Maxim Muzafarov  wrote:

> Artem,
>
>
> Thank you for starting this thread.
> One note from my side, I think we can move disk page compression [1]
> to the 2-nd priority, but definitely must document WAL page
> compression first [2]
>
>
> The list of important tasks [3].
> The list of documentation tasks [4].
>
> [1] https://issues.apache.org/jira/browse/IGNITE-10330
> [2] https://issues.apache.org/jira/browse/IGNITE-11336
> [3]
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Themostimportantreleasetasks
> [4]
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Unresolveddocumentationtasks
>
> On Wed, 19 Feb 2020 at 18:15, Artem Budnikov
>  wrote:
> >
> > Hi everyone,
> >
> > As the release of Ignite 2.8 is getting closer, let's discuss which
> features should be documented. I created a list of features based on the
> release notes and the documentation tickets in jira (see below). Much more
> has been added, but these seemed to have first priority. It's not to say
> that other features are not important, but given the limited resources a
> list of high-priority task would help to schedule the time of those who
> will help with the docs.
> >
> > Here is the list of features:
> >
> > Disk page compression
> > Metrics and System Views documentation
> > Default Ignite work dir location
> > Baseline auto-adjust feature
> > Cluster (de)activation events documentation
> > Remove SqlQuery documentation
> > Partition awareness for thin clients
> > Transactions support in thin clients
> > KILL QUERY command
> > Move rebalance configuration properties to the IgniteConfiguration level
> > Renamed IGNITE schema to SYS
> > JDBC: Support for query cancellation
> > JDBC: Support for query timeout
> > suspend/resume for pessimistic transactions
> >
> > Now, two really big questions here:
> >
> > If you want to add anything else to the documentation, please let us
> know in this thread.
> > If you are the author of any of the features listed above, please share
> the details on the feature. You can do it by creating a documentation
> ticket. If you want to contribute a page or section to the existing docs,
> you can write directly on apacheignite.readme.io (send me a note if you
> don't have an account there). Any help is greatly appreciated.
> >
> > -Artem
> >
> >
>

Ignite 2.8 documentation

[Artem Budnikov]

Hi everyone,

As the release of Ignite 2.8 is getting closer, let's discuss which 
features should be documented. I created a list of features based on the 
release notes and the documentation tickets in jira (see below). Much 
more has been added, but these seemed to have first priority. It's not 
to say that other features are not important, but given the limited 
resources a list of high-priority task would help to schedule the time 
of those who will help with the docs.


Here is the list of features:

 * Disk page compression
 * Metrics and System Views documentation
 * Default Ignite work dir location
 * Baseline auto-adjust feature
 * Cluster (de)activation events documentation
 * Remove SqlQuery documentation
 * Partition awareness for thin clients
 * Transactions support in thin clients
 * KILL QUERY command
 * Move rebalance configuration properties to the IgniteConfiguration level
 * Renamed IGNITE schema to SYS
 * JDBC: Support for query cancellation
 * JDBC: Support for query timeout
 * suspend/resume for pessimistic transactions

Now, two really big questions here:

1. If you want to add anything else to the documentation, please let us
   know in this thread.
2. If you are the author of any of the features listed above, please
   share the details on the feature. You can do it by creating a
   documentation ticket. If you want to contribute a page or section to
   the existing docs, you can write directly on apacheignite.readme.io
   (send me a note if you don't have an account there). Any help is
   greatly appreciated.

-Artem

Re: Update documentation about using Spring Data for Ignite

[Artem Budnikov]

Hi Sergey,

Please create a ticket for documentation update as described in this 
section: 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-Documentingaticket


-Artem

On 07.02.2020 12:00, Sergey Chernolyas wrote:

Hi igniters!

Feature, which I working on, requires to update the page
https://apacheignite-mix.readme.io/docs/spring-data#section-apache-ignite-repository
.
Because the feature provides additional way to link Spring repository with
particular cache.
I think It is required additional example of code.

Re: Hint for user that baseline topology should be changed in order to trigger rebalance

[Artem Budnikov]

Hi everyone,

I think a link to the documentation is unnecessary. We could simply 
mention "baseline topology", and users will be able to find what it is 
in the docs.


Artem Budnikov
Technical Writer
gridgain.com

On 13.01.2020 21:15, Denis Magda wrote:

Stan,

I would not suggest us adding any links to docs as long as the message 
needs to be self-explanatory. If someone doesn't get it then they 
should google. Taking your feedback into consideration:


"New server node joined the cluster, add it to the baseline topology 
to store data there  [[topVer=2, minorTopVer=0], force=false, 
evt=NODE_JOINED, node=57bc10fe-1505-4e8e-9987-52c9c903c6ef]]


*Artem*, could you share your thoughts on this? *Ivan*, what's your 
thinking?


-
Denis


On Mon, Jan 13, 2020 at 5:27 AM Stanislav Lukyanov 
mailto:stanlukya...@gmail.com>> wrote:


We already have a ticket for this open BTW:
https://issues.apache.org/jira/browse/IGNITE-8115
<https://issues.apache.org/jira/browse/IGNITE-8115>.

I would also avoid saying anything about rebalancing - at this
point the user may not know what it is.
This message is very clearly targeted at new users, so it is
probably wrong to assume that they know
what baseline topology or rebalancing is.

I think it's better to say something like "add it to the baseline
topology if you want it to store data. See  for details.".

Stan

> On 9 Jan 2020, at 23:28, Denis Magda mailto:dma...@apache.org>> wrote:
>
> Ivan, Igniters, thanks for starting the discussion,
>
> How about the following a bit simplified message template? It's
assumed the
> user is aware of what both rebalancing and baseline topology mean.
>
> "New server node joined the cluster, add it to the baseline topology
> manually to trigger data rebalancing [node details]"
>
> a complete message will look like this
>
> "New server node joined the cluster, add it to the baseline topology
> manually to trigger data rebalancing [[topVer=2, minorTopVer=0],
> force=false, evt=NODE_JOINED,
node=57bc10fe-1505-4e8e-9987-52c9c903c6ef]]
>
>
> -
> Denis
>
>
> On Thu, Jan 9, 2020 at 6:21 AM Ivan Rakov mailto:ivan.glu...@gmail.com>> wrote:
>
>> Folks,
>>
>> Since 2.4, Ignite cluster requires baseline topology in
persistent mode.
>> That means if user wants to scale cluster and add more nodes,
data won't be
>> redistributed among the whole node set until manual call of
>> IgniteCluster#setBaselineTopology.
>>
>> Surely this behavior is well-documented, but don't we need to
give user a
>> hint that baseline topology should be managed manually? I
think, log
>> message with something like "Current set of nodes differs from
baseline
>> topology, please call XXX in order to trigger rebalance and
redistribute
>> your data" will make the situation a bit more transparent.
>>
>> Right now we have only this message
>>
>>> [2020-01-07T19:36:45,997][INFO
>>>
>>

][exchange-worker-#39%blue-54.158.100.161%][GridCachePartitionExchangeManager]
>> Skipping
>>> rebalancing (nothing scheduled) [top=AffinityTopologyVersion
[topVer=2,
>>> minorTopVer=0], force=false, evt=NODE_JOINED,
>> node=57bc10fe-1505-4e8e-9987-
>>> 52c9c903c6ef]
>>
>> which doesn't properly explain what's going on.
>>

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

[Artem Budnikov]

Hi Maxim,

I'm glad to see that you care about documentation. Way to go! Here is a 
couple of points that can help:


1) I think it's safe to assume that Prachi will not work on the Ignite 
documentation any longer. You can take up the issues assigned to her and 
prioritize them whichever way is convenient for yourself. In fact, you 
can take up other's issues as well.


2) I'll try to do my best to finish as much documentation issues as I'll 
be able to by the release date.


So, it looks like that in general we are good.

-Artem

On 13.10.2019 15:55, Maxim Muzafarov wrote:

Ilya,

I agree that issues related to `documentation` can be safely
postponed, however, for me the whole batch of such issues looks
unmanageable and unclear. At least we should prioritize all of them to
complete the maximum that we can by the deadline.

On Thu, 10 Oct 2019 at 19:47, Ilya Kasnacheev  wrote:

Hello!

I think that Documentation tickets may be safely postponed until final
stages of release, since it's not included in artifacts, rather available
on readme.io, etc.

Regards,
--
Ilya Kasnacheev


чт, 10 окт. 2019 г. в 14:41, Pavel Kovalenko :


Issues link is broken, because it has a filter that can't be found.
Here is correct link:

https://issues.apache.org/jira/issues/?jql=project%20%3D%20Ignite%20AND%20status%20in%20(Open%2C%20Reopened%2C%20%22In%20Progress%22%2C%20%22Patch%20Available%22)%20AND%20fixVersion%20%3D%202.8%20and%20component%20%3D%20Documentation%20order%20by%20status

чт, 10 окт. 2019 г. в 13:38, Maxim Muzafarov :


Igniters,


Who can advise what we can\should do with the issues related to
`documentation` component to release Ignite 2.8 version?
How can I sort them and prioritize?
What are best-practices here?

Currently, we have 81 issues pinned to 2.8 release [1].

6 - `In Progress`
2 - `Patch Available`
73 - `Open`

Some of the issues are assigned to the `Prachi Garg` which is not
active since February 15-th 2019.

[1]


https://issues.apache.org/jira/issues/?filter=12347303&jql=project%20%3D%20Ignite%20AND%20status%20in%20(Open%2C%20Reopened%2C%20%22In%20Progress%22%2C%20%22Patch%20Available%22)%20AND%20fixVersion%20%3D%202.8%20and%20component%20%3D%20Documentation%20order%20by%20status


On Thu, 3 Oct 2019 at 01:52, Denis Magda  wrote:

Maxim,

This sounds reasonable to me.

-
Denis


On Wed, Oct 2, 2019 at 8:55 AM Maxim Muzafarov 

wrote:

Folks,

Since we are focusing on new SQL engine implementation I'd like to
perform bulk moving of all MVCC related unassigned tickets [1] to the
next release.
Can you confirm?

[1]


https://issues.apache.org/jira/issues/?jql=project%20%3D%20Ignite%20AND%20status%20in%20(Open%2C%20Reopened)%20AND%20fixVersion%20%3D%202.8%20and%20priority%20in%20(Major)%20and%20summary%20~%20MVCC

On Wed, 2 Oct 2019 at 01:27, Denis Magda  wrote:

Alexey Z.,

Could you please answer some of the questions



- IGNITE-11942 IGFS and Hadoop Accelerator Discontinuation [2].
Probably should be moved to the next release due to dependency on
Tensorflow. Need to check. (Andrey Gura)


Can we decouple Tensorflow from the IGFS?

Mark all the issues related to ML, Spark 2.4, Monitoring major

features and track their comletion to be sure on there is no
unfinished major changes will be present in 2.8 release.
- ML (Alexey Zinoviev)


Are there any other ML contributors who will be helping you with

this

release?

-
Denis


On Tue, Oct 1, 2019 at 6:56 AM Maxim Muzafarov 

wrote:

Igniters,


Here is the list of activities we've agreed on to prepare the

Apache

Ignite 2.8 release.

1.
Preliminary release dates with the ability to shift them if some

of

the planned activities will not be finalized. But anyway we

should

build our engagement based on these dates.

Scope Freeze: November 5, 2019
Code Freeze: December 2, 2019
Voting Date: January 10, 2020
Release Date: January 17, 2020

2.
Mark all the issues related to ML, Spark 2.4, Monitoring major
features and track their comletion to be sure on there is no
unfinished major changes will be present in 2.8 release.
- ML (Alexey Zinoviev)
- Spark [1] [4] (Alexey Zinoviev)
- Monitoring (Nikolay Izhikov)

3.
Review and mark all the partially completed major issues

currently

present in the master branch.
- major IEPs e.g. IEP-18, non-blocking PME (Maxim Muzafarov)
- review major commits in the master branch (Maxim Muzafarov)

4.
Review blocker issues currently pinned to 2.8 release.
- IGNITE-11942 IGFS and Hadoop Accelerator Discontinuation [2].
Probably should be moved to the next release due to dependency on
Tensorflow. Need to check. (Andrey Gura)
- IGNITE-9489 CorruptedTreeException on index create [3]. Check

all

the issues releated to this. Some of them already fixed by

GridGain.

Need to check. (Andrey Gura)
- IGNITE-12181 Rebalance hangs on BLT change. The cause has been
found. Will be fixed. (Maxim Muzafarov)
- Need to check all the other blocker issues (Maxim Muzafarov)

5.
QA regression (2.7 -> 2.8). I'll provide additional details w

Re: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

[Artem Budnikov]

Hi,

I've created new versions for other projects on readme.io

-Artem

On 18.09.2019 19:17, Alexey Goncharuk wrote:

Igniters,

I am following the release process procedure [1] and currently on docs
update step. I can login to the admin panel, but I can only see the main
Ignite docs project. Who can add me to the remaining projects (C#/.NET,
C++, SQL, Integrations*, Ignite for Spark, Tools) or perhaps clone the docs
for 2.7.6?

[1] https://cwiki.apache.org/confluence/display/IGNITE/Release+Process

ср, 11 сент. 2019 г. в 20:44, Alexey Goncharuk :


Ivan, thank you!

Will update release notes and start the build shortly.

ср, 11 сент. 2019 г. в 20:41, Ivan Rakov :


Alexey,

I've merged https://issues.apache.org/jira/browse/IGNITE-12163 to master
and 2.7.6.

Best Regards,
Ivan Rakov

On 11.09.2019 18:13, Alexey Goncharuk wrote:

Good,

Please let me know when this is done, I will re-upload the release
artifacts.

ср, 11 сент. 2019 г. в 18:11, Alexandr Shapkin :


Alexey,

The changes already have been tested, so no TC problems expected.
If this is true, then we need just a few hours to merge them.

From: Alexey Goncharuk
Sent: Wednesday, September 11, 2019 6:03 PM
To: dev
Cc: Dmitriy Govorukhin; Anton Kalashnikov
Subject: Re: Re[2]: Apache Ignite 2.7.6 (Time, Scope, and Release

manager)

Alexandr,

I almost sent the vote email :) When do you expect the fix to be in

master

and 2.7.6?

ср, 11 сент. 2019 г. в 17:38, Alexandr Shapkin :


Folks,

A critical bug was detected in .NET [1].

I understand that it’s a little bit late, but I propose to include

this

issue into the release scope.

PR is ready, currently waiting for a TC visa.

Thoughts?

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


From: Alexey Goncharuk
Sent: Monday, September 9, 2019 5:11 PM
To: dev
Cc: Dmitriy Govorukhin; Anton Kalashnikov
Subject: Re: Re[2]: Apache Ignite 2.7.6 (Time, Scope, and Release

manager)

Igniters,

I just pushed the last ticket to ignite-2.7.6 branch; looks like we

are

ready for the next iteration.

Given that Dmitriy Pavlov will be unavailable till the end of this

week,

I

will take over the release. TC re-run is started.

чт, 5 сент. 2019 г. в 16:14, Dmitriy Govorukhin <
dmitriy.govoruk...@gmail.com>:


Hi Igniters,

I finished work on

https://issues.apache.org/jira/browse/IGNITE-12127,

fix

already in master and ignite-2.7.6

On Wed, Sep 4, 2019 at 2:22 PM Dmitriy Govorukhin <
dmitriy.govoruk...@gmail.com> wrote:


Hi Alexey,

I think that I will finish work on the fix tomorrow. Fix already

completed

but I need to get VISA from TC bot.

On Mon, Sep 2, 2019 at 8:27 PM Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:


Folks, it looks like I was overly optimistic with the estimates for

the

mentioned two tickets.

Dmitriy, Anton,
Can you share your vision when the issues will be fixed? Perhaps,

it

makes

sense to release 2.7.6 with the already fixed issues and schedule

2.7.7?

Neither of them is a regression, so it's ok to release 2.7.6 as it

is

now.

Thoughts?

сб, 31 авг. 2019 г. в 11:37, Alexey Goncharuk <

alexey.goncha...@gmail.com

:
Yes, my bad, forgot to include the link. That's the one.

пт, 30 авг. 2019 г. в 15:01, Maxim Muzafarov 
:

Alexey,

Does the issue [1] is related to this [2] discussion on the

user-list?

If yes, I think it is very important to include these fixes to

2.7.6.

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


http://apache-ignite-users.70518.x6.nabble.com/Node-failure-with-quot-Failed-to-write-buffer-quot-error-td29100.html

On Fri, 30 Aug 2019 at 14:26, Alexei Scherbakov
 wrote:

Alexey,

Looks like important fixes, better to include them.

пт, 30 авг. 2019 г. в 12:51, Alexey Goncharuk <

alexey.goncha...@gmail.com>:

Igniters,

Given that the RC1 vote did not succeed and we are still

waiting

for

a few

minor fixes, may I suggest including these two tickest to the

2.7.6

scope?

https://issues.apache.org/jira/browse/IGNITE-12127
https://issues.apache.org/jira/browse/IGNITE-12128

The first one has been already reported on the dev-list [1],

the

second one

may cause a state when an Ignite node cannot start on

existing

persisted

data. Looking at the tickets, the fixes should be reasonably

easy,

so

it

should not shift 2.7.6 release timeline much.

Thoughts?

ср, 28 авг. 2019 г. в 15:25, Nikolay Izhikov <

nizhi...@apache.org

:

Separate repos for different Spark version is a good idea

for

me.

Anyway, can you help with Spark version migration,  for

now?

В Ср, 28/08/2019 в 15:20 +0300, Alexey Zinoviev пишет:

Maybe the best solution today add for each new version of

Spark

the

sub-module (Spark-2.3, Spark-2.4) or the separate

repository

with

modules

for each version or another way with separate repository

and

different

branches like in

https://github.com/datastax/spark-cassandra-connector

3 ways to support different versions with the different

costs

of

support

In the case of separate repository I could help,

Re: Cache expiry policy not deleting records from disk(native persistence)

[Artem Budnikov]

Hi Denis,

That's on the expiry policies page: 
https://apacheignite.readme.io/docs/expiry-policies


On 13.09.2019 19:46, Denis Magda wrote:
Artem, thanks, could you please share a reference to the updated page? 
Can't find anything here:

https://apacheignite.readme.io/docs/evictions

Shiva, I've restarted the discussion on the dev list, to get to the 
bottom of this gap and how it can be addressed:

http://apache-ignite-developers.2346864.n4.nabble.com/How-to-free-up-space-on-disc-after-removing-entries-from-IgniteCache-with-enabled-PDS-td39839.html

-
Denis


On Fri, Sep 13, 2019 at 7:05 AM Artem Budnikov 
mailto:a.budnikov.ign...@gmail.com>> wrote:


Hi Denis,

I updated the page about eviction policies. Not freeing up space
on disk was not implemented for reasons explained in the dev-list
thread. I'll update the page once more if/when a solution is
implemented.

Artem

On 13.09.2019 00:34, Denis Magda wrote:

Shiva,

Hopefully, someone from the dev community will pick this ticket
up soon and solve the task. In the meantime, Artem, would you
mind documenting this limitation referring to ticket 10862?

-
Denis


On Tue, Sep 10, 2019 at 12:50 AM Shiva Kumar
mailto:shivakumar@gmail.com>> wrote:

I have filed a bug
https://issues.apache.org/jira/browse/IGNITE-12152 but this
is same as https://issues.apache.org/jira/browse/IGNITE-10862
Any idea on the timeline of these tickets?
In the documentation
https://apacheignite.readme.io/v2.7/docs/expiry-policies
it says when native persistence is enabled "*expired entries
are removed from both memory and disk tiers*" but in the disk
it just mark the pages as unwanted pages and same disk space
used by these unwanted pages will be used to store new pages
but it will not remove unwanted pages from disk and so it
will not release disk space used by these unwanted pages.

here is the developer's discussion link

http://apache-ignite-developers.2346864.n4.nabble.com/How-to-free-up-space-on-disc-after-removing-entries-from-IgniteCache-with-enabled-PDS-td39839.html


On Mon, Sep 9, 2019 at 11:53 PM Shiva Kumar
mailto:shivakumar@gmail.com>>
wrote:

Hi
I have deployed ignite on kubernetes and configured two
seperate persistent volume for WAL and persistence.
The issue Iam facing is same as
https://issues.apache.org/jira/browse/IGNITE-10862

Thanks
Shiva

On Mon, 9 Sep, 2019, 10:47 PM Andrei Aleksandrov,
mailto:aealexsand...@gmail.com>> wrote:

Hello,

I guess that generated WAL will take this disk space.
Please read about WAL here:

https://apacheignite.readme.io/docs/write-ahead-log

Please provide the size of every folder under
/opt/ignite/persistence.

BR,
Andrei

9/6/2019 9:45 PM, Shiva Kumar пишет:

Hi all,
I have set cache expiry policy like this


 
 
          
              
                
                
                
                
                
                  

                      


                      

                  
                

              
          
 


And batch inserting records to one of the table
which is created with above cache template.
Around 10 minutes, I ingested ~1.5GB of data and
after 10 minutes records started reducing(expiring)
when I monitored from sqlline.

0: jdbc:ignite:thin://192.168.*.*:10800> select
count(ID) from DIMENSIONS;


COUNT(ID)


248896

1 row selected (0.86 seconds)
0: jdbc:ignite:thin://192.168.*.*:10800> select
count(ID) from DIMENSIONS;


COUNT(ID)


222174

1 row selected (0.313 seconds)
0: jdbc:ignite:thin://192.168.*.*:10800> select
count(ID) from DIMENSIONS;
   

Re: Cache expiry policy not deleting records from disk(native persistence)

[Artem Budnikov]

Hi Denis,

I updated the page about eviction policies. Not freeing up space on disk 
was not implemented for reasons explained in the dev-list thread. I'll 
update the page once more if/when a solution is implemented.


Artem

On 13.09.2019 00:34, Denis Magda wrote:

Shiva,

Hopefully, someone from the dev community will pick this ticket up 
soon and solve the task. In the meantime, Artem, would you mind 
documenting this limitation referring to ticket 10862?


-
Denis


On Tue, Sep 10, 2019 at 12:50 AM Shiva Kumar > wrote:


I have filed a bug
https://issues.apache.org/jira/browse/IGNITE-12152 but this is
same as https://issues.apache.org/jira/browse/IGNITE-10862
Any idea on the timeline of these tickets?
In the documentation
https://apacheignite.readme.io/v2.7/docs/expiry-policies
it says when native persistence is enabled "*expired entries are
removed from both memory and disk tiers*" but in the disk it just
mark the pages as unwanted pages and same disk space used by these
unwanted pages will be used to store new pages but it will not
remove unwanted pages from disk and so it will not release disk
space used by these unwanted pages.

here is the developer's discussion link

http://apache-ignite-developers.2346864.n4.nabble.com/How-to-free-up-space-on-disc-after-removing-entries-from-IgniteCache-with-enabled-PDS-td39839.html


On Mon, Sep 9, 2019 at 11:53 PM Shiva Kumar
mailto:shivakumar@gmail.com>> wrote:

Hi
I have deployed ignite on kubernetes and configured two
seperate persistent volume for WAL and persistence.
The issue Iam facing is same as
https://issues.apache.org/jira/browse/IGNITE-10862

Thanks
Shiva

On Mon, 9 Sep, 2019, 10:47 PM Andrei Aleksandrov,
mailto:aealexsand...@gmail.com>> wrote:

Hello,

I guess that generated WAL will take this disk space.
Please read about WAL here:

https://apacheignite.readme.io/docs/write-ahead-log

Please provide the size of every folder under
/opt/ignite/persistence.

BR,
Andrei

9/6/2019 9:45 PM, Shiva Kumar пишет:

Hi all,
I have set cache expiry policy like this


 
 
          
              
                
                
                
                
                
                  
                    
                      
                        
                        
                      
                    
                  
                

              
          
 


And batch inserting records to one of the table which is
created with above cache template.
Around 10 minutes, I ingested ~1.5GB of data and after 10
minutes records started reducing(expiring) when I
monitored from sqlline.

0: jdbc:ignite:thin://192.168.*.*:10800> select count(ID)
from DIMENSIONS;


COUNT(ID)


248896

1 row selected (0.86 seconds)
0: jdbc:ignite:thin://192.168.*.*:10800> select count(ID)
from DIMENSIONS;


COUNT(ID)


222174

1 row selected (0.313 seconds)
0: jdbc:ignite:thin://192.168.*.*:10800> select count(ID)
from DIMENSIONS;


COUNT(ID)


118154

1 row selected (0.15 seconds)
0: jdbc:ignite:thin://192.168.*.*:10800>
0: jdbc:ignite:thin://192.168.*.*:10800> select count(ID)
from DIMENSIONS;


COUNT(ID)


76061

1 row selected (0.106 seconds)
0: jdbc:ignite:thin://192.168.*.*:10800>
0: jdbc:ignite:thin://192.168.*.*:10800> select count(ID)
from DIMENSIONS;


COUNT(ID)


41671

1 row selected (0.063 seconds)
0: jdbc:ignite:thin://192.168.*.*:10800> select coun

Re: Update the rebalance configuration documentation

[Artem Budnikov]

Hi Maxim,

Please create a documentation ticket as described here [1] or here [2].

Garrett, this improvement will be released in Ignite 2.8.


[1]: 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document#HowtoDocument-Basics 



[2]: 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-Documentingaticket


-Artem

On 27.08.2019 22:05, Garrett Alley wrote:

Hello Maxim,

I'll take a look at this soon and make sure the documentation is up to date.

Also, you're always welcome to make suggested edits to the readme.io page.

Thanks!
===

Garrett Alley
Documentation
GridGain Systems


On Tue, Aug 27, 2019 at 10:38 AM Maxim Muzafarov  wrote:


Igniters,

I'm worrying about updating the Ignite documentation.

Can you advise who will or should update the Ignite documentation
rebalancing page [2] since the [1] issue has merged to the master
branch and some of the parameters have moved to the
IgniteConfiguration level?

I've marked this issue [1] as `Docs Required` but should I make some
changes at readme.io page?

[1] https://issues.apache.org/jira/browse/IGNITE-11821
[2] https://apacheignite.readme.io/docs/rebalancing

Re: Control.sh usability & possible bugs

[Artem Budnikov]

Hi everyone,

Re Issue 3:

That's a good idea, but as far as I remember this was done in 
https://jira.apache.org/jira/browse/IGNITE-10279 and is waiting to be 
released in Ignite 2.8.


-Artem

On 26.08.2019 15:18, Anton Kalashnikov wrote:

Hello, Igniters.

+1 for Script help usability - issue 3

Looks like it will be great if we avoid the repeated output of the commands, 
ex.:

control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] [--password PASSWORD]  
[--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT] [] 
[--yes]

Allowable :
--activate - ...
--deactivate - ...
...

--
Best regards,
Anton Kalashnikov


26.08.2019, 15:00, "Dmitriy Pavlov" :

Hi Igniters,

During voting on 2.7.6-rc1, I saw how experienced Ignite contributor
committer and PMC member were trying to activate cluster using control.sh
command.

We usually just call cluster().active(true), but end users have to use the
script provided in the distribution.

Related to control.sh there are 3 concerns:

Issue 1: On Mac OS if there is an empty (unset) JAVA_HOME variable, script
outputs noting and probably does not execute its comment.

Petr Ivanov, Alexey Goncharuck, could you please double-check if it could
be fixed?

Issue 2: Control.sh was not able to connect to cluster (local). AFAIK
multicast is still our defaults. so it should be possible to connect to
cluster without any options.

Ivan Rakov, could you please chime in? Is it a local issue or bug?

Issue 3: Script help usability

Example of output:

  Activate cluster:

 control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] [--password
PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT]
--activate

   Deactivate cluster:

 control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] [--password
PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT]
--deactivate [--yes]

  ...

Why do we repeat tons of parameters each time? Is it better for users to
enlist options and commands separately?

  control.sh [options] command

and then enlist options

[--host HOST_OR_IP]

[--port PORT]

[--user USER]

[--password PASSWORD]

[--ping-interval PING_INTERVAL]

[--ping-timeout PING_TIMEOUT]

and describe several commands we have?

In coding WET is not the best solution. So maybe we could DRY in our help,
should we?

Artem Boudnikov, could you evaluate this idea?

Sincerely,
Dmitriy Pavlov

Re: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

[Artem Budnikov]

Hi Dmitry,

The release notes reviewed. Please see my comment in the pull request.

-Artem

On 19.08.2019 14:20, Dmitriy Pavlov wrote:

Hi Andrey,

could you please take a look at
https://issues.apache.org/jira/browse/IGNITE-12061 ?

Are you comfortable with merging it to release (in rush mode)?

Sincerely,
Dmitriy Pavlov

вс, 18 авг. 2019 г. в 18:12, Dmitriy Pavlov :


Hi Igniters,

please review release notes for Ignite 2.7.6 (-rc0), tickets:
https://issues.apache.org/jira/issues/?jql=labels%20%3D%202.7.6-rc0 :

Text version:
https://github.com/apache/ignite/pull/6788/files

And corresponding HTML version (will be available at SVN once vote passes):

- Ignite work directory is set to current user's home directory by
default, native persistence files aren't stored in Temp anymore
[#IGNITE-12057] 
- Fixed the bug when SELECT with an equality predicate on the part of
a primary compound key returned a single row result while multiple matching
rows existed in the table [#IGNITE-12068]

- Fixed data corruption in the rare case when page replacement can
reload an outdated page during checkpoint [#IGNITE-12081]

- Fixed tree corruption caused by incorrect row size calculation for
shared cache groups [#IGNITE-12060]

- Java heap footprint reduced by optimizing
GridDhtPartitionsFullMessage maps in exchange history [#IGNITE-11767]

- .NET: Fix for native persistence, now it works with custom affinity
function [#IGNITE-10451]



For remained tickets

https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.7.6%20and%20(labels%20!%3D%202.7.6-rc0%20or%20labels%20is%20EMPTY%20)

please add desired release note as a comment (since I still not asked
Infra about a separate field).

Sincerely,
Dmitriy Pavlov

вс, 18 авг. 2019 г. в 12:59, Dmitriy Pavlov :


Ok, Ivan, thank you for sharing this bit of info. I always prefer to
avoid any rush. It may be reasonable to wait for 2.8 or maybe we'll decide
to do 2.7.7. As the release is a trigger for activity in the community, it
is always better to prepare releases.

BTW, minor correction: ticket mentioned here as IGNITE-12507
(Persistence files are stored to temp dir) has
actually is https://issues.apache.org/jira/browse/IGNITE-12057 Anyway,
thanks to Anton K. & Dmitriy G., is already in the release branch.

вс, 18 авг. 2019 г. в 06:27, Ivan Pavlukhina :


Zhenya, Dmitriy,


hi Dmitriy, Ivan Pavlukhin suggest to exclude IGNITE-12061 from

2.7.6, i

have no clue - why,

The reason here is a lack of time to ensure that everything is fine
there. The patch is valuable but not so trivial. Honestly, I find it wrong
to merge a changes I am not sure with (yet). Especially in a hurry.

Sent from my iPhone


On 17 Aug 2019, at 13:13, Zhenya Stanilovsky

 wrote:

I hope there is no data loss here, but index tree corruption can be

easily obtained.

Impact: someone believe that inline_size has been changed due to index

recreation but that`s not so.

Hi Evgeniy,

I can't review this change. We need approve of a committer, who is

SQL

expert,  here.

What would be an impact on users if we don' include it into 2.7.6?

Is it a critical/data loss issue? If not, I agree it can wait for 2.8
release.

Sincerely,
Dmitriy Pavlov

сб, 17 авг. 2019 г. в 12:43, Zhenya Stanilovsky :


hi Dmitriy, Ivan Pavlukhin suggest to exclude IGNITE-12061 from

2.7.6, i

have no clue - why, but seems i can`t merge it without his visa.
thanks.


Hi Igniters,

I also suggest adding newly created critical bug into scope
https://issues.apache.org/jira/browse/IGNITE-12081 (already

assigned

since
it was discussed before in private communication).

It is not a regression but can cause data corruption, so I'd

rather wait

for the fix.

Eduard Shangareev, Stanilovsky Evgeny I'm going to assemble the

first RC

during the weekend, so I would be grateful if fixes can be

cherry-piked

to
the branch today. Also, since narrow time limit, please trigger

Run All

after each commit in 2.7.6. This will allow to immediately locate

which

commit caused test failure.

Sincerely,
Dmitriy Pavlov

пт, 16 авг. 2019 г. в 13:33, Dmitriy Pavlov :


Hi Ivan,

yes, sure.

If it is cherry-picked without conflicts, just push it.

  If it contains conflicts it is better to push to 2.7.6-based

branch and

start additional run-all, example
https://github.com/apache/ignite/pull/6781 -it is PR for

ignite-9562,

base: 2.7.6

Sincerely,
Dmitriy Pavlov

пт, 16 авг. 2019 г. в 12:28, Павлухин Иван :


Dmitriy,

We accomplished with

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

Should I cherry-pick it to release branch?

пт,

Re: Why TDE doc says that memory encryption is supported?

[Artem Budnikov]

Guys,

I updated the page.

-Artem

On 02.06.2019 22:20, Nikolay Izhikov wrote:

Hello, Denis.

Ignite doesn't encrypt memory page as long as it retains in memory.
Page encrypted when it is written to the disk.


пт, 31 мая 2019 г. в 19:39, Denis Magda :


Nikolay,

Do we really support encryption for pages in RAM? That's what I found in
the docs:

Ignite uses JDK-provided encryption algorithms: "AES/CBC/PKCS5Padding" for
WAL records encryption and *"AES/CBC/NoPadding" for memory page
encryption.*

Shouldn't we remove the highlighted from the docs?
-
Denis

[jira] [Created] (IGNITE-10868) WAL segments are removed from WAL archive after each checkpoint

[Artem Budnikov (JIRA)]

Artem Budnikov created IGNITE-10868:
---

 Summary: WAL segments are removed from WAL archive after each 
checkpoint
 Key: IGNITE-10868
 URL: https://issues.apache.org/jira/browse/IGNITE-10868
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Artem Budnikov
Assignee: Alexey Goncharuk


The WAL archive is cleaned up after each checkpoint. This does not cause issues 
for end users; however, an empty WAL archive won't help in case of historical 
rebalancing. But our documentation says that it does. Please investigate.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10850) Clarify the use of the enforceJoin flag

[Artem Budnikov (JIRA)]

Artem Budnikov created IGNITE-10850:
---

 Summary: Clarify the use of the enforceJoin flag 
 Key: IGNITE-10850
 URL: https://issues.apache.org/jira/browse/IGNITE-10850
 Project: Ignite
  Issue Type: Task
  Components: documentation
Reporter: Artem Budnikov
Assignee: Artem Budnikov
 Fix For: 2.8


Need to clarify the use of the enforceJoin flag and how it can be used to 
optimize queries. Add this information to 
[https://apacheignite-sql.readme.io/docs/performance-and-debugging]

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10154) Critical worker liveness check configuration is non-trivial and inconsistent

[Artem Budnikov (JIRA)]

Artem Budnikov created IGNITE-10154:
---

 Summary: Critical worker liveness check configuration is 
non-trivial and inconsistent
 Key: IGNITE-10154
 URL: https://issues.apache.org/jira/browse/IGNITE-10154
 Project: Ignite
  Issue Type: Task
Affects Versions: 2.7
Reporter: Artem Budnikov
 Fix For: 2.7


The way the critical thread liveness check is configured has a number of 
usability issues.

1) By default, the liveness check is disabled (i.e. if no failure handler is 
specified in the configuration). However, if you specify any handler (including 
the default one), liveness check gets enabled (which is something the users may 
not want) unless you disable it explicitly.

2) Users that use Ignite 2.6 with a configured failure handler will get this 
check enabled after migrating to Ignite 2.7.

In the two cases above, the functionality changes in a non-trivial. Ideally, we 
need an option that enables this functionality explicitly. A possible example 
would be to keep liveness check disabled until the user sets the 
systemWorkerBlockedTimeout to a positive value. (Or the other way around: 
enable liveness check by default until the user explicitly disables it).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Ignite documentation process

[Artem Budnikov]

Hi Igniters,

Please take a look at the changes in the "How to Contribute" procedure 
[1] related to Ignite documentation. I just reflected there what we 
discussed earlier about our documentation process. Please see this 
thread for more information [2].



[1]: 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-Documentingaticket


[2]: 
apache-ignite-developers.2346864.n4.nabble.com/Re-Documenting-Ignite-tt32746.html



Cheers,
Artem

Re: Documentation: dead links

[Artem Budnikov]

Hi Pavel,

1) I fixed the broken link. Thanks for pointing out.

2) Yes, that is a common problem, and as far as I know, we don't have 
such a check, but we will when we adopt the new docs publishing process 
(markdown-to-html-pulled-from-github-based process).


Cheers,
Artem

On 25.10.2018 16:36, Pavel Kuznetsov wrote:

Hi, dear community,

1) I see dead link on the page 
https://apacheignite-sql.readme.io/docs/jdbc-client-driver


Link "Cross-Cache Query" 
https://apacheignite-sql.readme.io/docs/cache-queries#cross-cache-queries 
points to 404 stub page. Could someone fix that?


2) I see it's a common problem. Do we have CI job that recursively 
checks our doc pages for dead links?


Thanks,

-Pavel

[jira] [Created] (IGNITE-9245) Document how to monitor Ignite with Zabbix

[Artem Budnikov (JIRA)]

Artem Budnikov created IGNITE-9245:
--

 Summary: Document how to monitor Ignite with Zabbix 
 Key: IGNITE-9245
 URL: https://issues.apache.org/jira/browse/IGNITE-9245
 Project: Ignite
  Issue Type: Test
  Components: documentation
Reporter: Artem Budnikov
Assignee: Artem Budnikov


Create a how-to page with an instruction on how to use Zabbix templates to 
monitor Ignite metrics.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Documenting Ignite

[Artem Budnikov]

Hi Dmitry,

I've added a comment to the issue.

My Confluence ID is a.budnikov. Could you please grant me permissions 
required to edit pages. Thanks!



Artem


On 24.07.2018 16:58, Dmitry Pavlov wrote:

I've noticed now INFRA asks for feedback from us.

Artem, will you provide feedback on done change in 
https://issues.apache.org/jira/browse/INFRA-16803


вт, 24 июл. 2018 г. в 11:01, Dmitry Pavlov <mailto:dpavlov@gmail.com>>:


Hi Artem,

This is page in Ignite space, so you could do updates. Of course,
if you have access to Ignite space in wiki. If not, please sign up
and share your wiki login (id).

Sincerely,
Dmitriy Pavlov

вт, 24 июл. 2018 г. в 10:25, Artem Budnikov
mailto:a.budnikov.ign...@gmail.com>>:

Hi everyone,

Despite what I've been told about INFRA, it responded
exceptionally quickly and added the field :-)

I think the page describing the process of creating IGNITE
issues

<https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-TicketCreation>
needs to be updated to reflect the changes related to
documentation process. Could someone do this?

Cheers,

Artem

    On 23.07.2018 18:00, Artem Budnikov wrote:

Hi everyone,

I created an issue in the Apache INFRA project:
https://issues.apache.org/jira/browse/INFRA-16803

Cheers,

Artem


On 19.07.2018 22:58, Dmitry Pavlov wrote:

I appologize, initially I misundersood proposal. I've
concluded that new
doc issue will be created automatically by closing original
ticket, - this
can be done by plugin only.

If we just introduce flag or combobox for indicate doc is
required, there
is no technical issues, it is defenetely possible. So +1
from my side
without concerns.

чт, 19 июл. 2018 г. в 22:02, Denis Magda 
<mailto:dma...@apache.org>:


Ok, if all our doc writers are in the agreement then let's
give a couple of
days to our fellow Igniters to share alternate opinions.

Artem, if you don't hear back by Monday then feel free to
create an INFRA
ticket.

-- 
Denis


On Thu, Jul 19, 2018 at 10:43 AM Prachi Garg
 <mailto:pg...@gridgain.com> wrote:


I totally agree with Denis's point -

"Another benefit of having "Docs Required" flag enabled by
default, is

that

Artem and Prachi can see all such tickets months and weeks
before a
release, figure out details from source code contributors
and complete

the

docs in advance."

On Wed, Jul 18, 2018 at 2:49 PM, Dmitry Pavlov
 <mailto:dpavlov@gmail.com>
wrote:


Yes, I agree. My concern is related only to process
implementation

aspect,

I wonder if it is technically possible.

Generally I like idea of automatic control.

ср, 18 июл. 2018 г. в 23:21, Denis Magda
 <mailto:dma...@apache.org>:


Hi folks,

Artem's proposal might simplify and make our doc tickets
tracking less
error-prone. The current approach implies that a
contributor keeps in

mind

what needs to go to the docs. If he/she has a good
memory, a doc JIRA
counterpart will be created once the contribution is
accepted. But the
practice shows that the memory lets us down :)

Another benefit of having "Docs Required" flag enabled
by default, is

that

Artem and Prachi can see all such tickets months and
weeks before a
release, figure out details from source code
contributors and complete

    the

docs in advance.

-- 
Denis


On Wed, Jul 18, 2018 at 8:39 AM Artem Budnikov <
a.budnikov.ign...@gmail.com
<mailto:a.budnikov.ign...@gmail.com>> wrote:


Dmitry,

The goal I had in mind by proposing that suggestion was
to rectify

the

fact that JIRA issues for documentation are created on
an ad-hoc

basis,

and often issues are created when the lack of
documentation becomes

an

issue for somebody. So we need to be more proactive.

I think manual tracking of issues is possible but as
efficient as the
current situation with the docs. Manual tracking will
have to be

shared

between multiple contributors and performed outside of
JIRA, which

has

its own limitation. If you have any suggestions for
improvement

without

creating f

Re: Documenting Ignite

[Artem Budnikov]

Hi everyone,

Despite what I've been told about INFRA, it responded exceptionally 
quickly and added the field :-)


I think the page describing the process of creating IGNITE issues 
<https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-TicketCreation> 
needs to be updated to reflect the changes related to documentation 
process. Could someone do this?


Cheers,

Artem

On 23.07.2018 18:00, Artem Budnikov wrote:

Hi everyone,

I created an issue in the Apache INFRA project: 
https://issues.apache.org/jira/browse/INFRA-16803


Cheers,

Artem


On 19.07.2018 22:58, Dmitry Pavlov wrote:

I appologize, initially I misundersood proposal. I've concluded that new
doc issue will be created automatically by closing original ticket, - 
this

can be done by plugin only.

If we just introduce flag or combobox for indicate doc is required, 
there

is no technical issues, it is defenetely possible. So +1 from my side
without concerns.

чт, 19 июл. 2018 г. в 22:02, Denis Magda :

Ok, if all our doc writers are in the agreement then let's give a 
couple of

days to our fellow Igniters to share alternate opinions.

Artem, if you don't hear back by Monday then feel free to create an 
INFRA

ticket.

--
Denis

On Thu, Jul 19, 2018 at 10:43 AM Prachi Garg  
wrote:



I totally agree with Denis's point -

"Another benefit of having "Docs Required" flag enabled by default, is

that

Artem and Prachi can see all such tickets months and weeks before a
release, figure out details from source code contributors and complete

the

docs in advance."

On Wed, Jul 18, 2018 at 2:49 PM, Dmitry Pavlov 
wrote:


Yes, I agree. My concern is related only to process implementation

aspect,

I wonder if it is technically possible.

Generally I like idea of automatic control.

ср, 18 июл. 2018 г. в 23:21, Denis Magda :


Hi folks,

Artem's proposal might simplify and make our doc tickets tracking 
less
error-prone. The current approach implies that a contributor 
keeps in

mind
what needs to go to the docs. If he/she has a good memory, a doc 
JIRA
counterpart will be created once the contribution is accepted. 
But the

practice shows that the memory lets us down :)

Another benefit of having "Docs Required" flag enabled by 
default, is

that

Artem and Prachi can see all such tickets months and weeks before a
release, figure out details from source code contributors and 
complete

the

docs in advance.

--
Denis

On Wed, Jul 18, 2018 at 8:39 AM Artem Budnikov <
a.budnikov.ign...@gmail.com> wrote:


Dmitry,

The goal I had in mind by proposing that suggestion was to rectify

the

fact that JIRA issues for documentation are created on an ad-hoc

basis,

and often issues are created when the lack of documentation becomes

an

issue for somebody. So we need to be more proactive.

I think manual tracking of issues is possible but as efficient 
as the

current situation with the docs. Manual tracking will have to be

shared

between multiple contributors and performed outside of JIRA, which

has

its own limitation. If you have any suggestions for improvement

without

creating fields in JIRA, please share your thoughts.

If you are concerned that it's not possible to add a field, then we
should contact Apache Infra and find out.


Best regards,

Artem Budnikov


On 18.07.2018 16:14, Dmitry Pavlov wrote:

Hi Artem,

I sometimes receive feedback that Ignite docs has potential for
improvement, while I found our docs quite intuitive and simple to
understand. So if experienced tech writer will join community it

could

benefit all of us, and users, of course. So you're very welcome to

the

community!

About idea of fields introduction I guess we will need assistance

of

Apache

Infra team, because Ignite shares JIRA with all other Apache

project.

And

I'm not sure that technical implementation of proposed process is

even

possible without plugins. Could we consider some manual processing

of

completed issues in relation to doc requrement?

Sincerely,
Dmitriy Pavlov

ср, 18 июл. 2018 г. в 15:06, Artem Budnikov <

a.budnikov.ign...@gmail.com>:

Hi Igniters,

Being a technical writer, I'm going to contribute to Ignite's
documentation, and I believe documentation is an important 
part of

every

product, especially such a complex product as Apache Ignite.

I'd like to put forward a suggestion on how to increase our

chances

of

making Ignite documentation more comprehensive. The basic idea is

to

have a Jira issue with the Component field set to "Documentation"

for

every feature that needs to be documented. This will ensure that

there

are documentation issues that cover the entire product

functionality.
Then someone can take on an issue and contribute an article on 
the

subject.

This is how I envision it to work technically. A new field

(checkbox)

is

added to the Apache Ignite Jira project.

Re: Documenting Ignite

[Artem Budnikov]

Hi everyone,

I created an issue in the Apache INFRA project: 
https://issues.apache.org/jira/browse/INFRA-16803


Cheers,

Artem


On 19.07.2018 22:58, Dmitry Pavlov wrote:

I appologize, initially I misundersood proposal. I've concluded that new
doc issue will be created automatically by closing original ticket, - this
can be done by plugin only.

If we just introduce flag or combobox for indicate doc is required, there
is no technical issues, it is defenetely possible. So +1 from my side
without concerns.

чт, 19 июл. 2018 г. в 22:02, Denis Magda :


Ok, if all our doc writers are in the agreement then let's give a couple of
days to our fellow Igniters to share alternate opinions.

Artem, if you don't hear back by Monday then feel free to create an INFRA
ticket.

--
Denis

On Thu, Jul 19, 2018 at 10:43 AM Prachi Garg  wrote:


I totally agree with Denis's point -

"Another benefit of having "Docs Required" flag enabled by default, is

that

Artem and Prachi can see all such tickets months and weeks before a
release, figure out details from source code contributors and complete

the

docs in advance."

On Wed, Jul 18, 2018 at 2:49 PM, Dmitry Pavlov 
wrote:


Yes, I agree. My concern is related only to process implementation

aspect,

I wonder if it is technically possible.

Generally I like idea of automatic control.

ср, 18 июл. 2018 г. в 23:21, Denis Magda :


Hi folks,

Artem's proposal might simplify and make our doc tickets tracking less
error-prone. The current approach implies that a contributor keeps in

mind

what needs to go to the docs. If he/she has a good memory, a doc JIRA
counterpart will be created once the contribution is accepted. But the
practice shows that the memory lets us down :)

Another benefit of having "Docs Required" flag enabled by default, is

that

Artem and Prachi can see all such tickets months and weeks before a
release, figure out details from source code contributors and complete

the

docs in advance.

--
Denis

On Wed, Jul 18, 2018 at 8:39 AM Artem Budnikov <
a.budnikov.ign...@gmail.com> wrote:


Dmitry,

The goal I had in mind by proposing that suggestion was to rectify

the

fact that JIRA issues for documentation are created on an ad-hoc

basis,

and often issues are created when the lack of documentation becomes

an

issue for somebody. So we need to be more proactive.

I think manual tracking of issues is possible but as efficient as the
current situation with the docs. Manual tracking will have to be

shared

between multiple contributors and performed outside of JIRA, which

has

its own limitation. If you have any suggestions for improvement

without

creating fields in JIRA, please share your thoughts.

If you are concerned that it's not possible to add a field, then we
should contact Apache Infra and find out.


Best regards,

Artem Budnikov


On 18.07.2018 16:14, Dmitry Pavlov wrote:

Hi Artem,

I sometimes receive feedback that Ignite docs has potential for
improvement, while I found our docs quite intuitive and simple to
understand. So if experienced tech writer will join community it

could

benefit all of us, and users, of course. So you're very welcome to

the

community!

About idea of fields introduction I guess we will need assistance

of

Apache

Infra team, because Ignite shares JIRA with all other Apache

project.

And

I'm not sure that technical implementation of proposed process is

even

possible without plugins. Could we consider some manual processing

of

completed issues in relation to doc requrement?

Sincerely,
Dmitriy Pavlov

ср, 18 июл. 2018 г. в 15:06, Artem Budnikov <

a.budnikov.ign...@gmail.com>:

Hi Igniters,

Being a technical writer, I'm going to contribute to Ignite's
documentation, and I believe documentation is an important part of

every

product, especially such a complex product as Apache Ignite.

I'd like to put forward a suggestion on how to increase our

chances

of

making Ignite documentation more comprehensive. The basic idea is

to

have a Jira issue with the Component field set to "Documentation"

for

every feature that needs to be documented. This will ensure that

there

are documentation issues that cover the entire product

functionality.

Then someone can take on an issue and contribute an article on the

subject.

This is how I envision it to work technically. A new field

(checkbox)

is

added to the Apache Ignite Jira project. The checkbox indicates

that

the

feature requested in this issue needs to be documented. The

checkbox is

selected by default. If the feature does not require

documentation,

then

the author unchecks the checkbox. If it does require

documentation,

the

author creates a related Jira issue selecting "Documentation" in

the

Component field, providing details on what exactly should be

documented.

The field is called "Requires documentation" or simi

Re: Documenting Ignite

[Artem Budnikov]

Dmitry,

The goal I had in mind by proposing that suggestion was to rectify the 
fact that JIRA issues for documentation are created on an ad-hoc basis, 
and often issues are created when the lack of documentation becomes an 
issue for somebody. So we need to be more proactive.


I think manual tracking of issues is possible but as efficient as the 
current situation with the docs. Manual tracking will have to be shared 
between multiple contributors and performed outside of JIRA, which has 
its own limitation. If you have any suggestions for improvement without 
creating fields in JIRA, please share your thoughts.


If you are concerned that it's not possible to add a field, then we 
should contact Apache Infra and find out.



Best regards,

Artem Budnikov


On 18.07.2018 16:14, Dmitry Pavlov wrote:

Hi Artem,

I sometimes receive feedback that Ignite docs has potential for
improvement, while I found our docs quite intuitive and simple to
understand. So if experienced tech writer will join community it could
benefit all of us, and users, of course. So you're very welcome to the
community!

About idea of fields introduction I guess we will need assistance of Apache
Infra team, because Ignite shares JIRA with all other Apache project. And
I'm not sure that technical implementation of proposed process is even
possible without plugins. Could we consider some manual processing of
completed issues in relation to doc requrement?

Sincerely,
Dmitriy Pavlov

ср, 18 июл. 2018 г. в 15:06, Artem Budnikov :


Hi Igniters,

Being a technical writer, I'm going to contribute to Ignite's
documentation, and I believe documentation is an important part of every
product, especially such a complex product as Apache Ignite.

I'd like to put forward a suggestion on how to increase our chances of
making Ignite documentation more comprehensive. The basic idea is to
have a Jira issue with the Component field set to "Documentation" for
every feature that needs to be documented. This will ensure that there
are documentation issues that cover the entire product functionality.
Then someone can take on an issue and contribute an article on the subject.

This is how I envision it to work technically. A new field (checkbox) is
added to the Apache Ignite Jira project. The checkbox indicates that the
feature requested in this issue needs to be documented. The checkbox is
selected by default. If the feature does not require documentation, then
the author unchecks the checkbox. If it does require documentation, the
author creates a related Jira issue selecting "Documentation" in the
Component field, providing details on what exactly should be documented.

The field is called "Requires documentation" or similarly. It could be
also useful to create a new issue type for documentation issues
exclusively.

Once this is done, we'll be able to filter out

  1. issues that do not require documentation,
  2. issues that have related documentation tickets, and
  3. issues that require documentation but have no related issues (which
 means that the author forgot to create a documentation issue for it).


Please share your thoughts about this.


Best regards,

Artem Budnikov

Documenting Ignite

[Artem Budnikov]

Hi Igniters,

Being a technical writer, I'm going to contribute to Ignite's 
documentation, and I believe documentation is an important part of every 
product, especially such a complex product as Apache Ignite.


I'd like to put forward a suggestion on how to increase our chances of 
making Ignite documentation more comprehensive. The basic idea is to 
have a Jira issue with the Component field set to "Documentation" for 
every feature that needs to be documented. This will ensure that there 
are documentation issues that cover the entire product functionality. 
Then someone can take on an issue and contribute an article on the subject.


This is how I envision it to work technically. A new field (checkbox) is 
added to the Apache Ignite Jira project. The checkbox indicates that the 
feature requested in this issue needs to be documented. The checkbox is 
selected by default. If the feature does not require documentation, then 
the author unchecks the checkbox. If it does require documentation, the 
author creates a related Jira issue selecting "Documentation" in the 
Component field, providing details on what exactly should be documented.


The field is called "Requires documentation" or similarly. It could be 
also useful to create a new issue type for documentation issues exclusively.


Once this is done, we'll be able to filter out

1. issues that do not require documentation,
2. issues that have related documentation tickets, and
3. issues that require documentation but have no related issues (which
   means that the author forgot to create a documentation issue for it).


Please share your thoughts about this.


Best regards,

Artem Budnikov