[jira] [Created] (IGNITE-7555) Create documentation for using Ignite Persistence on Kubernetes

[Evgenii Zhuravlev (JIRA)]

Evgenii Zhuravlev created IGNITE-7555:
-

 Summary: Create documentation for using Ignite Persistence on 
Kubernetes
 Key: IGNITE-7555
 URL: https://issues.apache.org/jira/browse/IGNITE-7555
 Project: Ignite
  Issue Type: Task
  Components: documentation
Reporter: Evgenii Zhuravlev
 Fix For: 2.5






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3445: IGNITE-6113 Async eviction

[Jokser]

GitHub user Jokser opened a pull request:

https://github.com/apache/ignite/pull/3445

IGNITE-6113 Async eviction



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-6113

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3445.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3445


commit 2890c096f072b1f3a6a81e653bf1b4742f34b34c
Author: ilantukh 
Date:   2018-01-24T14:09:32Z

gg-12001 : Rebalance mechanics redesign.

commit 7063a41c18749a4a206e84eda8c1a775dee055f4
Author: Pavel Kovalenko 
Date:   2018-01-29T09:17:25Z

WIP




---

[GitHub] ignite pull request #3446: IGNITE-7534 ClusterGroupExample duplicate

[vveider]

GitHub user vveider opened a pull request:

https://github.com/apache/ignite/pull/3446

IGNITE-7534 ClusterGroupExample duplicate

 * removed 
examples/src/main/java/org/apache/ignite/examples/computegrid/cluster

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-7534

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3446.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3446


commit 857b1f317f852cc1a4c5e60ed07973dc10ec21a4
Author: Ivanov Petr 
Date:   2018-01-29T09:45:32Z

IGNITE-7534 ClusterGroupExample duplicate
 * removed 
examples/src/main/java/org/apache/ignite/examples/computegrid/cluster




---

[jira] [Created] (IGNITE-7556) Docs should feature specifying SQL key more prominently

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-7556:
---

 Summary: Docs should feature specifying SQL key more prominently
 Key: IGNITE-7556
 URL: https://issues.apache.org/jira/browse/IGNITE-7556
 Project: Ignite
  Issue Type: Bug
  Components: documentation
Reporter: Ilya Kasnacheev


