[jira] [Created] (IGNITE-12133) O(log n) partition exchange

[Moti Nisenson-Ken (Jira)]

Moti Nisenson-Ken created IGNITE-12133:
--

 Summary: O(log n) partition exchange
 Key: IGNITE-12133
 URL: https://issues.apache.org/jira/browse/IGNITE-12133
 Project: Ignite
  Issue Type: Improvement
Reporter: Moti Nisenson-Ken


Currently, partition exchange leverages a ring. This means that communications 
is O(n) in number of nodes. It also means that if non-coordinator nodes hang it 
can take much longer to successfully resolve the topology.

Instead, why not use something like a skip-list where the coordinator is first. 
The coordinator can notify the first node at each level of the skip-list. Each 
node then notifies all of its "near-neighbours" in the skip-list, where node B 
is a near-neighbour of node-A, if max-level(nodeB) <= max-level(nodeA), and 
nodeB is the first node at its level when traversing from nodeA in the 
direction of nodeB, skipping over nodes C which have max-level(C) > 
max-level(A). 

1

1 .  .  .3

1        3 . .  . 5

1 . 2 . 3 . 4 . 5 . 6

In the above 1 would notify 2 and 3, 3 would notify 4 and 5, 2 -> 4, and 4 -> 
6, and 5 -> 6.

One can achieve better redundancy by having each node traverse in both 
directions, and having the coordinator also notify the last node in the list at 
each level. This way in the above example if 2 and 3 were both down, 4 would 
still get notified from 5 and 6 (in the backwards direction).

 

The idea is that each individual node has O(log n) nodes to notify - so the 
overall time is reduced. Additionally, we can deal well with at least 1 node 
failure - if one includes the option of processing backwards, 2 consecutive 
node failures can be handled as well. By taking this kind of an approach, then 
the coordinator can basically treat any nodes it didn't receive a message from 
as not-connected, and update the topology as well (disconnecting any nodes that 
it didn't get a notification from). While there are some edge cases here (e.g. 
2 disconnected nodes, then 1 connected node, then 2 disconnected nodes - the 
connected node would be wrongly ejected from the topology), these would 
generally be too rare to need explicit handling for.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Re: Making Ignite Collaboration 100% Open and Transparent

[Pavel Tupitsyn]

Andrey is right, dev list is our primary form of communication, and for
many good reasons.

Other forms of communications are fine, but all discussions/decisions
should be reflected on the dev list in one form or another.
- Had a chat in slack and agreed on something? Write a summary to the dev
list
- Had a meeting? Recording is great, but please post meeting minutes in
text form to the dev list

Thanks,
Pavel

On Fri, Aug 30, 2019 at 11:23 PM Denis Magda  wrote:

> Andrey,
>
> I'm not insisting to replace dev list with Slack or always react to Slack
> messages. It's up to us to decide where and with what frequency to respond.
> My suggestion is just to have Slack as an extra tool for the Ignite dev
> communications (no user support).
>
> I also prefer either email conversations (time to think, no commitments to
> respond ASAP) or phone calls (make things done now). But sometimes Slack
> comes handy. For instance, I'd like to have a faster channel to talk to
> Nikolay Izhikov, Anton Vinogradov or Roman Shtykh on Ignite related tasks
> discussed initially on the dev.
>
>
> -
> Denis
>
>
> On Thu, Aug 29, 2019 at 6:04 AM Andrey Gura  wrote:
>
> > Why chat is called chat? [1] Just ignore modern definitions :) Chat is
> > "bla-bla-bla".
> >
> > IMO, there are no any pros for using Slack in order to make Ignite
> > Collaboration 100% Open and Transparent. Chat is just garbage of some
> > phrases that aren't structured into discussions (please, don't talk me
> > about threads in Slack, they are useless).  So  transparency isn't
> > chat's property. If some topics have parallel discussion we will have
> > as result something like salad "Asynchronous":
> > tomacucumtoes,bersmayonn,aise. Moreover, the same salad we will have
> > for discussion of one topic by many members.
> >
> > Mailing list is the best mean for easygoing interaction. It
> > asynchronous by nature and doesn't have any means for pressure to
> > community members (like notifications). Discussions on mailing list
> > are organized into threads and any new message to the thread will
> > follow up thread to the top of unread messages. All you need and
> > nothing more.
> >
> > Mailing list are indexed by search engines while Slack channels
> > aren't. It is stone in the garden of openтess.
> >
> > I always can refer to discussion on mailing list. But it's impossible
> > for discussion in Slack channel due to reasons mentioned above.
> >
> > I do not mind the idea as a whole. Chat could be nice and fun. But
> > openness, transparency, and also important searchability, it is all
> > about mailing lists, not chats.
> >
> > [1] https://www.merriam-webster.com/dictionary/chat
> >
> > On Thu, Aug 29, 2019 at 12:40 AM Павлухин Иван 
> > wrote:
> > >
> > > + Meeting minutes
> > >
> > > 2019-08-28 22:29 GMT+11:00, Alexey Zinoviev :
> > > > I am totally support the idea with the planned and widely announced
> > Hangout
> > > > meeting between commiters and contributers and posting the link to
> the
> > > > dev-list with the special Topic Name and short agenda. Maybe, the
> > recorded
> > > > video could be added to the YouTube (or to another platform) to share
> > with
> > > > the community members.
> > > >
> > > > пн, 26 авг. 2019 г. в 22:23, Amit Chavan :
> > > >
> > > >> Hi Denis,
> > > >>
> > > >> I really like the initiative for transparency and collaboration. Are
> > > >> there
> > > >> any plans to help get new contributors up to speed with the project
> > where
> > > >> they can contribute effectively? Sometimes it can be intimidating to
> > > >> start
> > > >> on a large project without some help or advice. Maybe assigning a
> > mentor
> > > >> or
> > > >> an existing committer can be useful or some slack channel people can
> > ping
> > > >> on. I am starting new on the project and have picked out newbie
> ticket
> > > >> from
> > > >> the Jira board. As I make myself familiar with the code base maybe
> its
> > > >> good
> > > >> to have some direction on which area should I focus more on etc.
> > > >>
> > > >> Thanks,
> > > >> Amit
> > > >>
> > > >> On Mon, Aug 26, 2019 at 11:54 AM Denis Magda 
> > wrote:
> > > >>
> > > >> > Folks, let me share more details on why Anton started the
> > conversation
> > > >> > about Ignite Slack:
> > > >> >
> > > >> >
> > > >>
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/The-ASF-Slack-td43233.html
> > > >> >
> > > >> > Recently, a group of GridGain and Sberbank committers of Ignite
> has
> > met
> > > >> to
> > > >> > discuss how to make our community more transparent and open. Anton
> > and
> > > >> > I
> > > >> > took part in that meeting. The primary problems we see in regards
> to
> > > >> > transparency and openness are as follows:
> > > >> >
> > > >> >- A lot of discussions on the dev list abrupts suddenly and
> it's
> > > >> unclear
> > > >> >whether a discussion is abandoned or something else is going on
> > in
> > > >> > the
> > > >> >background with a task/bug/improvement. In many c

Re: Making Ignite Collaboration 100% Open and Transparent

[Alexey Zinoviev]

Cool idea about sending summary/meeting records to dev list for each
meaningful communication
Support you, Pavel!

пн, 2 сент. 2019 г. в 12:55, Pavel Tupitsyn :