Descriptions on [https://apacheignite-sql.readme.io/docs/schema-and-indexes] 
are not DML-friendly
After reading this page and [https://apacheignite-sql.readme.io/docs/insert], 
one would likely still unable to write working INSERT because there won't be 
primary key in it.

Their only chance is to spot _key reference in infoblock, or infer usability of 
setKeyFields() with single key type. Both are unlikely, leading to questions 
such as 
[https://stackoverflow.com/questions/48460214/how-do-i-read-data-from-ignite-kv-storage-using-jdbc]
 see {{Key is missing from query}}

Such problems are hard to debug. They can be avoided if all examples of 
QueryEntities in docs will contain setKeyFields, and INSERT docs page will 
refer to _key field.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: SSL for ODBC connection

[Igor Sapego]

Denis,

For example, there are often such options as "verify-ca" and "verify-full".
[1-3]
Moreover, this approach seems more consistent with other solutions and thus
more familiar to user.

[1] - https://www.postgresql.org/docs/9.1/static/libpq-ssl.html
[2] -
https://docs.oracle.com/cd/E17952_01/connector-odbc-en/connector-odbc-configuration-connection-parameters.html
[3] -
https://dev.mysql.com/doc/connector-odbc/en/connector-odbc-configuration-connection-parameters.html

Best Regards,
Igor

On Sat, Jan 27, 2018 at 2:22 AM, Denis Magda  wrote:

> Igor,
>
> Why it might be not enough to have ssl_enabled=[true | false]? Could you
> give an example since you’ve already did a research?
>
> —
> Denis
>
> > On Jan 26, 2018, at 6:08 AM, Igor Sapego  wrote:
> >
> > Guys,
> >
> > The SSL for the ODBC is pretty much ready and working, so
> > here is update on the current state I want to share with you.
> > And of course, I'd like to to hear your opinion on this one.
> >
> > First of all, I've checked some discussions about the ssl_mode
> > approaches in different ODBC drivers and it seems to me that
> > there is a big chance that simple ssl_enabled=[true|false]
> > approach is not going to be enough for our users.
> >
> > So I propose a compromise for now. The compromise is to use
> > ssl_mode=[require|disable] parameter right now, which is pretty
> > much as easy to understand as ssl_enabled=[true|false], but
> > leaves us a possibility to add other modes in future if we need
> > them.
> >
> > So the full set of SSL parameters now is the following:
> > ssl_mode=[require|disable]
> > ssl_key_file=
> > ssl_cert_file=
> > ssl_ca_file=
> >
> > Thoughts?
> >
> > Best Regards,
> > Igor
> >
> > On Tue, Nov 21, 2017 at 2:01 AM, Denis Magda  wrote:
> >
> >> This configuration approach looks clearer to me. +1 for it.
> >>
> >> —
> >> Denis
> >>
> >>> On Nov 20, 2017, at 12:42 AM, Igor Sapego  wrote:
> >>>
> >>> Ok, then how about the following set of options:
> >>>
> >>> ssl_enabled=[true|false]
> >>> ssl_key_file=
> >>> ssl_cert_file=
> >>>
> >>>
> >>> Best Regards,
> >>> Igor
> >>>
> >>> On Tue, Nov 14, 2017 at 5:21 PM, Vladimir Ozerov  >
> >>> wrote:
> >>>
>  I think it would be enough to have a single switch for now.
> 
>  On Tue, Nov 7, 2017 at 10:04 PM, Denis Magda 
> wrote:
> 
> > Igor,
> >
> > Thanks for the clarification. Please file a ticket if nobody else
> >> shares
>  a
> > feedback soon.
> >
> > —
> > Denis
> >
> >> On Nov 7, 2017, at 1:23 AM, Igor Sapego  wrote:
> >>
> >> Hi Denis,
> >>
> >>> Could you explain the difference between “allow, prefer and
> require”
> >> modes?
> >> allow - Client will first try connecting without SSL, and then
> >> fallback
> > to
> >> SSL if it is not allowed to connect without SSL;
> >> prefer - Client will first try connecting using SSL, and then
> fallback
>  to
> >> non-SSL if SSL is not supported by the server;
> >> disable - Client will only connect using SSL and return error if
> >> failed
> > to
> >> successfully do so.
> >>
> >>> BTW, do we really need to have the “disable” one? Guess that having
> >> ssl_mode set to “disable” will have the same effect as not setting
> the
> >> ssl_mode at all.
> >> This is the matter of the default value of the ssl_mode option. The
> >> way
> > you
> >> propose it means that you still has "disable" option, it is just is
> >> not
> >> explicit.
> >>
> >> Best Regards,
> >> Igor
> >>
> >> On Fri, Nov 3, 2017 at 10:35 PM, Denis Magda 
>  wrote:
> >>
> >>> Hi Igor,
> >>>
> >>> Could you explain the difference between “allow, prefer and
> require”
> > modes?
> >>>
> >>> BTW, do we really need to have the “disable” one? Guess that having
> >>> ssl_mode set to “disable” will have the same effect as not setting
> >> the
> >>> ssl_mode at all.
> >>>
> >>> —
> >>> Denis
> >>>
>  On Nov 3, 2017, at 9:04 AM, Igor Sapego 
> wrote:
> 
>  Hi, Igniters,
> 
>  I'm going to start working on the SSL support for the ODBC
>  connection and I need to hear your opinion.
> 
>  For the client side I'm going to use OpenSSL library [1], which is
>  standard de-facto for C/C++ applications. Unfortunately its
>  licence is not fully compatible with Apache Licence, so its going
>  to require from users to install OpenSSL themselves.
> 
>  For the driver I'm going to add following options to connection
>  string:
>  ssl_mode - Determines whether or with what priority a SSL
>  connection will be negotiated with the server. Options
>  here are disable, allow, prefer, require.
>  ssl_key_file - Path to the location for the secret key used for
> the
>  client certificate.
>  ssl_cert_file - Path 

Re: SSL for ODBC connection

[Pavel Tupitsyn]

Agree with Igor, we should be able to configure verification in future, and
this approach seems to be widely used.


On Mon, Jan 29, 2018 at 2:50 PM, Igor Sapego  wrote:

> Denis,
>
> For example, there are often such options as "verify-ca" and "verify-full".
> [1-3]
> Moreover, this approach seems more consistent with other solutions and thus
> more familiar to user.
>
> [1] - https://www.postgresql.org/docs/9.1/static/libpq-ssl.html
> [2] -
> https://docs.oracle.com/cd/E17952_01/connector-odbc-en/
> connector-odbc-configuration-connection-parameters.html
> [3] -
> https://dev.mysql.com/doc/connector-odbc/en/connector-
> odbc-configuration-connection-parameters.html
>
> Best Regards,
> Igor
>
> On Sat, Jan 27, 2018 at 2:22 AM, Denis Magda  wrote:
>
> > Igor,
> >
> > Why it might be not enough to have ssl_enabled=[true | false]? Could you
> > give an example since you’ve already did a research?
> >
> > —
> > Denis
> >
> > > On Jan 26, 2018, at 6:08 AM, Igor Sapego  wrote:
> > >
> > > Guys,
> > >
> > > The SSL for the ODBC is pretty much ready and working, so
> > > here is update on the current state I want to share with you.
> > > And of course, I'd like to to hear your opinion on this one.
> > >
> > > First of all, I've checked some discussions about the ssl_mode
> > > approaches in different ODBC drivers and it seems to me that
> > > there is a big chance that simple ssl_enabled=[true|false]
> > > approach is not going to be enough for our users.
> > >
> > > So I propose a compromise for now. The compromise is to use
> > > ssl_mode=[require|disable] parameter right now, which is pretty
> > > much as easy to understand as ssl_enabled=[true|false], but
> > > leaves us a possibility to add other modes in future if we need
> > > them.
> > >
> > > So the full set of SSL parameters now is the following:
> > > ssl_mode=[require|disable]
> > > ssl_key_file=
> > > ssl_cert_file=
> > > ssl_ca_file=
> > >
> > > Thoughts?
> > >
> > > Best Regards,
> > > Igor
> > >
> > > On Tue, Nov 21, 2017 at 2:01 AM, Denis Magda 
> wrote:
> > >
> > >> This configuration approach looks clearer to me. +1 for it.
> > >>
> > >> —
> > >> Denis
> > >>
> > >>> On Nov 20, 2017, at 12:42 AM, Igor Sapego 
> wrote:
> > >>>
> > >>> Ok, then how about the following set of options:
> > >>>
> > >>> ssl_enabled=[true|false]
> > >>> ssl_key_file=
> > >>> ssl_cert_file=
> > >>>
> > >>>
> > >>> Best Regards,
> > >>> Igor
> > >>>
> > >>> On Tue, Nov 14, 2017 at 5:21 PM, Vladimir Ozerov <
> voze...@gridgain.com
> > >
> > >>> wrote:
> > >>>
> >  I think it would be enough to have a single switch for now.
> > 
> >  On Tue, Nov 7, 2017 at 10:04 PM, Denis Magda 
> > wrote:
> > 
> > > Igor,
> > >
> > > Thanks for the clarification. Please file a ticket if nobody else
> > >> shares
> >  a
> > > feedback soon.
> > >
> > > —
> > > Denis
> > >
> > >> On Nov 7, 2017, at 1:23 AM, Igor Sapego 
> wrote:
> > >>
> > >> Hi Denis,
> > >>
> > >>> Could you explain the difference between “allow, prefer and
> > require”
> > >> modes?
> > >> allow - Client will first try connecting without SSL, and then
> > >> fallback
> > > to
> > >> SSL if it is not allowed to connect without SSL;
> > >> prefer - Client will first try connecting using SSL, and then
> > fallback
> >  to
> > >> non-SSL if SSL is not supported by the server;
> > >> disable - Client will only connect using SSL and return error if
> > >> failed
> > > to
> > >> successfully do so.
> > >>
> > >>> BTW, do we really need to have the “disable” one? Guess that
> having
> > >> ssl_mode set to “disable” will have the same effect as not setting
> > the
> > >> ssl_mode at all.
> > >> This is the matter of the default value of the ssl_mode option.
> The
> > >> way
> > > you
> > >> propose it means that you still has "disable" option, it is just
> is
> > >> not
> > >> explicit.
> > >>
> > >> Best Regards,
> > >> Igor
> > >>
> > >> On Fri, Nov 3, 2017 at 10:35 PM, Denis Magda 
> >  wrote:
> > >>
> > >>> Hi Igor,
> > >>>
> > >>> Could you explain the difference between “allow, prefer and
> > require”
> > > modes?
> > >>>
> > >>> BTW, do we really need to have the “disable” one? Guess that
> having
> > >>> ssl_mode set to “disable” will have the same effect as not
> setting
> > >> the
> > >>> ssl_mode at all.
> > >>>
> > >>> —
> > >>> Denis
> > >>>
> >  On Nov 3, 2017, at 9:04 AM, Igor Sapego 
> > wrote:
> > 
> >  Hi, Igniters,
> > 
> >  I'm going to start working on the SSL support for the ODBC
> >  connection and I need to hear your opinion.
> > 
> >  For the client side I'm going to use OpenSSL library [1], which
> is
> >  standard de-facto for C/C++ applications. Unfortunately its
> >  licence is not fully compatible with Ap

[GitHub] ignite pull request #3447: IGNITE-7329 .NET: Thin client: SSL

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

https://github.com/apache/ignite/pull/3447

IGNITE-7329 .NET: Thin client: SSL



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ptupitsyn/ignite ignite-7329

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3447.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3447


commit 68d7154cb033ed69d48998f40ec3ed5da6a1392a
Author: Igor Sapego 
Date:   2017-12-04T16:14:04Z

IGNITE-6810: Implemented SecureSocketClient

commit 5cebaacb49a30dfba8ffc1f7f566a9fdd365a37a
Author: Igor Sapego 
Date:   2017-12-21T16:44:29Z

IGNITE-6810: Implemented SSL connection.

commit 955dd22930b35b3d54d98f4932229223537bcd53
Author: Igor Sapego 
Date:   2017-12-22T15:16:58Z

IGNITE-6810: Added saving SSL parameters to DSN

commit 8876df39efbf0061b611ee16479a3d032d7d2676
Author: Igor Sapego 
Date:   2017-12-25T16:24:24Z

IGNITE-6810: Changed UI layout

commit 089c81b9b971c1d8270987d5a6bcac94383212bc
Author: Igor Sapego 
Date:   2017-12-26T12:26:44Z

IGNITE-6810: Added values retrieval

commit 817584dc9de401d523af8c301ec5982d3ad8f249
Author: Igor Sapego 
Date:   2017-12-26T13:05:59Z

IGNITE-6810: Implmented disabling of SSL options on choosing "disable"
mode

commit a780fd1f36903549199cdcbef0d963b79f00b462
Author: Igor Sapego 
Date:   2017-12-26T13:40:42Z

IGNITE-6810: Merge-related fixes

commit 26a882eb5795b7b86e94dedc50c81791a7d04ddd
Author: Igor Sapego 
Date:   2017-12-27T12:26:25Z

IGNITE-6810: Fix for SecureSocketClient disconnect.

commit 64e3c89a8c626ab5c77da8aefe2106473cfcc078
Author: Igor Sapego 
Date:   2017-12-28T17:54:17Z

IGNITE-6810: Implemented OpenSSL dynamic loading.

commit 92e3febdd2d54dc0cfb16e6d8d9299dc571b6855
Author: Igor Sapego 
Date:   2018-01-10T15:54:49Z

IGNITE-6810: Minor fixes

commit 517ff46c5e3dff8ea0969c71963649aa0e709225
Author: Igor Sapego 
Date:   2018-01-11T15:37:26Z

IGNITE-6810: Fixes for Linux

commit 56b2d1046a85bed85e3e3955f974f507cdfa8e61
Author: Igor Sapego 
Date:   2018-01-11T15:41:06Z

IGNITE-6810: Fixed test

commit 9f719cd720e798a3f9e128a7eae7ae7adb855acb
Author: Igor Sapego 
Date:   2018-01-11T16:42:55Z

IGNITE-6810: Changes for Linux

commit cf4c716749b5b7b0f6d20bc48b0992a6233fbe3d
Author: Igor Sapego 
Date:   2018-01-12T09:08:33Z

IGNITE-6810: Merge-related fixes

commit a5aec9b62aedf24434d9ea12c9259ef04db74ed9
Author: Igor Sapego 
Date:   2018-01-16T15:46:38Z

IGNITE-6810: Improved Server-side

commit 09fe00532faa75e0148eafd67696efda73dca6ba
Author: Igor Sapego 
Date:   2018-01-18T12:43:28Z

IGNITE-6810: Implemented timeouts for SSL connections

commit db770a8537b28922f74b3984eef88285fe53508f
Author: Igor Sapego 
Date:   2018-01-18T15:11:02Z

IGNITE-6810: Fix for linux

commit 471d49cf33a8008dc100c33c9ac107f199f19f17
Author: Igor Sapego 
Date:   2018-01-18T15:49:03Z

IGNITE-6810: Fixes for linux

commit 77eb83cb2d249faea4c36050653ab9d1de24272b
Author: Igor Sapego 
Date:   2018-01-18T16:10:43Z

IGNITE-6810: Fixed linux errors

commit 97b1c80b078bbf984d4137f17f9ad6ddf6b3e1fc
Author: Igor Sapego 
Date:   2018-01-23T16:43:25Z

IGNITE-6810: Fix for x86

commit 79b5be4fe5c078c0d2fa28f9c9adbb29dadce491
Author: Igor Sapego 
Date:   2018-01-23T16:44:59Z

IGNITE-6810: Typo fixed

commit 90b74898ac84f158ce6dd76818ced6eb5aee4014
Author: Pavel Tupitsyn 
Date:   2018-01-24T07:54:25Z

Merge branch 'master' into ignite-7329

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/configuration/ClientConnectorConfiguration.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/odbc/ClientListenerProcessor.java

commit 18bf93161008cdf02b6e35d536a37baaf58753ec
Author: Pavel Tupitsyn 
Date:   2018-01-24T08:29:36Z

IGNITE-7329 .NET: Thin client: SSL

commit 78f22353add53bee60b341756dee41c5aed738a9
Author: Pavel Tupitsyn 
Date:   2018-01-24T12:16:34Z

wip raw tests

commit 80b399895a13686a231872fabb0f07a672219c85
Author: Pavel Tupitsyn 
Date:   2018-01-24T12:21:54Z

wip

commit 2b723d494f12c97989f1f24338d056e308a3b01f
Author: Pavel Tupitsyn 
Date:   2018-01-24T12:30:19Z

wip test

commit 7b64da68e243839e0508365b4486cec49adab54f
Author: Pavel Tupitsyn 
Date:   2018-01-24T12:37:14Z

wip tests

commit 449253909a11b3490c22f9c3230ee8e31093f2a5
Author: Pavel Tupitsyn 
Date:   2018-01-24T12:45:15Z

wip tests

commit 1d3ef776b287e54f813d46d77c8fcf737b56076e
Author: Pavel Tupitsyn 
Date:   2018-01-24T15:02:15Z

wip

commit a0664d7d6740623f87ef3700b7d6f01022587489
Author: Pavel Tupitsyn 
Date:   2018-01-24T15:14:21Z

It works!!




---

[GitHub] ignite pull request #3448: IGNITE-7476 IGNITE-7519 needed for reproducer of ...

[alamar]

GitHub user alamar opened a pull request:

https://github.com/apache/ignite/pull/3448

IGNITE-7476 IGNITE-7519 needed for reproducer of IGNITE-7540



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-7476-7519

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3448.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3448


commit 246239105c7ca5b835ed1767f4f6be667f374ccc
Author: Ilya Kasnacheev 
Date:   2018-01-29T13:18:21Z

IGNITE-7519 Avoid suppression of exceptions by IsolatedUpdater in data 
streamer.

commit 83ebbe5630cca6b40e96d61637ba4e5058b3c253
Author: Ilya Kasnacheev 
Date:   2018-01-29T13:20:01Z

IGNITE-7476 Avoid NPE during metrics gathering leading to discovery thread 
failure.




---

[GitHub] ignite pull request #3140: IGNITE-7017: Archiver disabled WAL mode in case f...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3140


---

[jira] [Created] (IGNITE-7557) CLI AUTH: implement SQL commands to users management

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-7557:


 Summary: CLI AUTH: implement SQL commands to users management
 Key: IGNITE-7557
 URL: https://issues.apache.org/jira/browse/IGNITE-7557
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.3
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.5


Create SQL commands for user management:
- CREATE USER
- ALTER USER
- DROP USER

[Devlist 
discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Username-password-authentication-for-thin-clients-td26058.html]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7558) CLI AUTH: add user authentication to JDBC thin driver

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-7558:


 Summary: CLI AUTH: add user authentication to JDBC thin driver
 Key: IGNITE-7558
 URL: https://issues.apache.org/jira/browse/IGNITE-7558
 Project: Ignite
  Issue Type: Task
  Components: jdbc
Affects Versions: 2.3
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.5


Add user authentication to JDBC thin driver.
- Authentication will be disabled by default to let users migrate from previous 
versions easily
- Clients will optionally pass username and password to the cluster during 
handshake phase.
- Password will be delivered in a *plain form*, because otherwise clients will 
have to implement complex hashing logic on their own. SSL will be used to 
protect passwords.

[Devlist 
discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Username-password-authentication-for-thin-clients-td26058.html]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3449: IGNITE-7509 Adjust documentation for ML module

[oignatenko]

GitHub user oignatenko opened a pull request:

https://github.com/apache/ignite/pull/3449

IGNITE-7509 Adjust documentation for ML module

- updated docs
-- verified with diffs overview and rebuild per updated instructions

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-7509

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3449.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3449


commit 88fc8e95fcfb6ead7379c1ecfaa861b286882695
Author: Oleg Ignatenko 
Date:   2018-01-29T15:21:51Z

IGNITE-7509 Adjust documentation for ML module
- updated docs
-- verified with diffs overview and rebuild per updated instructions




---

[jira] [Created] (IGNITE-7559) Adjust documentation for ML module at readme.io

[Oleg Ignatenko (JIRA)]

Oleg Ignatenko created IGNITE-7559:
--

 Summary: Adjust documentation for ML module at readme.io
 Key: IGNITE-7559
 URL: https://issues.apache.org/jira/browse/IGNITE-7559
 Project: Ignite
  Issue Type: Sub-task
  Components: documentation, ml
Affects Versions: 2.4
Reporter: Oleg Ignatenko


Reflect changes made to github per IGNITE-7509 in respective docs at readme.io.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3450: IGNITE-898: Fixed error when path to Ignite folde...

[vveider]

GitHub user vveider opened a pull request:

https://github.com/apache/ignite/pull/3450

IGNITE-898: Fixed error when path to Ignite folder contains whitespaces

 * Fixed error when path to ignite folder contains whitespaces
 * Fixed error when path to ignite folder contains whitespaces (for Windows 
batch files)
 * Fixed condition operator for paths with spaces
 * Returned full path to java.exe

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-898

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3450.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3450


commit 673868239558d7350c3bfbb8d9d95565772e371b
Author: alexzaitzev 
Date:   2018-01-29T15:36:41Z

IGNITE-898: Fixed error when path to Ignite folder contains whitespaces
 * Fixed error when path to ignite folder contains whitespaces
 * Fixed error when path to ignite folder contains whitespaces (for Windows 
batch files)
 * Fixed condition operator for paths with spaces
 * Returned full path to java.exe




---

Should we annotate @CacheLocalStore as @Depricated?

[Vyacheslav Daradur]

Hi Igniters,

I've worked with Apache Ignite 3rd Party Persistent Storage tools recently.

I found that use of CacheLocalStore annotation has hidden issues, for example:
* rebalancing issues [1]
* possible data consistency issues [1]
* handling of CacheLocalStore on clients nodes [2]

Valentin K. considers it necessary to make @CacheLocalStore deprecated
and remove. If we want to have a decentralized persistent storage we
should use Apache Ignite Native Persistence.

If the community supports this decision I will create a new Jira issue.

Any thoughts?

[1] 
http://apache-ignite-developers.2346864.n4.nabble.com/Losing-data-during-restarting-cluster-with-persistence-enabled-tt24267.html
[2] 
http://apache-ignite-developers.2346864.n4.nabble.com/How-to-handle-CacheLocalStore-on-clients-node-tt25703.html



-- 
Best Regards, Vyacheslav D.

Re: Should we annotate @CacheLocalStore as @Depricated?

[Andrey Mashenkov]

Vyacheslav,

+1 for dropping @CacheLocalStore.
Ignite have no support 2-phase commit for store and public API provides no
methods to users can easily implement it by themselves.




On Mon, Jan 29, 2018 at 7:11 PM, Vyacheslav Daradur 
wrote:

> Hi Igniters,
>
> I've worked with Apache Ignite 3rd Party Persistent Storage tools recently.
>
> I found that use of CacheLocalStore annotation has hidden issues, for
> example:
> * rebalancing issues [1]
> * possible data consistency issues [1]
> * handling of CacheLocalStore on clients nodes [2]
>
> Valentin K. considers it necessary to make @CacheLocalStore deprecated
> and remove. If we want to have a decentralized persistent storage we
> should use Apache Ignite Native Persistence.
>
> If the community supports this decision I will create a new Jira issue.
>
> Any thoughts?
>
> [1] http://apache-ignite-developers.2346864.n4.nabble.
> com/Losing-data-during-restarting-cluster-with-
> persistence-enabled-tt24267.html
> [2] http://apache-ignite-developers.2346864.n4.nabble.com/How-to-handle-
> CacheLocalStore-on-clients-node-tt25703.html
>
>
>
> --
> Best Regards, Vyacheslav D.
>



-- 
Best regards,
Andrey V. Mashenkov

[GitHub] ignite pull request #3449: IGNITE-7509 Adjust documentation for ML module

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3449


---

Re: Next Steps: GA Grid: Request to contribute GA library to Apache Ignite

[Denis Magda]

Hi Turik,

The next step is to file a software grant and navigate through the IP clearance 
process:
http://incubator.apache.org/ip-clearance/ip-clearance-template.html 


Once this is done, the GA Grid will be officially accepted and released in the 
next Ignite version.

I’ll execute the IP clearance process as a PMC representative while I would ask 
you to file a software grant to the ASF:
* Grant template: http://www.apache.org/licenses/software-grant-template.pdf
* Submission: http://www.apache.org/licenses/#submitting

—
Denis

> On Jan 25, 2018, at 3:01 PM, techbysample  wrote:
> 
> Denis/Yury, 
> 
> Please advise on next steps.
> 
> JIRA:  https://issues.apache.org/jira/browse/IGNITE-6899
> 
> Per recent comments from Oleg Ignatenko:
> 
> "...most recent change looks good to me: the typo in MovieFitnessFunction is
> fixed and the rest of code is the same as it was ie everything now looks
> right.."
> 
> Please advise.
> 
> Best,
> Turik Campbell
> 
> 
> 
> 
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

[jira] [Created] (IGNITE-7560) Baseline topology documentation

[Denis Magda (JIRA)]

Denis Magda created IGNITE-7560:
---

 Summary: Baseline topology documentation
 Key: IGNITE-7560
 URL: https://issues.apache.org/jira/browse/IGNITE-7560
 Project: Ignite
  Issue Type: Task
  Components: documentation
Reporter: Denis Magda
Assignee: Denis Magda
 Fix For: 2.4


Document baseline topology architecture, benefits, and usage:

https://cwiki.apache.org/confluence/display/IGNITE/IEP-4+Baseline+topology+for+caches



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3446: IGNITE-7534 ClusterGroupExample duplicate

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3446


---

[jira] [Created] (IGNITE-7561) .NET: Service proxy as dynamic object

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-7561:
--

 Summary: .NET: Service proxy as dynamic object
 Key: IGNITE-7561
 URL: https://issues.apache.org/jira/browse/IGNITE-7561
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn


Currently we require user to provide an interface to interact with .NET and 
Java services.

We could also provide a dynamic API (based on {{dynamic}} keyword) like this:

{code}
IServices services = ignite.GetServices();
dynamic prx = services.GetDynamicServiceProxy("someService");
prx.Foo();
prx.Bar = 1;
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7562) .NET: Binary object as dynamic object

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-7562:
--

 Summary: .NET: Binary object as dynamic object
 Key: IGNITE-7562
 URL: https://issues.apache.org/jira/browse/IGNITE-7562
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn


Provide a way to access {{IBinaryObject}} fields through C# {{dynamic}} API:

{code}
IBinaryObject obj = cache.Get(1);
var name = obj.GetField("Name");  // Current API

dynamic dynObj = obj.AsDynamic();
name = dynObj.Name;  // Proposed API
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7563) .NET: Binary object builder dynamic API

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-7563:
--

 Summary: .NET: Binary object builder dynamic API
 Key: IGNITE-7563
 URL: https://issues.apache.org/jira/browse/IGNITE-7563
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn


Provide a way to build binary objects with C# {{dynamic}} API:

{code}
IBinary bin = ignite.GetBinary();
IBinaryObjectBuilder builder = bin.GetBuilder("myType");
builder.SetField("Name", "Jack");  // current API

IBinaryObjectBuilderDynamic dynBuilder = builder.AsDynamic();
dynBuilder.Name = "Jack";
IBinaryObject result = dynBuilder.Build();
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Should we annotate @CacheLocalStore as @Depricated?

[Valentin Kulichenko]

+1

On Mon, Jan 29, 2018 at 8:31 AM, Andrey Mashenkov <
andrey.mashen...@gmail.com> wrote:

> Vyacheslav,
>
> +1 for dropping @CacheLocalStore.
> Ignite have no support 2-phase commit for store and public API provides no
> methods to users can easily implement it by themselves.
>
>
>
>
> On Mon, Jan 29, 2018 at 7:11 PM, Vyacheslav Daradur 
> wrote:
>
> > Hi Igniters,
> >
> > I've worked with Apache Ignite 3rd Party Persistent Storage tools
> recently.
> >
> > I found that use of CacheLocalStore annotation has hidden issues, for
> > example:
> > * rebalancing issues [1]
> > * possible data consistency issues [1]
> > * handling of CacheLocalStore on clients nodes [2]
> >
> > Valentin K. considers it necessary to make @CacheLocalStore deprecated
> > and remove. If we want to have a decentralized persistent storage we
> > should use Apache Ignite Native Persistence.
> >
> > If the community supports this decision I will create a new Jira issue.
> >
> > Any thoughts?
> >
> > [1] http://apache-ignite-developers.2346864.n4.nabble.
> > com/Losing-data-during-restarting-cluster-with-
> > persistence-enabled-tt24267.html
> > [2] http://apache-ignite-developers.2346864.n4.nabble.com/How-to-handle-
> > CacheLocalStore-on-clients-node-tt25703.html
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>