> Andrey is right, dev list is our primary form of communication, and for
> many good reasons.
>
> Other forms of communications are fine, but all discussions/decisions
> should be reflected on the dev list in one form or another.
> - Had a chat in slack and agreed on something? Write a summary to the dev
> list
> - Had a meeting? Recording is great, but please post meeting minutes in
> text form to the dev list
>
> Thanks,
> Pavel
>
> On Fri, Aug 30, 2019 at 11:23 PM Denis Magda  wrote:
>
> > Andrey,
> >
> > I'm not insisting to replace dev list with Slack or always react to Slack
> > messages. It's up to us to decide where and with what frequency to
> respond.
> > My suggestion is just to have Slack as an extra tool for the Ignite dev
> > communications (no user support).
> >
> > I also prefer either email conversations (time to think, no commitments
> to
> > respond ASAP) or phone calls (make things done now). But sometimes Slack
> > comes handy. For instance, I'd like to have a faster channel to talk to
> > Nikolay Izhikov, Anton Vinogradov or Roman Shtykh on Ignite related tasks
> > discussed initially on the dev.
> >
> >
> > -
> > Denis
> >
> >
> > On Thu, Aug 29, 2019 at 6:04 AM Andrey Gura  wrote:
> >
> > > Why chat is called chat? [1] Just ignore modern definitions :) Chat is
> > > "bla-bla-bla".
> > >
> > > IMO, there are no any pros for using Slack in order to make Ignite
> > > Collaboration 100% Open and Transparent. Chat is just garbage of some
> > > phrases that aren't structured into discussions (please, don't talk me
> > > about threads in Slack, they are useless).  So  transparency isn't
> > > chat's property. If some topics have parallel discussion we will have
> > > as result something like salad "Asynchronous":
> > > tomacucumtoes,bersmayonn,aise. Moreover, the same salad we will have
> > > for discussion of one topic by many members.
> > >
> > > Mailing list is the best mean for easygoing interaction. It
> > > asynchronous by nature and doesn't have any means for pressure to
> > > community members (like notifications). Discussions on mailing list
> > > are organized into threads and any new message to the thread will
> > > follow up thread to the top of unread messages. All you need and
> > > nothing more.
> > >
> > > Mailing list are indexed by search engines while Slack channels
> > > aren't. It is stone in the garden of openтess.
> > >
> > > I always can refer to discussion on mailing list. But it's impossible
> > > for discussion in Slack channel due to reasons mentioned above.
> > >
> > > I do not mind the idea as a whole. Chat could be nice and fun. But
> > > openness, transparency, and also important searchability, it is all
> > > about mailing lists, not chats.
> > >
> > > [1] https://www.merriam-webster.com/dictionary/chat
> > >
> > > On Thu, Aug 29, 2019 at 12:40 AM Павлухин Иван 
> > > wrote:
> > > >
> > > > + Meeting minutes
> > > >
> > > > 2019-08-28 22:29 GMT+11:00, Alexey Zinoviev  >:
> > > > > I am totally support the idea with the planned and widely announced
> > > Hangout
> > > > > meeting between commiters and contributers and posting the link to
> > the
> > > > > dev-list with the special Topic Name and short agenda. Maybe, the
> > > recorded
> > > > > video could be added to the YouTube (or to another platform) to
> share
> > > with
> > > > > the community members.
> > > > >
> > > > > пн, 26 авг. 2019 г. в 22:23, Amit Chavan :
> > > > >
> > > > >> Hi Denis,
> > > > >>
> > > > >> I really like the initiative for transparency and collaboration.
> Are
> > > > >> there
> > > > >> any plans to help get new contributors up to speed with the
> project
> > > where
> > > > >> they can contribute effectively? Sometimes it can be intimidating
> to
> > > > >> start
> > > > >> on a large project without some help or advice. Maybe assigning a
> > > mentor
> > > > >> or
> > > > >> an existing committer can be useful or some slack channel people
> can
> > > ping
> > > > >> on. I am starting new on the project and have picked out newbie
> > ticket
> > > > >> from
> > > > >> the Jira board. As I make myself familiar with the code base maybe
> > its
> > > > >> good
> > > > >> to have some direction on which area should I focus more on etc.
> > > > >>
> > > > >> Thanks,
> > > > >> Amit
> > > > >>
> > > > >> On Mon, Aug 26, 2019 at 11:54 AM Denis Magda 
> > > wrote:
> > > > >>
> > > > >> > Folks, let me share more details on why Anton started the
> > > conversation
> > > > >> > about Ignite Slack:
> > > > >> >
> > > > >> >
> > > > >>
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/The-ASF-Slack-td43233.html
> > > > >> >
> > > > >> > Recently, a group of GridGain and Sberbank committers of Ignite
> > has
> > > met
> > > > >> to
> > > > >> > discuss how to make our community more transparent and open.
> Anton

Re: Making Ignite Collaboration 100% Open and Transparent

[Anton Vinogradov]

Folks,

ASF Slack is just a private messenger.
For me, it's a way to have a conversation with any contributor joined
#ignite channel.
Of-course, conversation results should be published at Jira/devlist.

On Mon, Sep 2, 2019 at 1:11 PM Alexey Zinoviev 
wrote:

> Cool idea about sending summary/meeting records to dev list for each
> meaningful communication
> Support you, Pavel!
>
> пн, 2 сент. 2019 г. в 12:55, Pavel Tupitsyn :
>
> > Andrey is right, dev list is our primary form of communication, and for
> > many good reasons.
> >
> > Other forms of communications are fine, but all discussions/decisions
> > should be reflected on the dev list in one form or another.
> > - Had a chat in slack and agreed on something? Write a summary to the dev
> > list
> > - Had a meeting? Recording is great, but please post meeting minutes in
> > text form to the dev list
> >
> > Thanks,
> > Pavel
> >
> > On Fri, Aug 30, 2019 at 11:23 PM Denis Magda  wrote:
> >
> > > Andrey,
> > >
> > > I'm not insisting to replace dev list with Slack or always react to
> Slack
> > > messages. It's up to us to decide where and with what frequency to
> > respond.
> > > My suggestion is just to have Slack as an extra tool for the Ignite dev
> > > communications (no user support).
> > >
> > > I also prefer either email conversations (time to think, no commitments
> > to
> > > respond ASAP) or phone calls (make things done now). But sometimes
> Slack
> > > comes handy. For instance, I'd like to have a faster channel to talk to
> > > Nikolay Izhikov, Anton Vinogradov or Roman Shtykh on Ignite related
> tasks
> > > discussed initially on the dev.
> > >
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Thu, Aug 29, 2019 at 6:04 AM Andrey Gura  wrote:
> > >
> > > > Why chat is called chat? [1] Just ignore modern definitions :) Chat
> is
> > > > "bla-bla-bla".
> > > >
> > > > IMO, there are no any pros for using Slack in order to make Ignite
> > > > Collaboration 100% Open and Transparent. Chat is just garbage of some
> > > > phrases that aren't structured into discussions (please, don't talk
> me
> > > > about threads in Slack, they are useless).  So  transparency isn't
> > > > chat's property. If some topics have parallel discussion we will have
> > > > as result something like salad "Asynchronous":
> > > > tomacucumtoes,bersmayonn,aise. Moreover, the same salad we will have
> > > > for discussion of one topic by many members.
> > > >
> > > > Mailing list is the best mean for easygoing interaction. It
> > > > asynchronous by nature and doesn't have any means for pressure to
> > > > community members (like notifications). Discussions on mailing list
> > > > are organized into threads and any new message to the thread will
> > > > follow up thread to the top of unread messages. All you need and
> > > > nothing more.
> > > >
> > > > Mailing list are indexed by search engines while Slack channels
> > > > aren't. It is stone in the garden of openтess.
> > > >
> > > > I always can refer to discussion on mailing list. But it's impossible
> > > > for discussion in Slack channel due to reasons mentioned above.
> > > >
> > > > I do not mind the idea as a whole. Chat could be nice and fun. But
> > > > openness, transparency, and also important searchability, it is all
> > > > about mailing lists, not chats.
> > > >
> > > > [1] https://www.merriam-webster.com/dictionary/chat
> > > >
> > > > On Thu, Aug 29, 2019 at 12:40 AM Павлухин Иван 
> > > > wrote:
> > > > >
> > > > > + Meeting minutes
> > > > >
> > > > > 2019-08-28 22:29 GMT+11:00, Alexey Zinoviev <
> zaleslaw@gmail.com
> > >:
> > > > > > I am totally support the idea with the planned and widely
> announced
> > > > Hangout
> > > > > > meeting between commiters and contributers and posting the link
> to
> > > the
> > > > > > dev-list with the special Topic Name and short agenda. Maybe, the
> > > > recorded
> > > > > > video could be added to the YouTube (or to another platform) to
> > share
> > > > with
> > > > > > the community members.
> > > > > >
> > > > > > пн, 26 авг. 2019 г. в 22:23, Amit Chavan :
> > > > > >
> > > > > >> Hi Denis,
> > > > > >>
> > > > > >> I really like the initiative for transparency and collaboration.
> > Are
> > > > > >> there
> > > > > >> any plans to help get new contributors up to speed with the
> > project
> > > > where
> > > > > >> they can contribute effectively? Sometimes it can be
> intimidating
> > to
> > > > > >> start
> > > > > >> on a large project without some help or advice. Maybe assigning
> a
> > > > mentor
> > > > > >> or
> > > > > >> an existing committer can be useful or some slack channel people
> > can
> > > > ping
> > > > > >> on. I am starting new on the project and have picked out newbie
> > > ticket
> > > > > >> from
> > > > > >> the Jira board. As I make myself familiar with the code base
> maybe
> > > its
> > > > > >> good
> > > > > >> to have some direction on which area should I focus more on etc.
> > > > > >>
> > > > > >> Thanks,
> > > > > >> Amit
>

Re: Replacing default work dir from tmp to current dir

[Ilya Kasnacheev]

Hello!

I have pushed an amended fix to both master and ignite-2.7.6.

Regards,
-- 
Ilya Kasnacheev


пт, 30 авг. 2019 г. в 21:48, Denis Magda :