Re: [SparkDataFrame] Saving DataFrame to Ignite

[Valentin Kulichenko]

Nikolay,

Thanks, I will do a review this week.

-Val

On Fri, Jan 26, 2018 at 6:19 AM, Nikolay Izhikov 
wrote:

> Hello, guys.
>
> I've finish implementation of IGNITE-7337 [1]
>
> Support of saving data frame to Ignite.
> Please, review.
>
> Valentin, I think it would be better to review this task prior IGNITE-7077
> (query optimization).
> Because, this issue is relatively smaller and easier to review.
> And, from my point of view, adds some valuable feature to project.
>
>
> [1] https://issues.apache.org/jira/browse/IGNITE-7337
> [2] https://github.com/apache/ignite/pull/3438
>

Re: Next Steps: GA Grid: Request to contribute GA library to Apache Ignite

[techbysample]

Denis,

Hello. 

I sent the form previously on  November 20, 2017 to secret...@apache.org and
cc'd  you at emails: dma...@gridgain.com, dma...@apache.org.

Per the emails below, I understood the document was already received by
Craig L Russell.

Please advise if you still require additional information from me.

Thank you.

Best,
Turik Campbell

On 2017-11-20 17:22, Turik Campbell wrote:
> To whom it may concern,
> 
> Attached you will find a copy of the 'Software Grant Agreement'
> to donate GA Grid to Apache Ignite.
> 
> Please advise.
> 
> Best,
> Turik Campbell
> NetMillennium, Inc.
> 866.300.2393
> 
> 

On 2017-11-20 18:37, Craig L Russell wrote:
> Dear Turik Campbell,
> 
> This message acknowledges receipt of the following document, which has
> been filed in the Apache Software Foundation records:
> 
>   Software Grant from NetMillennium, Inc.
> 
> -- Craig L Russell
> Secretary, Apache Software Foundation






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

Re: IGNITE_HOME for persistence

[Denis Magda]

No we don’t. I’ve never touched IGNITE_HOME variable for any other purpose.

As it was suggested, the reported should share the project to reproduce his 
scenario.

—
Denis

> On Jan 26, 2018, at 9:05 PM, Dmitriy Setrakyan  wrote:
> 
> Igniters,
> 
> I have just stumbled upon this post on SO:
> https://stackoverflow.com/questions/48434929/apache-ignite-persistent-storage
> 
> Do we require IGNITE_HOME to be set if the persistence is enabled? If yes,
> do we check for it on startup?
> 
> D.

Re: SSL for ODBC connection

[Denis Magda]

Igor,

Thanks for the references. Now it makes total sense to me. Let’s go for your 
approach suggested earlier.

—
Denis

> On Jan 29, 2018, at 3:50 AM, Igor Sapego  wrote:
> 
> Denis,
> 
> For example, there are often such options as "verify-ca" and "verify-full".
> [1-3]
> Moreover, this approach seems more consistent with other solutions and thus
> more familiar to user.
> 
> [1] - https://www.postgresql.org/docs/9.1/static/libpq-ssl.html
> [2] -
> https://docs.oracle.com/cd/E17952_01/connector-odbc-en/connector-odbc-configuration-connection-parameters.html
> [3] -
> https://dev.mysql.com/doc/connector-odbc/en/connector-odbc-configuration-connection-parameters.html
> 
> Best Regards,
> Igor
> 
> On Sat, Jan 27, 2018 at 2:22 AM, Denis Magda  wrote:
> 
>> Igor,
>> 
>> Why it might be not enough to have ssl_enabled=[true | false]? Could you
>> give an example since you’ve already did a research?
>> 
>> —
>> Denis
>> 
>>> On Jan 26, 2018, at 6:08 AM, Igor Sapego  wrote:
>>> 
>>> Guys,
>>> 
>>> The SSL for the ODBC is pretty much ready and working, so
>>> here is update on the current state I want to share with you.
>>> And of course, I'd like to to hear your opinion on this one.
>>> 
>>> First of all, I've checked some discussions about the ssl_mode
>>> approaches in different ODBC drivers and it seems to me that
>>> there is a big chance that simple ssl_enabled=[true|false]
>>> approach is not going to be enough for our users.
>>> 
>>> So I propose a compromise for now. The compromise is to use
>>> ssl_mode=[require|disable] parameter right now, which is pretty
>>> much as easy to understand as ssl_enabled=[true|false], but
>>> leaves us a possibility to add other modes in future if we need
>>> them.
>>> 
>>> So the full set of SSL parameters now is the following:
>>> ssl_mode=[require|disable]
>>> ssl_key_file=
>>> ssl_cert_file=
>>> ssl_ca_file=
>>> 
>>> Thoughts?
>>> 
>>> Best Regards,
>>> Igor
>>> 
>>> On Tue, Nov 21, 2017 at 2:01 AM, Denis Magda  wrote:
>>> 
 This configuration approach looks clearer to me. +1 for it.
 
 —
 Denis
 