> Ilya,
>
> I forgot to push "Send for review" button. You can see my minor comment
> now.
>
> -
> Denis
>
>
> On Fri, Aug 30, 2019 at 5:47 AM Ilya Kasnacheev  >
> wrote:
>
> > Hello!
> >
> > Waiting for a minor comment from Denis, as soon as I see/fix it I'm going
> > to commit.
> >
> > Regards,
> > Ilya.
> > --
> > Ilya Kasnacheev
> >
> >
> > пт, 30 авг. 2019 г. в 11:30, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > >:
> >
> > > Hello Ilya,
> > >
> > > Just curious, when are you planning to commit your changes to the 2.7.6
> > > branch?
> > >
> > > ср, 28 авг. 2019 г. в 04:57, Denis Magda :
> > >
> > > > Ok, seems like we came to a consensus. Let’s ensure that the path for
> > our
> > > > work dir is user.dir/ignite/work and restart the vote.
> > > >
> > > > Denis
> > > >
> > > > On Tuesday, August 27, 2019, Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hello!
> > > > >
> > > > > I have took the liberty to implement the change to existing code
> base
> > > to
> > > > > remove concern about work/ directory:
> > > > >
> > > > > https://github.com/apache/ignite/pull/6816/files
> > > > >
> > > > > Some advocacy for this patch:
> > > > > - Minimal change.
> > > > > - Storing in user.dir/ignite/work (current directory, e.g. project
> > > root)
> > > > > which is consistent with behavior of unzipped binary release.
> > > > > - We can re-use user.dir/ignite for other uses in the future, such
> as
> > > > > storing logs there.
> > > > >
> > > > > I have to admit that my previous reaction to the change was too
> > strong.
> > > > It
> > > > > turned out the default was user.dir/work (project root) and not
> > > > > user.home/work (home dir with imminent Work collision).
> > > > > Nevertheless, I think that after this change it would be good
> enough
> > to
> > > > > last for a few years.
> > > > >
> > > > > What do you think?
> > > > >
> > > > > Regards,
> > > > > --
> > > > > Ilya Kasnacheev
> > > > >
> > > > >
> > > > > вт, 27 авг. 2019 г. в 18:28, Alexey Goncharuk <
> > > > alexey.goncha...@gmail.com
> > > > > >:
> > > > >
> > > > > > In the current state of the project, we cannot directly compare
> > > Ignite
> > > > > > setup process to the one of postgresql or another database. In
> many
> > > > > Ignite
> > > > > > examples, an embedded node (even with persistence) is started and
> > it
> > > is
> > > > > > supposed to run without any additional FS rights grants or init
> > > steps.
> > > > > This
> > > > > > may be changed in 3.0, but not in a maintenance release. If we
> are
> > to
> > > > > > change the directory to /var/lib, I would rather fail Ignite node
> > > start
> > > > > > asking a user to explicitly provide work directory path. Let
> alone
> > > > > /var/lib
> > > > > > is not portable and I would not add an OS-switch to the code for
> no
> > > > > reason.
> > > > > >
> > > > > > I vote for storing the work in ~/ignite/work - agree with Ilya
> that
> > > > > writing
> > > > > > large amounts of data in a hidden folder is a bad idea.
> > > > > >
> > > > > > вт, 27 авг. 2019 г. в 15:17, Dmitriy Pavlov  >:
> > > > > >
> > > > > > > Hi Igniters,
> > > > > > >
> > > > > > > I agree that user home maybe not the best place from Linux
> > > > perspective
> > > > > > and
> > > > > > > philosophy, but  "user.home"/ignite/work  is more or less
> > portable.
> > > > > > >
> > > > > > > For the Linux environment, we can add a suggestion about where
> to
> > > > place
> > > > > > > persisted data. For very first testing of Apache Ignite user
> home
> > > > still
> > > > > > > looks good for me.
> > > > > > >
> > > > > > > Sincerely,
> > > > > > > Dmitriy Pavlov
> > > > > > >
> > > > > > > вт, 27 авг. 2019 г. в 11:56, Pavel Pereslegin <
> xxt...@gmail.com
> > >:
> > > > > > >
> > > > > > > > Or instead of a WARNING, we can add a suggestion with a
> > > > > recommendation
> > > > > > > > for the production environment.
> > > > > > > >
> > > > > > > > вт, 27 авг. 2019 г. в 11:41, Petr Ivanov <
> mr.wei...@gmail.com
> > >:
> > > > > > > > >
> > > > > > > > > /opt is either does not exist on fresh system, or has the
> > same
> > > > > > > > restriction: no user access without admin intervention.
> > > > > > > > > /usr/local, /var/lib, etc. — all this is implemented in our
> > > DEB /
> > > > > RPM
> > > > > > > > packages already.
> > > > > > > > >
> > > > > > > > > For ZIP installation %HOME% seems to be the best approach
> for
> > > > > > "2-click"
> > > > > > > > launch.
> > > > > > > > > Later user can update preferences and set working dir to
> > > whatever
> > > > > > > > directory he would like.
> > > > > > > > >
> > > > > > > > > Also — we can put WARNING message to log noting that
> WORK_DIR
> > > is
> > > > > set
> > > > > > to
> > > > > > > > default.
> > > > > > > > >
> > > > > > > > > > On 27 Aug 2019, at 10:16, Zhen