> On Nov 20, 2017, at 12:42 AM, Igor Sapego  wrote:
> 
> Ok, then how about the following set of options:
> 
> ssl_enabled=[true|false]
> ssl_key_file=
> ssl_cert_file=
> 
> 
> Best Regards,
> Igor
> 
> On Tue, Nov 14, 2017 at 5:21 PM, Vladimir Ozerov >> 
> wrote:
> 
>> I think it would be enough to have a single switch for now.
>> 
>> On Tue, Nov 7, 2017 at 10:04 PM, Denis Magda 
>> wrote:
>> 
>>> Igor,
>>> 
>>> Thanks for the clarification. Please file a ticket if nobody else
 shares
>> a
>>> feedback soon.
>>> 
>>> —
>>> Denis
>>> 
 On Nov 7, 2017, at 1:23 AM, Igor Sapego  wrote:
 
 Hi Denis,
 
> Could you explain the difference between “allow, prefer and
>> require”
 modes?
 allow - Client will first try connecting without SSL, and then
 fallback
>>> to
 SSL if it is not allowed to connect without SSL;
 prefer - Client will first try connecting using SSL, and then
>> fallback
>> to
 non-SSL if SSL is not supported by the server;
 disable - Client will only connect using SSL and return error if
 failed
>>> to
 successfully do so.
 
> BTW, do we really need to have the “disable” one? Guess that having
 ssl_mode set to “disable” will have the same effect as not setting
>> the
 ssl_mode at all.
 This is the matter of the default value of the ssl_mode option. The
 way
>>> you
 propose it means that you still has "disable" option, it is just is
 not
 explicit.
 
 Best Regards,
 Igor
 
 On Fri, Nov 3, 2017 at 10:35 PM, Denis Magda 
>> wrote:
 
> Hi Igor,
> 
> Could you explain the difference between “allow, prefer and
>> require”
>>> modes?
> 
> BTW, do we really need to have the “disable” one? Guess that having
> ssl_mode set to “disable” will have the same effect as not setting
 the
> ssl_mode at all.
> 
> —
> Denis
> 
>> On Nov 3, 2017, at 9:04 AM, Igor Sapego 
>> wrote:
>> 
>> Hi, Igniters,
>> 
>> I'm going to start working on the SSL support for the ODBC
>> connection and I need to hear your opinion.
>> 
>> For the client side I'm going to use OpenSSL library [1], which is
>> standard de-facto for C/C++ applications. Unfortunately its
>> licence is not fully compatible with Apache Licence, so its going
>> to require from users to install OpenSSL themselves.
>> 
>> For the driver I'm going to add following options to connection
>> string:
>> ssl_mode - Determines whether or with what priority a 