[jira] [Created] (IGNITE-12134) Document default Ignite work dir location

[Ilya Kasnacheev (Jira)]

Ilya Kasnacheev created IGNITE-12134:


 Summary: Document default Ignite work dir location
 Key: IGNITE-12134
 URL: https://issues.apache.org/jira/browse/IGNITE-12134
 Project: Ignite
  Issue Type: Improvement
  Components: documentation
Reporter: Ilya Kasnacheev
 Fix For: 2.7.6


What should be documented:
Contents and significance of work dir - db, marshaller, wal.
Default for cases when there is IGNITE_HOME (such as running from binary 
distribution)
Default for cases when there's no IGNITE_HOME (running Ignite as library)
Changing default
logs/ that sometimes comes alongside work/



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Re: Replacing default work dir from tmp to current dir

[Ilya Kasnacheev]

Hello again!

Please note that I have updated release notes for IGNITE-12057 as well as
added them for my ticket. Release Engineers, please make sure you include
the latest one.

Regards,
-- 
Ilya Kasnacheev


пн, 2 сент. 2019 г. в 13:33, Ilya Kasnacheev :

> Hello!
>
> I have pushed an amended fix to both master and ignite-2.7.6.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пт, 30 авг. 2019 г. в 21:48, Denis Magda :
>
>> Ilya,
>>
>> I forgot to push "Send for review" button. You can see my minor comment
>> now.
>>
>> -
>> Denis
>>
>>
>> On Fri, Aug 30, 2019 at 5:47 AM Ilya Kasnacheev <
>> ilya.kasnach...@gmail.com>
>> wrote:
>>
>> > Hello!
>> >
>> > Waiting for a minor comment from Denis, as soon as I see/fix it I'm
>> going
>> > to commit.
>> >
>> > Regards,
>> > Ilya.
>> > --
>> > Ilya Kasnacheev
>> >
>> >
>> > пт, 30 авг. 2019 г. в 11:30, Alexey Goncharuk <
>> alexey.goncha...@gmail.com
>> > >:
>> >
>> > > Hello Ilya,
>> > >
>> > > Just curious, when are you planning to commit your changes to the
>> 2.7.6
>> > > branch?
>> > >
>> > > ср, 28 авг. 2019 г. в 04:57, Denis Magda :
>> > >
>> > > > Ok, seems like we came to a consensus. Let’s ensure that the path
>> for
>> > our
>> > > > work dir is user.dir/ignite/work and restart the vote.
>> > > >
>> > > > Denis
>> > > >
>> > > > On Tuesday, August 27, 2019, Ilya Kasnacheev <
>> > ilya.kasnach...@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > Hello!
>> > > > >
>> > > > > I have took the liberty to implement the change to existing code
>> base
>> > > to
>> > > > > remove concern about work/ directory:
>> > > > >
>> > > > > https://github.com/apache/ignite/pull/6816/files
>> > > > >
>> > > > > Some advocacy for this patch:
>> > > > > - Minimal change.
>> > > > > - Storing in user.dir/ignite/work (current directory, e.g. project
>> > > root)
>> > > > > which is consistent with behavior of unzipped binary release.
>> > > > > - We can re-use user.dir/ignite for other uses in the future,
>> such as
>> > > > > storing logs there.
>> > > > >
>> > > > > I have to admit that my previous reaction to the change was too
>> > strong.
>> > > > It
>> > > > > turned out the default was user.dir/work (project root) and not
>> > > > > user.home/work (home dir with imminent Work collision).
>> > > > > Nevertheless, I think that after this change it would be good
>> enough
>> > to
>> > > > > last for a few years.
>> > > > >
>> > > > > What do you think?
>> > > > >
>> > > > > Regards,
>> > > > > --
>> > > > > Ilya Kasnacheev
>> > > > >
>> > > > >
>> > > > > вт, 27 авг. 2019 г. в 18:28, Alexey Goncharuk <
>> > > > alexey.goncha...@gmail.com
>> > > > > >:
>> > > > >
>> > > > > > In the current state of the project, we cannot directly compare
>> > > Ignite
>> > > > > > setup process to the one of postgresql or another database. In
>> many
>> > > > > Ignite
>> > > > > > examples, an embedded node (even with persistence) is started
>> and
>> > it
>> > > is
>> > > > > > supposed to run without any additional FS rights grants or init
>> > > steps.
>> > > > > This
>> > > > > > may be changed in 3.0, but not in a maintenance release. If we
>> are
>> > to
>> > > > > > change the directory to /var/lib, I would rather fail Ignite
>> node
>> > > start
>> > > > > > asking a user to explicitly provide work directory path. Let
>> alone
>> > > > > /var/lib
>> > > > > > is not portable and I would not add an OS-switch to the code
>> for no
>> > > > > reason.
>> > > > > >
>> > > > > > I vote for storing the work in ~/ignite/work - agree with Ilya
>> that
>> > > > > writing
>> > > > > > large amounts of data in a hidden folder is a bad idea.
>> > > > > >
>> > > > > > вт, 27 авг. 2019 г. в 15:17, Dmitriy Pavlov > >:
>> > > > > >
>> > > > > > > Hi Igniters,
>> > > > > > >
>> > > > > > > I agree that user home maybe not the best place from Linux
>> > > > perspective
>> > > > > > and
>> > > > > > > philosophy, but  "user.home"/ignite/work  is more or less
>> > portable.
>> > > > > > >
>> > > > > > > For the Linux environment, we can add a suggestion about
>> where to
>> > > > place
>> > > > > > > persisted data. For very first testing of Apache Ignite user
>> home
>> > > > still
>> > > > > > > looks good for me.
>> > > > > > >
>> > > > > > > Sincerely,
>> > > > > > > Dmitriy Pavlov
>> > > > > > >
>> > > > > > > вт, 27 авг. 2019 г. в 11:56, Pavel Pereslegin <
>> xxt...@gmail.com
>> > >:
>> > > > > > >
>> > > > > > > > Or instead of a WARNING, we can add a suggestion with a
>> > > > > recommendation
>> > > > > > > > for the production environment.
>> > > > > > > >
>> > > > > > > > вт, 27 авг. 2019 г. в 11:41, Petr Ivanov <
>> mr.wei...@gmail.com
>> > >:
>> > > > > > > > >
>> > > > > > > > > /opt is either does not exist on fresh system, or has the
>> > same
>> > > > > > > > restriction: no user access without admin intervention.
>> > > > > > > > > /usr/local, /var/lib, etc. — all this is implemented in
>> our
>> > > DEB /
>> > > > > RPM
>> > > > > > > > packages already.
>> > > > > > > > >
>> > > > > > > >

[jira] [Created] (IGNITE-12135) Rework GridCommandHandlerTest

[Kirill Tkalenko (Jira)]

Kirill Tkalenko created IGNITE-12135:


 Summary: Rework GridCommandHandlerTest
 Key: IGNITE-12135
 URL: https://issues.apache.org/jira/browse/IGNITE-12135
 Project: Ignite
  Issue Type: Improvement
Reporter: Kirill Tkalenko
Assignee: Kirill Tkalenko
 Fix For: 2.8


There are 50+ tests. In each test we are start and stop nodes. I think we could 
split tests at least to two groups:
 # Tests on normal behaviour. We could start nodes before all tests and stop 
them after all tests.
 # Tests required start new cluster before each test.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Re: Re[2]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

[Alexey Goncharuk]

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 :

> 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 :
>> > >
>> > > > 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, for example
>> > > > >
>> > > > > ср, 28 авг. 2019 г. в 14:57, Nikolay Izhikov > >:
>> > > > >
>> > > > > > Hello, Alexey.
>> > > > > >
>> > > > > > > But the
>> > > > > > > compatibility with Spark 2.3 will be broken, isn't it?
>> > > > > >
>> > > > > > Yes.
>> > > > > >
>> > > > > > > Do you have any
>> > > > > > > plans to support the different version of Spark without
>> loosing
>> > > your
>> > > > > >
>> > > > > > unique
>> > > > > > > expertise in Spark-Ignite integration?
>> > > > > >
>> > > > > > What do you mean by "my unique expertise"? :)
>> > > > > >
>> > > > > > How do you see support of several Spark version?
>> > > > > >
>> > > > > >
>> > > > > > В Ср, 28/08/2019 в 14:29 +0300, Alexey Zinoviev пишет:
>> > > > > > > Dear Nikolay Izhikov
>> > > > > > > Are you going to update the Ignite-Spark integration for
>> Spark 2.4.
>> > > > But
>> > > > > >
>> > > > > > the
>> > > > > > > compatibility with Spark 2.3 will be broken, isn't it? Do you
>> have
>> > > > any
>> > > > > > > plans to support the different version of Spark without
>> loosing
>> > > your
>> > > > > >
>> > > > > > unique
>> > > > > > > expertise in Spark-Ignite integration?
>> > > > > > >
>> > > > > > > чт, 15 авг. 2019 г. в 14:54, Nikolay Izhikov <
>> nizhi...@apache.org
>> > > >:
>> > > > > > >
>> > > > > > > > Hello, Igniters.
>> > > > > > > >
>> > > > > > > > I try to upgrade Spark version but failed.
>> > > > > > > >
>> > > > > > > > Seems, internal Spark API(External Catalog, SQL planner)
>> that we
>> > > > use
>> > > > > > > > changed a lot.
>> > > > > > > > So it will take some time to upgrade version.
>> > > > > > > >
>> > > > > > > > For now, I work hard to complete the second phase of IEP-35
>> so I
>> > > > > >
>> > > > > > postpone
>> > > > > > > > upgrade Spark version to Ignite 2.8.
>> > > > > > > >
>> > > > > > > > В Чт, 15/08/2019 в 14:51 +0300, Dmitriy Pavlov пишет:
>> > > > > > > > > Hi Denis,
>> > > > > > > > >
>> > > > > > > > > Sure, since code freeze is planned for today, I don't
>> mind to
>> > > > include
>> > > > > > > >
>> > > > > > > > this
>> > > > > > > > > bug.
>> > > > > > > > >
>> > > > > > > > > Ivan, could you complete this issue by 20 August?
>> > > > > > > > >
>> > > > > > > > > BTW #1, Dmitriy Govoruchnin, please reply about commit for
>> > > > > > > > >
>> > > https://issues.apache.org/jira/browse/IGNITE-11953?src=confmacro
>> > > > > > > > >
>> > > > > > > > > BTW #2, FYI, release 