[GitHub] ignite pull request #3307: IGNITE-7323: Update Storm dependencies to 1.1.1.

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3307


---

[jira] [Created] (IGNITE-7564) Document IgniteSet memory consumption

[Alexander Belyak (JIRA)]

Alexander Belyak created IGNITE-7564:


 Summary: Document IgniteSet memory consumption
 Key: IGNITE-7564
 URL: https://issues.apache.org/jira/browse/IGNITE-7564
 Project: Ignite
  Issue Type: Bug
  Components: documentation
Affects Versions: 2.2
Reporter: Alexander Belyak


We need to document onheap memory consumption of IgniteSet collections (all 
values stored in durable memory AND in java heap).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7565) Remove IgniteSet from heap

[Alexander Belyak (JIRA)]

Alexander Belyak created IGNITE-7565:


 Summary: Remove IgniteSet from heap
 Key: IGNITE-7565
 URL: https://issues.apache.org/jira/browse/IGNITE-7565
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.2
Reporter: Alexander Belyak


IgniteSet store all data in durable memory and in java heap. It's not good for 
big clusters and big sets, so we need to remove values from heap.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: .NET development on Linux & macOS is now possible

[Yakov Zhdanov]

Pavel,

I tried this out recently and had few minor issues.

1. due to path issues mvn executable was not found, but process coninued to
.net build
2. after I set path for mvn it still was failing due to incorrect java home

Should we report maven build issues and stop the overall process with
appropriate error message?

Also 2 tests failed for me:

Failed   TestClientDisposeWhileOperationsAreInProgress
Error Message:
   Some tasks should have failed.
  Expected: True
  But was:  False

Stack Trace:
   at
Apache.Ignite.Core.Tests.Client.ClientConnectionTest.TestClientDisposeWhileOperationsAreInProgress()
in
/home/yzhdanov/projects/incubator-ignite/modules/platforms/dotnet/Apache.Ignite.Core.Tests/Client/ClientConnectionTest.cs:line
277

Failed   TestAsyncCompletionOrder
Error Message:
   Expected: False
  But was:  True

Stack Trace:
   at
Apache.Ignite.Core.Tests.Client.Cache.CacheTest.TestAsyncCompletionOrder()
in
/home/yzhdanov/projects/incubator-ignite/modules/platforms/dotnet/Apache.Ignite.Core.Tests/Client/Cache/CacheTest.cs:line
855

If you need logs just let me know.

--Yakov

Plugins in tests

[Yakov Zhdanov]

Guys,

When running tests from core module I see that Ignite has 2 plugins
configured by default (because they are available in classpath):

-TestReconnectPlugin 1.0
-StanByClusterTestProvider 1.0

It seems they were introduced by Dmitry Karachentsev and Dmitry Govorukhin.
Guys, can you please move the plugins to extdata project similar to
PlatformTestPlugin and configure them only when needed. This is not correct
that each test we run for Ignite runs with plugins configured. By default
Ignite does not have any plugin.

--Yakov

Re: Should we annotate @CacheLocalStore as @Depricated?

[Yakov Zhdanov]

+1 for deprecation



--Yakov

2018-01-30 1:06 GMT+03:00 Valentin Kulichenko :

> +1
>
> On Mon, Jan 29, 2018 at 8:31 AM, Andrey Mashenkov <
> andrey.mashen...@gmail.com> wrote:
>
> > Vyacheslav,
> >
> > +1 for dropping @CacheLocalStore.
> > Ignite have no support 2-phase commit for store and public API provides
> no
> > methods to users can easily implement it by themselves.
> >
> >
> >
> >
> > On Mon, Jan 29, 2018 at 7:11 PM, Vyacheslav Daradur  >
> > wrote:
> >
> > > Hi Igniters,
> > >
> > > I've worked with Apache Ignite 3rd Party Persistent Storage tools
> > recently.
> > >
> > > I found that use of CacheLocalStore annotation has hidden issues, for
> > > example:
> > > * rebalancing issues [1]
> > > * possible data consistency issues [1]
> > > * handling of CacheLocalStore on clients nodes [2]
> > >
> > > Valentin K. considers it necessary to make @CacheLocalStore deprecated
> > > and remove. If we want to have a decentralized persistent storage we
> > > should use Apache Ignite Native Persistence.
> > >
> > > If the community supports this decision I will create a new Jira issue.
> > >
> > > Any thoughts?
> > >
> > > [1] http://apache-ignite-developers.2346864.n4.nabble.
> > > com/Losing-data-during-restarting-cluster-with-
> > > persistence-enabled-tt24267.html
> > > [2] http://apache-ignite-developers.2346864.n4.nabble.
> com/How-to-handle-
> > > CacheLocalStore-on-clients-node-tt25703.html
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
> >
> >
> >
> > --
> > Best regards,
> > Andrey V. Mashenkov
> >
>