[jira] [Created] (IGNITE-12136) Test ClusterReadOnlyModeTest is flaky.

[Sergey Antonov (Jira)]

Sergey Antonov created IGNITE-12136:
---

 Summary: Test ClusterReadOnlyModeTest is flaky.
 Key: IGNITE-12136
 URL: https://issues.apache.org/jira/browse/IGNITE-12136
 Project: Ignite
  Issue Type: Bug
Reporter: Sergey Antonov
Assignee: Sergey Antonov
 Fix For: 2.8


https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=4535823271211432266&tab=testDetails&branch_IgniteTests24Java8=%3Cdefault%3E



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Re: IGNITE-12018 Web Agent docker image: 'functions.sh' not found

[Saikat Maitra]

Hi Andrey,

Thank you for review and approving my request.

As discussed I also validated the apache-ignite docker image and I am
getting different error as mentioned below.

Step 5/11 : COPY apache-ignite* apache-ignite
COPY failed: no source files were specified

I will look into apache-ignite docker image issue further.

Regards
Saikat

On Sun, Sep 1, 2019 at 9:32 PM Andrey Novikov  wrote:

> Looks like same logic is used for apache-ignite docker image. I approved
> your PR
>
>
> On Mon, Sep 2, 2019 at 3:22 AM Saikat Maitra 
> wrote:
> >
> > Hi,
> >
> > This is a tiny PR. Please take a look and let me know if it is ok to
> merge.
> >
> > I have validated the results locally and it is working as expected.
> >
> > Regards,
> > Saikat
> >
> > On Sun, Aug 25, 2019 at 3:24 PM Saikat Maitra 
> > wrote:
> >
> > > Hello,
> > >
> > > I have raised PR for the following issue
> > >
> > > IGNITE-12018 Web Agent docker image: 'functions.sh' not found
> > >
> > > Jira issue : https://issues.apache.org/jira/browse/IGNITE-12018
> > >
> > > PR : https://github.com/apache/ignite/pull/6808
> > >
> > > Please review and share feedback.
> > >
> > > Regards,
> > > Saikat
> > >
> > >
> > >
>

Re: Contribute to ticket IGNITE-11894

[Amit Chavan]

Hi Denis,

I still can't assign the ticket to myself.

-Amit

On Fri, Aug 30, 2019 at 7:52 PM Denis Magda  wrote:

> Amit, done, go ahead and assign the ticket.
>
> -
> Denis
>
>
> On Fri, Aug 30, 2019 at 2:42 PM Amit Chavan  wrote:
>
> > My jira ID is amitvc.
> >
> > -Amit
> >
> > On Fri, Aug 30, 2019 at 1:08 PM Denis Magda  wrote:
> >
> > > Amit,
> > >
> > > Please share your JIRA id. Will add you to JIRA's contributors' list
> and
> > > you will be able to take over this ticket.
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Thu, Aug 29, 2019 at 2:55 PM Amit Chavan 
> wrote:
> > >
> > > > Hello,
> > > >
> > > > I joined the Ignite community last week and I want to start
> > > contributing. I
> > > > would like to start with this ticket - IGNITE-11894
> > > > . Can someone
> > please
> > > > assign me the ticket?
> > > >
> > > > Thanks,
> > > > Amit
> > > >
> > >
> >
>