Re: [Discussion] Kanban board for quick start issues to join the community

[Konstantin Boudnik]

I guess the same result could be achieved with simple labels, no?

With regards,
  Cos

On 22.01.2021 16:25, Saikat Maitra wrote:

Hi,

I was looking into our community page to find new open issues that I can
contribute to and the easy and moderate tickets, tickets for beginners and
SQL tasks help me to find open issues to contribute.

I am also thinking if we should use a project Kanban board in jira and move
these issues in the ToDo column so that it is easy to find and contribute
to these open issues.

I have seen few Apache Project like Beam, Flink already uses Kanban board

https://issues.apache.org/jira/secure/RapidBoard.jspa?projectKey=BEAM=325

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=356=FLINK

Please review and let me know your thoughts.

Regards
Saikat

Re: [DISCUSSION] Renaming Ignite's product category

[Konstantin Boudnik]

+1

With regards,
  Cos

On 2020-09-21 20:35, Nikita Ivanov wrote:

My vote is to just call ignite "IgniteDB". That's it. No other additional
explanation is required as no amount of additional verbiage will help.
Every DB is different: from MongoDB, to RedisDB, to CockroachDB, to Oracle
- they all look & act completely different, and they don't go around trying
to explain in one line what they do and how they are different.

"IgniteDB" is clear, concise and gives us the broadest initial acceptance
from the new user perspective.

Thanks,
--
Nikita Ivanov



On Sat, Sep 19, 2020 at 1:10 PM Saikat Maitra 
wrote:


Hi,

My thoughts are similar to as Denis and Val mentioned like Apache Ignite -
"A Memory Centric Database".

It aligns to current features of Apache Ignite as mentioned in the below
post.


https://thenewstack.io/memory-centric-architectures-whats-next-for-in-memory-computing

Regards,
Saikat

On Fri, Sep 18, 2020 at 9:02 AM Carbone, Adam 
wrote:


So when I came across Ignite It was described as an In Memory Data Grid

So one way to look at this is who do you fashion as Ignite competing
against?

Are competing against Redis, Aerospike - In Memory Databases

Or are you more competing with

Gigaspaces - True In memory Compute platform

And then you have like of

Hazelcast that started as a Distributed Hash and have gained some
features...

On thing that I think is a differentiator that isn't being highlighted
but Is  unique feature to Ignited, and the primary reason we ended up here;
The integration with spark and it's distributed/shared Datasets/Dataframes.

I don't know for me the In Memory Data Grid I think fits what Ignite
is...

Regards

~Adam

Adam Carbone | Director of Innovation – Intelligent Platform Team |
Bottomline Technologies
Office: 603-501-6446 | Mobile: 603-570-8418
www.bottomline.com



On 9/17/20, 11:45 AM, "Glenn Wiebe"  wrote:

 I agree with Stephen about "database" devaluing what Ignite can do
(though
 it probably hits the majority of existing use cases). I tend to go
with
 "massively distributed storage and compute platform"

 I know, I didn't take sides, I just have both.

 Cheers,
   Glenn

 On Thu., Sep. 17, 2020, 7:04 a.m. Stephen Darlington, <
 stephen.darling...@gridgain.com> wrote:

 > I think this is a great question. Explaining what Ignite does is
always a
 > challenge, so having a useful “tag line” would be very valuable.
 >
 > I’m not sure what the answer is but I think calling it a “database”
 > devalues all the compute facilities. "Computing platform” may be
too vague
 > but it at least says that we do more than “just” store data.
 >
 > On 17 Sep 2020, at 06:29, Valentin Kulichenko <
 > valentin.kuliche...@gmail.com> wrote:
 >
 > My vote is for the "distributed memory-first database". It clearly
states
 > that Ignite is a database (which is true at this point), while still
 > emphasizing the in-memory computing power endorsed by the platform.
 >
 > The "in-memory computing platform" is an ambiguous term and doesn't
really
 > reflect what Ignite is, especially in its current state.
 >
 > -Val
 >
 > On Wed, Sep 16, 2020 at 3:53 PM Denis Magda 
wrote:
 >
 >> Igniters,
 >>
 >> Throughout the history of our project, we could see how the
addition of
 >> certain features required us to reassess the project's name and
category.
 >>
 >> Before Ignite joined the ASF, it supported only compute APIs
resembling
 >> the
 >> MapReduce engine of Hadoop. Those days, it was fair to define
Ignite as "a
 >> distributed in-memory computing engine". Next, at the time of the
project
 >> donation, it already included key-value/SQL/transactional APIs,
was used
 >> as
 >> a distributed cache, and significantly outgrew the "in-memory
computing
 >> engine" use case. That's how the project transitioned to the
product
 >> category of in-memory caches and we started to name it as an
"in-memory
 >> data grid" or "in-memory computing platform" to differentiate from
 >> classical caching products such as Memcached and Redis.
 >>
 >> Nowadays, the project outgrew its caching use case, and the
classification
 >> of Ignite as an "in-memory data grid" or "in-memory computing
platform"
 >> doesn't sound accurate. We rebuilt our storage engine by replacing
a
 >> typical key-value engine with a B-tree engine that spans across
memory and
 >> disk tiers. And it's not surprising to see more deployments of
Ignite as a
 >> database on its own. So, it feels like we need to reconsider Ignite
 >> positioning again so that a) application developers can discover
it easily
 >> via search engines and b) the project can stand out from in-memory
 >> projects
 >> with intersecting capabilities.
 >>
 >> To the point, I'm suggesting to reposition Ignite in one of the
following
 >> ways:

Re: Apache Ignite Hackathon: Open Source contribution is simple

[Konstantin Boudnik]

It is a great idea, Dmitriy. Doing meetups is a great way to bring
more contributors and developers on board. Besides, it helps the
community's biding.

I'd suggest to plan for a few solid hours of hackathon only: 3-5 hours
would be a good idea, but it might need to be done on a weekend
(depends on the weather, of course :). Mixing it with the talks might
or might not work well - I guess it is a judgement call, and depends
on the audience. I would also recommend to start some communication in
Russian language among the local folks and post the links here as
well. I will help to spread the word among people I know, as well. And
am looking forward to be there for the event!

Thanks for starting this thread, by the way!
--
  With regards,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any entity the author
might be affiliated with at the time of writing.


On Sat, Aug 25, 2018 at 1:22 AM, Dmitriy Pavlov  wrote:
> Hi Ignite Users, Developers, and Enthusiasts,
>
> It's natural to assume that a newcomer has little to offer the Apache
> Ignite. However, you can be surprised at how much each newcomer can help,
> even now.
>
> I would propose to run a hackathon on the next Apache Ignite meetup. In
> parallel with talks, an attendee can pick up a simple ticket and run full
> patch submission process during meetup and make open source contribution.
> Ignite experts will be there and will be able to help everyone interested.
>
> The first place to run - Ignite meetup in Saint Petersburg, Russia, because
> I know that several committers live there.
>
> - If you're a user or a contributor, would you like to join such activity?
> - If you're a committer, will you be able to come and help with review and
> merge?
> - Would you propose a simple ticket(s) which can be done in one hour or even
> several minutes?
>
> Any feedback is very welcome.
>
> Sincerely,
> Dmitriy Pavlov

MD5 sums in the releases

[Konstantin Boudnik]

Please be aware about the changes in the Foundation's release policy [1]

* SHOULD NOT supply a MD5 checksum file

[1] https://www.apache.org/dev/release-distribution#sigs-and-sums
--
  With regards,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.

Re: [DISCUSS] Ignite Update Checker

[Konstantin Boudnik]

Yes, that what I meant. It might not work per website (depends on how
the server is configured), but server-wide redirects could be
arranged.
Also, there's a new discussion on the topic going on legal-discuss@
right now [1]


[1] https://is.gd/RPaWQt
--
  With regards,
Konstantin (Cos) Boudnik


On Tue, Oct 31, 2017 at 1:21 PM, Dmitriy Setrakyan
<dsetrak...@apache.org> wrote:
> Cos, thanks for helping out! By redirect, do you mean changing the
> .htaccess file to point a certain URL containing Ignite version to a GA
> URL? In that case, do you know if it will be possible to still send the
> latest Ignite version back as a response?
>
> D.
>
> On Tue, Oct 31, 2017 at 11:30 AM, Konstantin Boudnik <c...@apache.org> wrote:
>
>> Looks like we are getting somewhere with this. Please check [1] for
>> the latest comment from the Infra team. I guess we can start with
>> asking for a server-side redirect to GA as the immediate step. And
>> explore it further possibilities as per Greg's recommendations.
>>
>>
>> [1] https://is.gd/CL88O6
>> --
>>   With regards,
>> Konstantin (Cos) Boudnik
>> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>>
>> Disclaimer: Opinions expressed in this email are those of the author,
>> and do not necessarily represent the views of any company the author
>> might be affiliated with at the moment of writing.
>>
>>
>> On Wed, Oct 25, 2017 at 8:21 AM, Denis Magda <dma...@apache.org> wrote:
>> > Hi Cos,
>> >
>> > Sure, will see you around there.
>> >
>> > Anyway, a short summary is the following.
>> >
>> > Starting Ignite 2.3 the nodes will be connecting to a *static* file [1]
>> deployed on Ignite site to obtain the most recent version. If the file has
>> a later version than the nodes will print out a message encouraging a user
>> to do an upgrade.
>> >
>> > On top of that, some community members proposed to trigger GA once the
>> file [1] is loaded. But to achieve this the file has to become dynamic
>> being able to execute simple CGI scripts. The INFRA turned this request
>> down.
>> >
>> > [1] https://ignite.apache.org/latest
>> > [2] https://issues.apache.org/jira/browse/INFRA-15182
>> >
>> > —
>> > Denis
>> >
>> >> On Oct 24, 2017, at 11:57 PM, Konstantin Boudnik <c...@apache.org>
>> wrote:
>> >>
>> >> Guys,
>> >>
>> >> I had a quick chat with Nikita earlier today and it seems that we have
>> came across of a blocker of some kind. With my member's hat on I would love
>> to help to find a resolution that let us (and potentially other
>> communities) to move forward.
>> >>
>> >> Let's craft the message and circulate it with Infra and Greg. Denis,
>> could you find me tomorrow at the IMCS and give me an insight into the
>> technical side of it? I feel a bit at loss after going through this
>> thread...
>> >> --
>> >> Regards,
>> >>  Cos
>> >>
>> >> On October 2, 2017 7:31:48 AM PDT, Denis Magda <dma...@apache.org>
>> wrote:
>> >>> Dmitriy,
>> >>>
>> >>> That’s the rule.  See replies in the ticket [1]
>> >>>
>> >>> *Background: the TLP server is already pretty darned busy just serving
>> >>> *static* sites. Dynamic operation for near-200 PMCs would bury the
>> >>> machine. Our policy of "static-only websites" has been in place since
>> >>> the Foundation started*
>> >>>
>> >>> Download scripts seem to be the only exception and we as PMC don’t even
>> >>> have access to them.
>> >>>
>> >>> If you want to keep pushing this direction let’s craft a message to
>> >>> Greg and Daniel directly. I don’t know what else to ask for here rather
>> >>> than a virtual machine that’s conceivably to much for a single script
>> >>> like that.
>> >>>
>> >>> [1] https://issues.apache.org/jira/browse/INFRA-15182
>> >>> <https://issues.apache.org/jira/browse/INFRA-15182>
>> >>>
>> >>> —
>> >>> Denis
>> >>>
>> >>>> On Oct 2, 2017, at 2:48 AM, Dmitriy Setrakyan <dsetrak...@apache.org>
>> >>> wrote:
>> >>>>
>> >>>> On Mon, Oct 2, 2017 at 12:46 PM, Vladimir Ozerov
>> >>> <voze...@gridgain.com>
>> >&

Re: [DISCUSS] Ignite Update Checker

[Konstantin Boudnik]

Looks like we are getting somewhere with this. Please check [1] for
the latest comment from the Infra team. I guess we can start with
asking for a server-side redirect to GA as the immediate step. And
explore it further possibilities as per Greg's recommendations.


[1] https://is.gd/CL88O6
--
  With regards,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Wed, Oct 25, 2017 at 8:21 AM, Denis Magda <dma...@apache.org> wrote:
> Hi Cos,
>
> Sure, will see you around there.
>
> Anyway, a short summary is the following.
>
> Starting Ignite 2.3 the nodes will be connecting to a *static* file [1] 
> deployed on Ignite site to obtain the most recent version. If the file has a 
> later version than the nodes will print out a message encouraging a user to 
> do an upgrade.
>
> On top of that, some community members proposed to trigger GA once the file 
> [1] is loaded. But to achieve this the file has to become dynamic being able 
> to execute simple CGI scripts. The INFRA turned this request down.
>
> [1] https://ignite.apache.org/latest
> [2] https://issues.apache.org/jira/browse/INFRA-15182
>
> —
> Denis
>
>> On Oct 24, 2017, at 11:57 PM, Konstantin Boudnik <c...@apache.org> wrote:
>>
>> Guys,
>>
>> I had a quick chat with Nikita earlier today and it seems that we have came 
>> across of a blocker of some kind. With my member's hat on I would love to 
>> help to find a resolution that let us (and potentially other communities) to 
>> move forward.
>>
>> Let's craft the message and circulate it with Infra and Greg. Denis, could 
>> you find me tomorrow at the IMCS and give me an insight into the technical 
>> side of it? I feel a bit at loss after going through this thread...
>> --
>> Regards,
>>  Cos
>>
>> On October 2, 2017 7:31:48 AM PDT, Denis Magda <dma...@apache.org> wrote:
>>> Dmitriy,
>>>
>>> That’s the rule.  See replies in the ticket [1]
>>>
>>> *Background: the TLP server is already pretty darned busy just serving
>>> *static* sites. Dynamic operation for near-200 PMCs would bury the
>>> machine. Our policy of "static-only websites" has been in place since
>>> the Foundation started*
>>>
>>> Download scripts seem to be the only exception and we as PMC don’t even
>>> have access to them.
>>>
>>> If you want to keep pushing this direction let’s craft a message to
>>> Greg and Daniel directly. I don’t know what else to ask for here rather
>>> than a virtual machine that’s conceivably to much for a single script
>>> like that.
>>>
>>> [1] https://issues.apache.org/jira/browse/INFRA-15182
>>> <https://issues.apache.org/jira/browse/INFRA-15182>
>>>
>>> —
>>> Denis
>>>
>>>> On Oct 2, 2017, at 2:48 AM, Dmitriy Setrakyan <dsetrak...@apache.org>
>>> wrote:
>>>>
>>>> On Mon, Oct 2, 2017 at 12:46 PM, Vladimir Ozerov
>>> <voze...@gridgain.com>
>>>> wrote:
>>>>
>>>>> I am not sure it is good idea to send requests to 3rd-party
>>> addresses from
>>>>> Ignite node. Let's do not make the same mistakes again.
>>>>>
>>>>
>>>> Agree with Vladimir.
>>>>
>>>> We obviously have CGI support on the website. Can someone explain why
>>> CGI
>>>> is not possible to use?
>>>>
>>>>
>>>>>
>>>>> On Mon, Oct 2, 2017 at 12:42 PM, Andrey Novikov
>>> <anovi...@gridgain.com>
>>>>> wrote:
>>>>>
>>>>>> We may directly send request to GA from Ignite node:
>>>>>> https://developers.google.com/analytics/devguides/
>>>>> collection/protocol/v1/
>>>>>> <https://developers.google.com/analytics/devguides/
>>>>> collection/protocol/v1/
>>>>>>>
>>>>>> Latest version can be received from maven central:
>>>>>> https://repo1.maven.org/maven2/org/apache/ignite/
>>>>>> ignite-core/maven-metadata.xml <https://repo1.maven.org/
>>>>>> maven2/org/apache/ignite/ignite-core/maven-metadata.xml>
>>>>>>
>>>>>>
>>>>>>> 2 окт. 2017 г., в 12:51, Dmitriy Setrakyan <dsetrak...@apache.org>
>>>

Re: [DISCUSS] Ignite Update Checker

[Konstantin Boudnik]

gt;>>> 
>>>>>>>>> Yeah, I guess that's doable as well and requires less
>management
>>>>>> effort
>>>>>>>>> than my suggestion. We could use events [1] to store payload
>data
>>>>>> (e.g.
>>>>>>>>> IP,
>>>>>>>>> version, etc.)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Yes, we could use events or some other similar API provided by
>GA.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> What the download page CGI developed in? PHP?
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> To be honest, no clue. I guess someone in the community can
>figure
>>> it
>>>>>>> out:
>>>>>>>>
>https://svn.apache.org/repos/asf/ignite/site/trunk/download.html
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> However, I'm not sure whether storing this data in a 3rd party
>>>>>> (Google)
>>>>>>> is
>>>>>>>>> compliant with the ASF policy. I guess it's no biggie, but if
>>> there's
>>>>>>>>> doubt
>>>>>>>>> in the PMC, it's better to ask legal@.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I am not sure there is anything to ask about. The whole Ignite
>>> website
>>>>>> is
>>>>>>>> GA enabled, and all we are doing is accessing a standard web
>page
>>> from
>>>>>>> the
>>>>>>>> Ignite web site. The information gathered from GA is available
>only
>>> to
>>>>>>> the
>>>>>>>> Ignite PMC. Frankly, I think legal@ will be very confused by
>this
>>>>>>>> question.
>>>>>>>> 
>>>>>>>> Even ASF website itself uses GA: https://www.apache.org/
>>>>>>>> foundation/policies/privacy.html
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> I think Cos said it's OK; maybe Roman can pitch in.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> Sure, would be nice to hear from Roman as well.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> Cheers.
>>>>>>>>> 
>>>>>>>>> [1]
>>>>>>>>> https://developers.google.com/analytics/devguides/collection
>>>>>>>>> /analyticsjs/events
>>>>>>>>> 
>>>>>>>>> On Sat, Aug 26, 2017 at 12:23 AM, Dmitriy Setrakyan <
>>>>>>>>> dsetrak...@apache.org <javascript:;>>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Raul,
>>>>>>>>>> 
>>>>>>>>>> Could point about Javascript, it will not work because it
>executes
>>>>>> in
>>>>>>>>> the
>>>>>>>>>> browser. This means we need a server-side script, like CGI we
>are
>>>>>>> using
>>>>>>>>> on
>>>>>>>>>> our download page.
>>>>>>>>>> 
>>>>>>>>>> How about this approach. We create something like
>>> ignite-version.cgi
>>>>>>>>> script
>>>>>>>>>> which will invoke a call to GA and then return the latest
>version.
>>>>>>>>>> 
>>>>>>>>>> This should work, right?
>>>>>>>>>> 
>>>>>>>>>> D.
>>>>>>>>>> 
>>>>>>>>>> On Fri, Aug 25, 2017 at 2:42 PM, Raúl Kripalani <
>>>>>> raul@evosent.com
>>>>>>> <javascript:;>>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Hey Dmitriy and all
>>>>>>>>>>> 
>>>>>>>>>>> Also, since we have GA enabled for the website, we can track
>how
>>>>>>> many
>>>>>>>>>> times
>>&g

Re: [DISCUSS] Ignite Update Checker

[Konstantin Boudnik]

Sorry guys - I neglected the fact that our lists don't permit
attachments. I have put the screenshot to an external server [1]

[1] https://imgur.com/a/p9FJ9

Thank you!
--
  With regards,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Thu, Sep 28, 2017 at 1:37 PM, Denis Magda <dma...@apache.org> wrote:
> Cos,
>
> The screenshot was not attached. Could you share it some other way (google 
> drive, etc.)? I’ve never seen any commercial on the site.
>
> —
> Denis
>
>> On Sep 28, 2017, at 7:23 AM, Konstantin Boudnik <c...@apache.org> wrote:
>>
>> I don't see an issue with node version either.
>>
>> Just one more, and it might be slightly irrelevant, issue though... I looked 
>> at the Ignite's site and found the following ads and trackers (that are 
>> indeed getting disabled by my browser).
>> Why are googleads or doubleclick are permitted?
>>
>>
>>
>> Thanks,
>>   Cos
>>
>>
>> --
>>   With regards,
>> Konstantin (Cos) Boudnik
>> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>>
>> Disclaimer: Opinions expressed in this email are those of the author, and do 
>> not necessarily represent the views of any company the author might be 
>> affiliated with at the moment of writing.
>>
>> On Tue, Sep 26, 2017 at 3:21 PM, Dmitriy Setrakyan <dsetrak...@apache.org 
>> <mailto:dsetrak...@apache.org>> wrote:
>> On Tue, Sep 26, 2017 at 6:20 AM, Vladimir Ozerov <voze...@gridgain.com 
>> <mailto:voze...@gridgain.com>>
>> wrote:
>>
>> > Folks,
>> >
>> > Can we add version of current node to web request? This way we will better
>> > understand version distribution, what might help us with certain API
>> > update/deprecate decisions
>> > E.g. http://ignite.apache.org/latest.cgi=2.2.0 
>> > <http://ignite.apache.org/latest.cgi=2.2.0>
>>
>>
>> Vladimir, I personally do not see a problem with that, as sending the
>> current version to the update checker seems very innocent to me. At the
>> same time, it will allow us to examine the usage of each release and make
>> decisions about dropping backward compatibility or spotting bugs for a
>> certain release.
>>
>> Cos, Raul, any thoughts?
>>
>>
>> >
>> >
>> > Vladimir.
>> >
>> > On Fri, Sep 8, 2017 at 7:06 AM, Dmitriy Setrakyan <dsetrak...@apache.org 
>> > <mailto:dsetrak...@apache.org>>
>> > wrote:
>> >
>> > > I think it is safe to assume at this point that everyone is in general
>> > > agreement, since there are no active objections.
>> > >
>> > > I have filed a ticket for the 2.3 release. Let's try to make it happen:
>> > > https://issues.apache.org/jira/browse/IGNITE-6305 
>> > > <https://issues.apache.org/jira/browse/IGNITE-6305>
>> > >
>> > > D.
>> > >
>> > > On Sat, Aug 26, 2017 at 3:06 PM, Dmitriy Setrakyan <
>> > dsetrak...@apache.org <mailto:dsetrak...@apache.org>>
>> > > wrote:
>> > >
>> > > >
>> > > >
>> > > > On Sat, Aug 26, 2017 at 3:22 AM, Raúl Kripalani <raul@evosent.com 
>> > > > <mailto:raul@evosent.com>>
>> > > > wrote:
>> > > >
>> > > >> Yeah, I guess that's doable as well and requires less management
>> > effort
>> > > >> than my suggestion. We could use events [1] to store payload data
>> > (e.g.
>> > > >> IP,
>> > > >> version, etc.)
>> > > >
>> > > >
>> > > > Yes, we could use events or some other similar API provided by GA.
>> > > >
>> > > >
>> > > >> What the download page CGI developed in? PHP?
>> > > >>
>> > > >
>> > > > To be honest, no clue. I guess someone in the community can figure it
>> > > out:
>> > > > https://svn.apache.org/repos/asf/ignite/site/trunk/download.html 
>> > > > <https://svn.apache.org/repos/asf/ignite/site/trunk/download.html>
>> > > >
>> > > >
>> > > >> However, I'm not sure whether storing this data in a 3rd party
>> > (Google)
>> >

Re: [DISCUSS] Ignite Update Checker

[Konstantin Boudnik]

t;> > browser. This means we need a server-side script, like CGI we are
> > > using
> > > >> on
> > > >> > our download page.
> > > >> >
> > > >> > How about this approach. We create something like
> ignite-version.cgi
> > > >> script
> > > >> > which will invoke a call to GA and then return the latest version.
> > > >> >
> > > >> > This should work, right?
> > > >> >
> > > >> > D.
> > > >> >
> > > >> > On Fri, Aug 25, 2017 at 2:42 PM, Raúl Kripalani <
> > raul@evosent.com
> > > >
> > > >> > wrote:
> > > >> >
> > > >> > > Hey Dmitriy and all
> > > >> > >
> > > >> > > Also, since we have GA enabled for the website, we can track how
> > > many
> > > >> > times
> > > >> > > > this page was accessed, which will be equal to the number of
> > > starts.
> > > >> > This
> > > >> > > > way, the counter information is tracked and monitored by the
> > > Ignite
> > > >> > PMC.
> > > >> > >
> > > >> > >
> > > >> > > Unfortunately this won't work because GA is loaded via
> Javascript
> > on
> > > >> the
> > > >> > > browser, so Google will never receive the page hit.
> > > >> > >
> > > >> > > Given the constraints, the most viable solution is an HTTPS
> > endpoint
> > > >> > > running on ASF infra that Ignite invokes via a GET or POST
> > request.
> > > >> The
> > > >> > > simplest thing is to write each request in a log file, along
> with
> > > the
> > > >> > > timestamp, the version reported by the client, maybe the IP (not
> > > sure
> > > >> > about
> > > >> > > the ASF rules about this concerning privacy, I guess it's OK if
> > you
> > > >> make
> > > >> > it
> > > >> > > an opt-in) and a unique node identifier, i.e. a UUID the node
> > > creates
> > > >> on
> > > >> > > first startup or something.
> > > >> > >
> > > >> > > This endpoint would need some basic DDoS protection and
> > blacklisting
> > > >> to
> > > >> > > prevent data spoofing.
> > > >> > >
> > > >> > > If we'll be implementing this endpoint anyway, then there's no
> > point
> > > >> > > placing another file on Git or elsewhere for reporting the
> latest
> > > >> > versions:
> > > >> > > the endpoint itself can return them.
> > > >> > >
> > > >> > > WDYT?
> > > >> > >
> > > >> > > Cheers.
> > > >> > >
> > > >> > > On Fri, Aug 25, 2017 at 9:56 PM, Dmitriy Setrakyan <
> > > >> > dsetrak...@apache.org>
> > > >> > > wrote:
> > > >> > >
> > > >> > > > Cos, Raul,
> > > >> > > >
> > > >> > > > Thanks for the feedback. I completely agree about Maven
> Central
> > > >> being a
> > > >> > > 3rd
> > > >> > > > party repo (did not think about that initially). All your
> > > >> suggestions
> > > >> > > make
> > > >> > > > sense, but I would like to keep it as simple as possible, and
> so
> > > far
> > > >> > > > everything suggested required GIT dependencies and extra work.
> > > >> > > >
> > > >> > > > How about Yakov's suggestion. We simply add a page to the
> Ignite
> > > >> > website
> > > >> > > > which will have only the latest version. Every time a node
> > starts,
> > > >> it
> > > >> > > > receives the latest version from the page and suggests that
> > users
> > > >> > upgrade
> > > >> > > > if needed.
> > > >> > > >
> > > >> > > > Also, since we have GA enabled for the website, we can track
> how
> > > >> many
> > > >> &

Re: Ignite Benchmarking Rules

[Konstantin Boudnik]

Yes, we do. A team within AWS org wanted to contribute to the project
and they are run a few machines for us. There's no money going back
and forth, we are "just" using some of the resources.

I guess the best way to get a few servers is to find people @Amazon,
who'd be willing to make such donation to the project.
--
  With regards,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Sat, Sep 16, 2017 at 12:06 AM, Dmitriy Setrakyan
 wrote:
> Cos,
>
> I think Apache BigTop is using servers provided by Amazon. Can you make a
> suggestion on how can Ignite community get a few servers from Amazon for
> benchmarking as well?
>
> D.
>
> On Fri, Sep 15, 2017 at 5:57 AM, Anton Vinogradov  wrote:
>>
>> Guys,
>>
>> I fully agree that configured servers at Amazon is the best choice.
>>
>> But when you need to check that your changes has no performance drop
>> you're
>> able to use your own PC or PCs to checks that.
>> All you need is to benchmark already released version vs version with your
>> fix at same environment.
>>
>> So, seems we should have couple of configuration recommendations
>> - reasonable for standalone PC
>> - reasonable for cluster
>>
>> On Fri, Sep 15, 2017 at 12:20 PM, Nikolay Izhikov 
>> wrote:
>>
>> > Hello, Dmitriy.
>> >
>> > I think experienced members of community have specific number for
>> > benchmarking.
>> >
>> > Can we start from reference hardware configuration: Num of CPU, RAM and
>> > HDD(SDD?) configuration, network configs, etc.
>> >
>> > Can someone share that kind of knowledge - Which hardware is best for
>> > Ignite benchmarking?
>> >
>> > I found some numbers here - [1]. Is it well suited for Apache Ignite?
>> >
>> > [1] https://www.gridgain.com/resources/benchmarks/gridgain-vs-
>> > hazelcast-benchmarks
>> >
>> > 14.09.2017 23:27, Dmitriy Setrakyan пишет:
>> >
>> > Alexey, I completely agree. However, for the benchmarks to be useful,
>> > then
>> >> need to be run on the same hardware all the time. Apache Ignite does
>> >> not
>> >> have servers sitting around, available to run the benchmarks.
>> >>
>> >> Would be nice to see how other projects address it. Can Amazon donate
>> >> servers for the Apache projects?
>> >>
>> >> D.
>> >>
>> >> On Thu, Sep 14, 2017 at 6:25 AM, Aleksei Zaitsev
>> >> 
>> >> wrote:
>> >>
>> >> Hi, Igniters.
>> >>>
>> >>> Recently I’ve done some research in benchmarks for Ignite, and noticed
>> >>> that we don’t have any rules for running benchmarks and collecting
>> >>> result
>> >>> from them. Although sometimes we have tasks, which results need to be
>> >>> measured. I propose to formalize such things as:
>> >>>   * set of benchmarks,
>> >>>   * parameters of launching them,
>> >>>   * way of result collection and interpretation,
>> >>>   * Ignite cluster configuration.
>> >>>
>> >>> I don’t think that we need to run benchmarks before every merge into
>> >>> master, but in some cases it should be mandatory to compare new
>> >>> results
>> >>> with reference values to be sure that changes do not lead to the
>> >>> performance degradation.
>> >>>
>> >>> What do you think?
>> >>>
>> >>>
>> >>
>
>

Re: Durable Memory and Ignite Persistence Tuning

[Konstantin Boudnik]

Just to spice it up: in my experience, having a few hundred parameters one can
tweak (I am making up the number here) is a tough UX call. In JVM, we had a
team that worked on heuristics that would auto-tune a bunch of things during
the VM startup. Hence, providing the best user experience in most cases.

Do you think something like this is feasible in case of persistence
functionality? Documenting it first is a great first step, but perhaps
wrapping this knowledge into some soft of code, would be even better.

I do have an anecdotal evidence where an experienced Ignite developer
tried to implement a message processing system with Ignite 2.0. After a week
of getting nowhere performance wise, he dropped it and implemented something
custom with Java and nothing else. Take it or leave it: that's why I called
this "anecdotal" in the first place.

Speaking strictly for myself: when I come across blog posts about tuning of
Apache Kudu or Apache Impala the skin on the back of head starts crawling. I
imagine 95% of the potential users of these applications would turn away right
at that point. If the system doesn't work well enough out of the box - screw
it, there's 355 other alternatives available in the FOSS market.

Thoughts?
  Cos

On Fri, Sep 01, 2017 at 11:08AM, Denis Magda wrote:
> Igniters,
> 
> I see a lot of complains regarding the performance of the subj on the user
> list. At the same time, I do believe that in most scenarios it’s a lack of
> knowledge that we keep in secret.
> 
> It's time to document Durable Memory and its Native Persistence tuning
> parameters. Let's start doing this for Linux based deployments first. Here
> is what we have for now (which is almost nothing):
> https://apacheignite.readme.io/docs/durable-memory-tuning
> 
> 
> Ideally, at some point we have to come up with doc like this:
> https://access.redhat.com/sites/default/files/attachments/deploying-oracle-12c-on-rhel6_1.2_1.pdf
> 
> Please share your expertise in a form of settings that have to be put on the
> paper. We put them in JIRA and document afterwords:
> https://issues.apache.org/jira/browse/IGNITE-6246
> 
> 
> —
> Denis


signature.asc
Description: Digital signature

Re: [DISCUSS] Ignite Update Checker

[Konstantin Boudnik]

This will surely works to get the update info to the nodes. And it
sounds like a legit approach.
I cannot judge on the feasibility of the GA though - don't know squat
about it ;)

Thanks!
--
  With regards,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Fri, Aug 25, 2017 at 1:56 PM, Dmitriy Setrakyan
<dsetrak...@apache.org> wrote:
> Cos, Raul,
>
> Thanks for the feedback. I completely agree about Maven Central being a 3rd
> party repo (did not think about that initially). All your suggestions make
> sense, but I would like to keep it as simple as possible, and so far
> everything suggested required GIT dependencies and extra work.
>
> How about Yakov's suggestion. We simply add a page to the Ignite website
> which will have only the latest version. Every time a node starts, it
> receives the latest version from the page and suggests that users upgrade
> if needed.
>
> Also, since we have GA enabled for the website, we can track how many times
> this page was accessed, which will be equal to the number of starts. This
> way, the counter information is tracked and monitored by the Ignite PMC.
>
> This approach looks pretty innocent to me and everything is kept and
> managed within Apache.
>
> Thoughts?
>
> D.
>
>
> On Fri, Aug 25, 2017 at 11:29 AM, Konstantin Boudnik <c...@apache.org> wrote:
>
>> I agree with Raul.
>> - providing a ping-back address to a 3rd party might be frown upon by some.
>>   And might have a consequences like stats collection about users'
>>   infrastructure.
>> - checking an ASF git-repo is easy and won't download any binary data:
>>   everything is clear text and could be easily monitored by any of the
>> network
>>   diagnostic tools, shall it be required. But it involves a bit of the
>> release
>>   discipline.
>> - the binary data download in the runtime is my main concern. This is the
>>   vector of MMA. What if someone gains the control over the repository and
>>   replaces the file with some malicious content.
>>
>> As for the particular mechanism: IIRC Ignite used to make a call to an
>> external script to check upon the atest software version available for
>> download. In the past, the endpoint was running on a 3rd party server, I
>> believe the best way would be to put this script on ASF infra and have the
>> "update checker" running in a completely controlled environment. Actually,
>> I
>> recall we had this very discussion during the Incubation; I can probably
>> dig
>> out the corresponding thread.
>>
>> Thoughts?
>>   Cok
>>
>> On Fri, Aug 25, 2017 at 10:41AM, Raul Kripalani wrote:
>> > Hey guys
>> >
>> > In my opinion, maven.org is still owned by a third party (Sonatype). We
>> > don't know what kind of data analysis or intelligence extraction they
>> run.
>> >
>> > If Ignite servers all over the world were hitting maven.org periodically
>> > asking for an Ignite Maven artifact, it gives Sonatype a clear indication
>> > of who is running an Ignite server.
>> >
>> > They could reverse lookup the IP address and find out what corporation it
>> > is.
>> >
>> > How about having Ignite check the ASF Git directly?
>> >
>> > We could use the Git ssh API, but that would require a new dependency,
>> > which I advise against.
>> >
>> > Alternatively, we could have it scrape this HTML for new Git tags:
>> > https://git-wip-us.apache.org/repos/asf?p=ignite.git
>> >
>> > Another option is to place a txt file in the root of the master branch
>> (e.g
>> > LATEST), containing a list of the latest GA versions for each major
>> version
>> > line (1.x, 2.x).
>> >
>> > I would advocate this last option, but it requires somebody remembering
>> to
>> > update the file with every release, unless we automate it with a Maven
>> > plugin.
>> >
>> > Hope that helps!
>> >
>> >
>> > On 24 Aug 2017 19:37, "Denis Magda" <dma...@apache.org> wrote:
>> >
>> > I see nothing wrong with this approach.
>> >
>> > Cos, Roman, Raul, as Apache veterans, what do you think? Is it good to
>> go?
>> >
>> > —
>> > Denis
>> >
>> > > On Aug 23, 2017, at 11:17 PM, Dmitriy Setrakyan <dsetrak...@apache.org
>> >
&

Re: [DISCUSS] Ignite Update Checker

[Konstantin Boudnik]

I agree with Raul.
- providing a ping-back address to a 3rd party might be frown upon by some.
  And might have a consequences like stats collection about users'
  infrastructure.
- checking an ASF git-repo is easy and won't download any binary data:
  everything is clear text and could be easily monitored by any of the network
  diagnostic tools, shall it be required. But it involves a bit of the release
  discipline.
- the binary data download in the runtime is my main concern. This is the
  vector of MMA. What if someone gains the control over the repository and
  replaces the file with some malicious content.

As for the particular mechanism: IIRC Ignite used to make a call to an
external script to check upon the atest software version available for
download. In the past, the endpoint was running on a 3rd party server, I
believe the best way would be to put this script on ASF infra and have the
"update checker" running in a completely controlled environment. Actually, I
recall we had this very discussion during the Incubation; I can probably dig
out the corresponding thread.

Thoughts?
  Cok

On Fri, Aug 25, 2017 at 10:41AM, Raul Kripalani wrote:
> Hey guys
> 
> In my opinion, maven.org is still owned by a third party (Sonatype). We
> don't know what kind of data analysis or intelligence extraction they run.
> 
> If Ignite servers all over the world were hitting maven.org periodically
> asking for an Ignite Maven artifact, it gives Sonatype a clear indication
> of who is running an Ignite server.
> 
> They could reverse lookup the IP address and find out what corporation it
> is.
> 
> How about having Ignite check the ASF Git directly?
> 
> We could use the Git ssh API, but that would require a new dependency,
> which I advise against.
> 
> Alternatively, we could have it scrape this HTML for new Git tags:
> https://git-wip-us.apache.org/repos/asf?p=ignite.git
> 
> Another option is to place a txt file in the root of the master branch (e.g
> LATEST), containing a list of the latest GA versions for each major version
> line (1.x, 2.x).
> 
> I would advocate this last option, but it requires somebody remembering to
> update the file with every release, unless we automate it with a Maven
> plugin.
> 
> Hope that helps!
> 
> 
> On 24 Aug 2017 19:37, "Denis Magda"  wrote:
> 
> I see nothing wrong with this approach.
> 
> Cos, Roman, Raul, as Apache veterans, what do you think? Is it good to go?
> 
> —
> Denis
> 
> > On Aug 23, 2017, at 11:17 PM, Dmitriy Setrakyan 
> wrote:
> >
> > Is everyone OK with this approach? Should I file a ticket on it?
> >
> > On Mon, Aug 21, 2017 at 2:07 PM, Dmitriy Setrakyan 
> > wrote:
> >
> >> Igniters,
> >>
> >> There has been lots of talk of proposals about various usage metrics for
> >> Ignite and nothing came of it. I would like to resurrect the topic and
> >> propose something very simple and non-intrusive.
> >>
> >> 1. Update Checker
> >> The main purpose of the update checker is not to collect metrics, but to
> >> notify users about a new version of Ignite by accessing maven.org and
> >> getting the version out of the metadata file:
> >> http://repo2.maven.org/maven2/org/apache/ignite/ignite-core/
> >> maven-metadata.xml
> >>
> >> This way we do not send any information anywhere and, at the same time,
> >> urge our users to download and start using the latest version of Ignite.
> >>
> >> 2. Startup Counter
> >> This piece is optional, but we can also get an insight in how many times
> a
> >> certain Ignite release gets started. This is just a cool metric for the
> >> community to gauge the project popularity. You can think of it as of a
> page
> >> visit counter shown on many websites. We can even decide to display this
> >> counter on the Ignite website as well.
> >>
> >> To do this, we can simply add a JAR in maven for every release, e.g.
> >> ignite-start-counter.jar, which will contain only 1 byte. Every time an
> >> Ignite node starts, it will download this JAR in the background. Then we
> >> will be able to view the number of the total downloads for this JAR in
> >> Maven Central, which is essentially the number of starts of Ignite nodes.
> >>
> >> *Note that neither of the above suggestions require Ignite to send or
> >> track any user information whatsoever.*
> >>
> >> Please reply suggesting weather you are OK with this approach.
> >>
> >> D.
> >>



signature.asc
Description: Digital signature

Re: [Webinar] Apache Process Overview, Aug 10, 2017 9.00 AM - 10.00 AM PT

[Konstantin Boudnik]

Thanks for posting the recording, guys!

Here are the slides to go with it [1]

[1] https://mega.nz/#!Bp0xAYYC!IntSc8idFUKRgw0Nr04q1HJWGHTw5mxS3pp5nKlI4_M
--
  With regards,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Tue, Aug 15, 2017 at 2:46 PM, Denis Magda <dma...@apache.org> wrote:
> Igniters,
>
> Those who missed the webinar can watch the recoding:
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-ApacheWay
>  
> <https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-ApacheWay>
>
> Cos, thanks a lot for presentation!
>
> —
> Denis
>
>> On Aug 8, 2017, at 10:55 AM, Dmitriy Setrakyan <dsetrak...@apache.org> wrote:
>>
>> I have tried to send a google invite to the dev list. Never done it before,
>> so let's see if it works.
>>
>> D.
>>
>> On Tue, Aug 8, 2017 at 9:13 AM, Konstantin Boudnik <c...@apache.org> wrote:
>>
>>> A reminder to register for the webinar if you're interested.
>>> --
>>>  With regards,
>>> Konstantin (Cos) Boudnik
>>> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>>>
>>> Disclaimer: Opinions expressed in this email are those of the author,
>>> and do not necessarily represent the views of any company the author
>>> might be affiliated with at the moment of writing.
>>>
>>>
>>> On Tue, Aug 1, 2017 at 11:07 AM, Denis Magda <dma...@apache.org> wrote:
>>>> Igniters,
>>>>
>>>> The practice shows that regardless of Ignite’s project maturity we as a
>>> community still miss some valuable points and principles on different
>>> occasions violating the ASF processes.
>>>>
>>>> Cos Boudnik as one of the oldest ASF and Ignite members agreed to
>>> conduct a global webinar reiterating over the main ASF principles,
>>> processes and rules we as a community has to comply with.
>>>>
>>>> That webinar will be useful for all of use without exception — new
>>> contributors who have just joined Ignite family and old long-beard
>>> committers.
>>>>
>>>> The webinar details:
>>>>
>>>> ——
>>>>
>>>> Changed: Apache Process Overview
>>>> Thu, Aug 10, 2017 9.00 AM - 10.00 AM PT (Pacific Time!)
>>>> Thu, Aug 10, 2017 7:00 PM - 8:00 PM MSK (Moscow Time!)
>>>>
>>>> Please join my meeting from your computer, tablet or smartphone.
>>>> https://global.gotomeeting.com/join/995507229
>>>>
>>>> You can also dial in using your phone.
>>>> United States: +1 (786) 535-3211
>>>>
>>>> Access Code: 995-507-229
>>>>
>>>> First GoToMeeting? Try a test session: https://care.citrixonline.com/
>>> g2m/getready
>>>>
>>>> ———
>>>>
>>>> —
>>>> Denis
>>>
>

Re: release procedure

[Konstantin Boudnik]

There's also #4:
 - providing an official environment, comprised of the toolchain,
compilers, libs, etc,. The same environment (read "a container") could
be used by an individual developer, RM, and/or in CI system for
builds, tests, etc. And then you can have #3 pretty much for free!

We are doing this in Bigtop for a much more complex environment, set
of components and supported OS. I am sure it would be easy to do in
Ignite.
--
  With regards,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Sun, Aug 6, 2017 at 5:37 AM, Oleg Ostanin  wrote:
> Hi,
>
> I'd like to start a discussion about Apache Ignite release procedure.
>
> I'm working on ticket Ignite-5249 "The release build procedure should be
> placed on the CI/CD server and available to run for the release engineer."
>
> https://issues.apache.org/jira/browse/IGNITE-5249
>
> Currently we have three options for release:
>
> 1. Release engineer can do all the necessary steps on his local machine. It
> will require installing tons of soft like maven, doxigen, candle and so on.
> Also building .net part of the project will require access to Windows OS.
> Build steps will not be transparent for community. Environment will not be
> the same for each release which can lead to the compatibility issues.
>
> 2. All the steps (including signing) can be done on the public continuous
> integration server. Environment will be the same for each release, all the
> steps will be transparent for community, but it will require uploading at
> least one private gpg certificate on the server. This is the high security
> risk and I'm mentioning this option only for the sake of completeness.
>
> 3. Building of the project can be performed on the public continuous
> integration server and then artifacts can be downloaded on the local
> machine and signed and deployed to the staging repository from that local
> machine by running maven commands. No sharing of any credentials and
> certificates will be needed, environment will be the same for each release,
> all the steps will be transparent for community, artifacts created on the
> CI server can be verified by check-sums after uploading to the repository.
>
> Please, let me know if you have any suggestion or any questions about
> anything related.

Re: [Webinar] Apache Process Overview, Aug 10, 2017 9.00 AM - 10.00 AM PT

[Konstantin Boudnik]

A reminder to register for the webinar if you're interested.
--
  With regards,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Tue, Aug 1, 2017 at 11:07 AM, Denis Magda  wrote:
> Igniters,
>
> The practice shows that regardless of Ignite’s project maturity we as a 
> community still miss some valuable points and principles on different 
> occasions violating the ASF processes.
>
> Cos Boudnik as one of the oldest ASF and Ignite members agreed to conduct a 
> global webinar reiterating over the main ASF principles, processes and rules 
> we as a community has to comply with.
>
> That webinar will be useful for all of use without exception — new 
> contributors who have just joined Ignite family and old long-beard committers.
>
> The webinar details:
>
> ——
>
> Changed: Apache Process Overview
> Thu, Aug 10, 2017 9.00 AM - 10.00 AM PT (Pacific Time!)
> Thu, Aug 10, 2017 7:00 PM - 8:00 PM MSK (Moscow Time!)
>
> Please join my meeting from your computer, tablet or smartphone.
> https://global.gotomeeting.com/join/995507229
>
> You can also dial in using your phone.
> United States: +1 (786) 535-3211
>
> Access Code: 995-507-229
>
> First GoToMeeting? Try a test session: 
> https://care.citrixonline.com/g2m/getready
>
> ———
>
> —
> Denis

Re: [RESULT] [VOTE] Apache Ignite 2.1.0 Release (RC4)

[Konstantin Boudnik]

thanks for checking!
Technically, speaking we were voting on a different zip-file, that has
been signed by the release manager. So, I am not sure what was the
point of posting rc3 to the dist, instead of rc4. Unless of course the
following statement
> The artifacts has been upload for RC3 and due to no code changes for RC4 they 
> not updated
was groundless.

You see where I am going with this?
--
  With regards,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Mon, Jul 31, 2017 at 12:21 PM, Anton Vinogradov <a...@apache.org> wrote:
> Cos,
>
> I see that artifacts and checksums are the same:
>
> https://dist.apache.org/repos/dist/dev/ignite/?p=20551
>
> RC3:
> md5 -> 3cd75e1f4e402d8c93b155386afe675c  apache-ignite-2.1.0-src.zip
> (https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc3/apache-ignite-2.1.0-src.zip.md5?p=20551)
> sha -> b60e95130a6ba758fdf48b8261ac2cd028278f23  apache-ignite-2.1.0-src.zip
> (https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc3/apache-ignite-2.1.0-src.zip.sha1?p=20551)
>
> RC4:
> md5 -> 3cd75e1f4e402d8c93b155386afe675c  apache-ignite-2.1.0-src.zip
> (https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc4/apache-ignite-2.1.0-src.zip.md5?p=20551)
> sha -> b60e95130a6ba758fdf48b8261ac2cd028278f23  apache-ignite-2.1.0-src.zip
> (https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc4/apache-ignite-2.1.0-src.zip.sha1?p=20551)
>
>
> Svn log for RC4 -> 2.1.0:
>
> Revision: 20651
> Author: av
> Date: 27 июля 2017 г. 18:15:43
> Message:
> Release 2.1.0-rc4
> 
> Deleted : /dev/ignite/2.1.0-rc4
> Added : /release/ignite/2.1.0 (Copy from path: /dev/ignite/2.1.0-rc4,
> Revision, 20650)
>
> On Mon, Jul 31, 2017 at 8:37 PM, Konstantin Boudnik <c...@apache.org> wrote:
>>
>> Wait, the artifacts for RC3 were signed differently and had different
>> checksums than those of RC4. Why the former is now are the official
>> release artifact if that [VOTE] has been cancelled?
>> --
>>   With regards,
>> Konstantin (Cos) Boudnik
>> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>>
>> Disclaimer: Opinions expressed in this email are those of the author,
>> and do not necessarily represent the views of any company the author
>> might be affiliated with at the moment of writing.
>>
>>
>> On Sat, Jul 29, 2017 at 9:17 AM, Sergey Kozlov <skoz...@gridgain.com>
>> wrote:
>> > Denis, that's true.
>> >
>> > The artifacts has been upload for RC3 and due to no code changes for RC4
>> > they not updated
>> >
>> > On Sat, Jul 29, 2017 at 5:09 PM, Denis Magda <dma...@gridgain.com>
>> > wrote:
>> >
>> >> I guess that's the JAR's creation time by the build procedure and not
>> >> the
>> >> uploading time. Looks valid to me.
>> >>
>> >> Denis
>> >>
>> >> On Saturday, July 29, 2017, 李玉珏@163 <18624049...@163.com> wrote:
>> >>
>> >> > Anton,
>> >> >
>> >> >
>> >> > http://repo.maven.apache.org/maven2/org/apache/ignite/ignite-core/2.1.0/
>> >> >
>> >> > The timestamp for uploading the artifact is 2017-07-20 17:35, Is that
>> >> > correct?
>> >> >
>> >> >
>> >> > 在 2017/7/28 上午2:06, Anton Vinogradov 写道:
>> >> >
>> >> >> Done.
>> >> >>
>> >> >> - Maven artifacts released
>> >> >> - Sources released
>> >> >> - Site updated
>> >> >> - Git tag added
>> >> >>
>> >> >> On Thu, Jul 27, 2017 at 4:24 PM, Anton Vinogradov <a...@apache.org>
>> >> wrote:
>> >> >>
>> >> >> Igniters,
>> >> >>>
>> >> >>> Apache Ignite 2.1.0 release (RC4) has been accepted.
>> >> >>>
>> >> >>> 7 "+1" votes received:
>> >> >>>
>> >> >>> - Valentin Kulichenko (binding)
>> >> >>> - Nikolai Tikhonov (binding)
>> >> >>> - Alexey Kuznetsov (binding)
>> >> >>> - Yakov Zhdanov (binding)
>> >> >>> - Konstantin Boudnik (binding)
>> >> >>> - Andrey Gura (binding)
>> >> >>> - Denis Magda (binding)
>> >> >>>
>> >> >>> Vote thread:
>> >> >>>
>> >> >>> http://apache-ignite-developers.2346864.n4.nabble.
>> >> >>> com/VOTE-Apache-Ignite-2-1-0-RC4-td19969.html
>> >> >>>
>> >> >>> Ignite 2.1.0 will be released soon. Woohoo!
>> >> >>>
>> >> >>>
>> >> >
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > Sergey Kozlov
>> > GridGain Systems
>> > www.gridgain.com
>
>

Re: [RESULT] [VOTE] Apache Ignite 2.1.0 Release (RC4)

[Konstantin Boudnik]

Wait, the artifacts for RC3 were signed differently and had different
checksums than those of RC4. Why the former is now are the official
release artifact if that [VOTE] has been cancelled?
--
  With regards,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Sat, Jul 29, 2017 at 9:17 AM, Sergey Kozlov <skoz...@gridgain.com> wrote:
> Denis, that's true.
>
> The artifacts has been upload for RC3 and due to no code changes for RC4
> they not updated
>
> On Sat, Jul 29, 2017 at 5:09 PM, Denis Magda <dma...@gridgain.com> wrote:
>
>> I guess that's the JAR's creation time by the build procedure and not the
>> uploading time. Looks valid to me.
>>
>> Denis
>>
>> On Saturday, July 29, 2017, 李玉珏@163 <18624049...@163.com> wrote:
>>
>> > Anton,
>> >
>> > http://repo.maven.apache.org/maven2/org/apache/ignite/ignite-core/2.1.0/
>> >
>> > The timestamp for uploading the artifact is 2017-07-20 17:35, Is that
>> > correct?
>> >
>> >
>> > 在 2017/7/28 上午2:06, Anton Vinogradov 写道:
>> >
>> >> Done.
>> >>
>> >> - Maven artifacts released
>> >> - Sources released
>> >> - Site updated
>> >> - Git tag added
>> >>
>> >> On Thu, Jul 27, 2017 at 4:24 PM, Anton Vinogradov <a...@apache.org>
>> wrote:
>> >>
>> >> Igniters,
>> >>>
>> >>> Apache Ignite 2.1.0 release (RC4) has been accepted.
>> >>>
>> >>> 7 "+1" votes received:
>> >>>
>> >>> - Valentin Kulichenko (binding)
>> >>> - Nikolai Tikhonov (binding)
>> >>> - Alexey Kuznetsov (binding)
>> >>> - Yakov Zhdanov (binding)
>> >>> - Konstantin Boudnik (binding)
>> >>> - Andrey Gura (binding)
>> >>> - Denis Magda (binding)
>> >>>
>> >>> Vote thread:
>> >>>
>> >>> http://apache-ignite-developers.2346864.n4.nabble.
>> >>> com/VOTE-Apache-Ignite-2-1-0-RC4-td19969.html
>> >>>
>> >>> Ignite 2.1.0 will be released soon. Woohoo!
>> >>>
>> >>>
>> >
>> >
>>
>
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com

Re: Apache Ignite Site Changed its Face

[Konstantin Boudnik]

Arguably, the website and its theme represents the projects' message.
And should be reflecting that of the community, and not just the
people who happen to be working on the changes in the website code.

Fixing existing or adding new content is different story: have a JIRA,
fix and commit it. Changing the style, content and the overall message
(in this case: "Ignite is now an in-memory DB") looks like a perfect
candidate to reach out for the consensus first. Consensus building
isn't an "extra noise", really.
--
  With regards,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Fri, Jul 28, 2017 at 5:42 PM, Denis Magda <dma...@gridgain.com> wrote:
> The site and documentation is improved almost in per day basis. I spot the
> changes happened to the project on @dev and @user and adjust the materials
> and site to reflect them with the help of contributirs and committers who
> worked on a specific functionality. Don't see much sense to generate extra
> noise while that work is in progress.
>
> That's exactly what happened to the front page. The new memory architecture
> and the persistent store was discussed on @dev before many times and the
> site was updated accordingly.
>
> --
> Denis
>
>
> On Friday, July 28, 2017, Konstantin Boudnik <c...@apache.org> wrote:
>>
>> Was there any discussion here on dev@ about this change? Just curious
>> if my search-foo is failing me...
>>
>> Thanks!
>> --
>>   With regards,
>> Konstantin (Cos) Boudnik
>> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>>
>> Disclaimer: Opinions expressed in this email are those of the author,
>> and do not necessarily represent the views of any company the author
>> might be affiliated with at the moment of writing.
>>
>>
>> On Thu, Jul 27, 2017 at 2:32 PM, Denis Magda <dma...@apache.org> wrote:
>> > Igniters,
>> >
>> > In favor of the 2.1 release we’ve reworked and renewed the front page
>> > and some of the existing pages of the site:
>> > https://ignite.apache.org
>> >
>> > The front page reflects the main additions of 2.1, durable memory +
>> > persistent store, that opened new opportunities for Ignite. Please welcome
>> > new Ignite that “provides in-memory performance with the durability of
>> > disk”:
>> > https://twitter.com/denismagda/status/890683287852601345
>> >
>> > —
>> > Denis

Re: Apache Ignite Site Changed its Face

[Konstantin Boudnik]

Arguably, the website and its theme represents the projects' message.
And should be reflecting that of the community, and not just the
people who happen to be working on the changes in the website code.

Fixing existing or adding new content is different story: have a JIRA,
fix and commit it. Changing the style, content and the overall message
(in this case: "Ignite is now an in-memory DB") looks like a perfect
candidate to reach out for the consensus first.

--
  With regards,
Konstantin (Cos) Boudnik


On Fri, Jul 28, 2017 at 5:42 PM, Denis Magda <dma...@gridgain.com> wrote:
> The site and documentation is improved almost in per day basis. I spot the
> changes happened to the project on @dev and @user and adjust the materials
> and site to reflect them with the help of contributirs and committers who
> worked on a specific functionality. Don't see much sense to generate extra
> noise while that work is in progress.
>
> That's exactly what happened to the front page. The new memory architecture
> and the persistent store was discussed on @dev before many times and the
> site was updated accordingly.
>
> --
> Denis
>
>
> On Friday, July 28, 2017, Konstantin Boudnik <c...@apache.org> wrote:
>>
>> Was there any discussion here on dev@ about this change? Just curious
>> if my search-foo is failing me...
>>
>> Thanks!
>> --
>>   With regards,
>> Konstantin (Cos) Boudnik
>> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>>
>> Disclaimer: Opinions expressed in this email are those of the author,
>> and do not necessarily represent the views of any company the author
>> might be affiliated with at the moment of writing.
>>
>>
>> On Thu, Jul 27, 2017 at 2:32 PM, Denis Magda <dma...@apache.org> wrote:
>> > Igniters,
>> >
>> > In favor of the 2.1 release we’ve reworked and renewed the front page
>> > and some of the existing pages of the site:
>> > https://ignite.apache.org
>> >
>> > The front page reflects the main additions of 2.1, durable memory +
>> > persistent store, that opened new opportunities for Ignite. Please welcome
>> > new Ignite that “provides in-memory performance with the durability of
>> > disk”:
>> > https://twitter.com/denismagda/status/890683287852601345
>> >
>> > —
>> > Denis

Re: сhecksum algorythm

[Konstantin Boudnik]

That won't guarantee the right choice, unfortunately. Some of the
popular projects are still using md5 ;(
Why not going with sha-512? This is release checksum'ing - we don't
care about computational difficulties nor efficiencies. It is done one
every few months. And we care in this case is the correctness and
robustness.
--
  With regards,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Thu, Jul 27, 2017 at 6:28 AM, Anton Vinogradov
 wrote:
> Oleg,
>
> Let's check what's used at another popular Apache Projects.
>
> On Wed, Jul 26, 2017 at 11:10 PM, Dmitry Pavlov 
> wrote:
>
>> Hi Oleg,
>>
>> Both MD5 and SHA1 are deprecated and can't be considered as trustfull.
>>
>> I think at-least-256 bit member of the SHA-2 family (e. g. sha512) should
>> be used.
>>
>> Sincerely,
>> Dmitriy Pavlov
>>
>> ср, 26 июл. 2017 г. в 22:27, Oleg Ostanin :
>>
>> > Hi,
>> >
>> > We need to decide what сhecksum algorythm we should use for signing
>> release
>> > artifacts. Currently we use md5 and sha-1. sha-1 will be replaced by
>> > sha-256 soon. Should we keep md5 or use only sha-256?
>> >
>>

Re: SSL certificate for the CI server

[Konstantin Boudnik]

Good point! Thanks! Please let me know if you need any assistance from me
--
  With regards,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Wed, Jul 26, 2017 at 2:29 AM, Aleksey Chetaev <alex.chet...@gmail.com> wrote:
> Konstantin,
> Ok, no objections from my side. I need some times for read documentation. I
> hope we will finished in two weeks.
>
> http://reviews.ignite.apache.org - will setup for ssl using too.
>
>
>
> Konstantin Boudnik-2 wrote
>> I have never heard about this provider, and it is great they are donating
>> their resources to the FOSS. I quick glance on their site has reveiled a
>> couple of issues:
>> - the page for the "Standard Agreement" returns 404 [1]. I won't be
>> willing to
>>   agree to something I cannot read upfront.
>> - the process seems to be manual.
>>
>> The reason I like [2] is because it's backed by EFF and has a huge user
>> base
>> (over 100 millions certificates to date) [3]
>>
>> The process has been debugged already for other Apache projects, so I
>> don't
>> really see why we need to go to someone else?
>>
>> [1]
>> https://www.globalsign.com/en/repository/globalsign-subscriber-agreement-digital-certificates-and-services.pdf
>> [2] https://letsencrypt.org/
>> [3]
>> https://www.eff.org/deeplinks/2017/06/lets-encrypt-has-issued-100-million-certificates
>>
>> Thanks,
>>   Cos
>>
>> On Wed, Jul 19, 2017 at 09:41PM, Aleksey Chetaev wrote:
>>> Hi,
>>>
>>> A know GlobalSing support open source projects for
>>> free(https://www.globalsign.com/en/ssl/ssl-open-source/).
>>> We can request certificates from them, it will be more easy for me. Any
>>> objection?
>>>
>>>
>>> Denis Magda-2 wrote
>>> > Hi Cos,
>>> >
>>> > Alexey Chetaev, please join the conversation and share your thoughts on
>>> > this.
>>> >
>>> > —
>>> > Denis
>>> >
>>> >> On Jul 19, 2017, at 9:44 AM, Konstantin Boudnik 
>>>
>>> > cos@
>>>
>>> >  wrote:
>>> >>
>>> >> Hey guys.
>>> >>
>>> >> I've noticed that https://ci.ignite.apache.org/ has two issues:
>>> >> - it has the invalid certificate
>>> >> - the CI server isn't responding on the https port (there's only
>>> ngnix)
>>> >>
>>> >> I don't about the rest of the group here, but all my browsers are
>>> >> enforcing
>>> >> HTTPS connections for the obvious reasons. I have to add an exception
>>> >> for the CI server to get in, which is a minor inconvenience compared
>>> to
>>> >> the
>>> >> security risks. I suggest we fix both issues.
>>> >> 1. Getting a valid certificate is easy and doesn't cost a dime
>>> nowadays.
>>> >>   Here's the very details set of instructions on how we do it for
>>> Apache
>>> >>   Bigtop. They are easily applicable in Ignite CI's case [1]. I'd be
>>> >> happy to
>>> >>   help with this.
>>> >> 2. Reconfiguring the server to respond only on HTTPS port. That's
>>> another
>>> >> easy
>>> >>   thing to do for anyone with the access to the box. I don't have
>>> this,
>>> >> so
>>> >>   it'd be someone else.
>>> >>
>>> >> Thoughts?
>>> >>  Cos
>>> >>
>>> >> [1]
>>> >>
>>> https://cwiki.apache.org/confluence/display/BIGTOP/Bigtop+CI+Setup+Guide#BigtopCISetupGuide-Advancedpart:SetupaSSLsecuredJenkinsmaster
>>> >>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://apache-ignite-developers.2346864.n4.nabble.com/SSL-certificate-for-the-CI-server-tp19830p19840.html
>>> Sent from the Apache Ignite Developers mailing list archive at
>>> Nabble.com.
>>
>>
>> signature.asc (237 bytes)
>> http://apache-ignite-developers.2346864.n4.nabble.com/attachment/19933/0/signature.asc;
>
>
>
>
>
> --
> View this message in context: 
> http://apache-ignite-developers.2346864.n4.nabble.com/SSL-certificate-for-the-CI-server-tp19830p20066.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Re: [VOTE] Apache Ignite 2.1.0 RC4

[Konstantin Boudnik]

+1 [binding]

- Checked the signature
- Checked the sha1
- Successfully ran the build
- RAT is clean

Things that need to be improved in the next release:
- neither sha1 nor md5 are trustful checksum'ing methods and aren't
  guaranteeing the authenticity of the source archive. We should be switching
  to at least sha265 or higher. This has been brought up since the incubation.
  And warrants for -1 in the next release.

Cos

On Mon, Jul 24, 2017 at 04:32PM, Anton Vinogradov wrote:
> Igniters,
> 
> This vote based on same files as RC3.
> Only one change is that I signed zips with my signature.
> KEYS files (https://dist.apache.org/repos/dist/release/ignite/KEYS) was
> updated as well.
> 
> We already got 5 "+1" at RC3, so, is there any reason to wait 72 hours?
> This vote will go for 72 hours but may be closed earlier if Konstantin
> Boudnik confirmed security issue solved.
> 
> We have uploaded a 2.1.0 release candidate to
> https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc4/
> 
> Git tag name is
> 2.1.0-rc4
> 
> This release includes the following changes:
> 
> Ignite:
> * Persistent cache store
> * Added IgniteFuture.listenAsync() and IgniteFuture.chainAsync() mehtods
> * Deprecated IgniteConfiguration.marshaller
> * Updated Lucene dependency to version 5.5.2
> * Machine learning: implemented K-means clusterization algorithm optimized
> for distributed storages
> * SQL: CREATE TABLE and DROP TABLE commands support
> * SQL: New thin JDBC driver
> * SQL: Improved performance of certain queries, when affinity node can be
> calculated in advance
> * SQL: Fixed return type of AVG() function
> * SQL: BLOB type support added to thick JDBC driver
> * SQL: Improved LocalDate, LocalTime and LocalDateTime support for Java 8
> * SQL: Added FieldsQueryCursor interface to get fields metadata for
> SqlFieldsQuery
> * ODBC: Implemented DML statement batching
> * Massive performance and stability improvements
> 
> Ignite.NET:
> * Automatic remote assembly loading
> * NuGet-based standalone node deployment
> * Added conditional data removeal via LINQ DeleteAll
> * Added TimestampAttribute to control DateTime serialization mode
> * Added local collections joins support to LINQ.
> 
> Ignite CPP:
> * Added Compute::Call and Compute::Broadcast methods
> 
> Web Console:
> * Implemented support for UNIQUE indexes for key fields on import model
> from RDBMS
> * Added option to show full stack trace on Queries screen
> * Added PK alias generation on Models screen.
> 
> Complete list of closed issues:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%
> 20fixVersion%20%3D%202.1%20AND%20(status%20%3D%20closed%20or%20status%20%3D%
> 20resolved)
> 
> DEVNOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=refs/tags/2.1.0-rc4
> 
> RELEASE NOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.1.0-rc4
> 
> Please start voting.
> 
> +1 - to accept Apache Ignite 2.1.0-rc4
> 0 - don't care either way
> -1 - DO NOT accept Apache Ignite 2.1.0-rc4 (explain why)
> 
> This vote will go for 72 hours.


signature.asc
Description: Digital signature

Re: [VOTE] Apache Ignite 2.1.0 RC3

[Konstantin Boudnik]

Got it. Thank you for the understanding and readiness to deal with the
finding - that might not look like a big issues for us, but could
alert some of the users. I will be happy to jump on another
verification cycle as soon as it is available. Please let me know if I
can help with anything.

With best regards,
  Cos
--
  With regards,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Mon, Jul 24, 2017 at 10:46 AM, Denis Magda <dma...@apache.org> wrote:
> Hi Cos,
>
>>  Which tells me that the private key is simply shared by a number of the
>>  committers. And there's no guarantee that it hasn't been leaked outside of
>>  the group. And that's pretty serious security flaw, actually.
>
> That’s not the case. Sam signed and did final technical steps preparing the 
> RC3. I took care of other formalities.
>
> Personally, did expect this to be an issue. Agree, let’s fix the process 
> making sure the release manager signs bundles all the times.
>
>> - why every other RC Vote is started by a different person?
>
>
> Summer time, vacations, day offs…
>
> —
> Denis
>
>> On Jul 22, 2017, at 1:26 PM, Konstantin Boudnik <c...@apache.org> wrote:
>>
>> Retracting this, found the KEYS (douh...). Still
>>
>> -1 (binding). The release isn't signed by the release manager. Someone else
>> key is used.
>>
>> - Checked the sha1
>> - Successfully ran the build
>> - Checked the signature
>> - The archive is signed by the key 593A743B belonging to sboi...@apache.org.
>>  However, none of the 2.1.0 RC [VOTE] attempts were started by this person.
>>  Which tells me that the private key is simply shared by a number of the
>>  committers. And there's no guarantee that it hasn't been leaked outside of
>>  the group. And that's pretty serious security flaw, actually.
>>
>>  Why the release managers aren't using their own keys? It is easy to generate
>>  and sign the keys following guidelines [1]. Committers' keys are easy to
>>  validate against the Apache repository [2]
>>
>> Things that need to be improved in the next release:
>> - neither sha1 nor md5 are trustful checksum'ing methods and aren't
>>  guaranteeing the authenticity of the source archive. We should be switching
>>  to at least sha265 or higher. This has been brought up since the incubation.
>>  And warrants for -1 in the next release.
>> - why every other RC Vote is started by a different person?
>>
>> With regards,
>>  Cos
>>
>> [1] https://people.apache.org/keys/committer/
>> [2] 
>> https://www.apache.org/dev/new-committers-guide.html#set-up-security-and-pgp-keys
>>
>> On Sat, Jul 22, 2017 at 01:00PM, Konstantin Boudnik wrote:
>>> Am I missing the location of the signing keys? I cannot verivy the signature
>>> of the archive.
>>>
>>> -1 (binding) until then.
>>>
>>> Thanks
>>>  Cos
>>>
>>> On Thu, Jul 20, 2017 at 03:34PM, Denis Magda wrote:
>>>> Igniters,
>>>>
>>>> Setting off the vote one more time. Hope I’ll be successful this time, 
>>>> keeping fingers crossed :)
>>>>
>>>> We have uploaded a 2.1.0 release candidate to
>>>> https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc3/
>>>>
>>>> Git tag name is
>>>> 2.1.0-rc3
>>>>
>>>> This release includes the following changes:
>>>>
>>>> Ignite:
>>>> * Persistent cache store
>>>> * Added IgniteFuture.listenAsync() and IgniteFuture.chainAsync() mehtods
>>>> * Deprecated IgniteConfiguration.marshaller
>>>> * Updated Lucene dependency to version 5.5.2
>>>> * Machine learning: implemented K-means clusterization algorithm optimized
>>>> for distributed storages
>>>> * SQL: CREATE TABLE and DROP TABLE commands support
>>>> * SQL: New thin JDBC driver
>>>> * SQL: Improved performance of certain queries, when affinity node can be
>>>> calculated in advance
>>>> * SQL: Fixed return type of AVG() function
>>>> * SQL: BLOB type support added to thick JDBC driver
>>>> * SQL: Improved LocalDate, LocalTime and LocalDateTime support for Java 8
>>>> * SQL: Added FieldsQueryCursor interface to get fields metadata for
>>>> SqlFieldsQuery
>>>> * ODBC: Implemented DML statement batching
>>&g

Re: [VOTE] Apache Ignite 2.1.0 RC3

[Konstantin Boudnik]

Retracting this, found the KEYS (douh...). Still

-1 (binding). The release isn't signed by the release manager. Someone else
key is used.

- Checked the sha1
- Successfully ran the build 
- Checked the signature
- The archive is signed by the key 593A743B belonging to sboi...@apache.org.
  However, none of the 2.1.0 RC [VOTE] attempts were started by this person.
  Which tells me that the private key is simply shared by a number of the
  committers. And there's no guarantee that it hasn't been leaked outside of
  the group. And that's pretty serious security flaw, actually.

  Why the release managers aren't using their own keys? It is easy to generate
  and sign the keys following guidelines [1]. Committers' keys are easy to
  validate against the Apache repository [2]

Things that need to be improved in the next release:
- neither sha1 nor md5 are trustful checksum'ing methods and aren't
  guaranteeing the authenticity of the source archive. We should be switching
  to at least sha265 or higher. This has been brought up since the incubation.
  And warrants for -1 in the next release.
- why every other RC Vote is started by a different person?

With regards,
  Cos

[1] https://people.apache.org/keys/committer/
[2] 
https://www.apache.org/dev/new-committers-guide.html#set-up-security-and-pgp-keys

On Sat, Jul 22, 2017 at 01:00PM, Konstantin Boudnik wrote:
> Am I missing the location of the signing keys? I cannot verivy the signature
> of the archive.
> 
> -1 (binding) until then.
> 
> Thanks
>   Cos
> 
> On Thu, Jul 20, 2017 at 03:34PM, Denis Magda wrote:
> > Igniters,
> > 
> > Setting off the vote one more time. Hope I’ll be successful this time, 
> > keeping fingers crossed :)
> > 
> > We have uploaded a 2.1.0 release candidate to
> > https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc3/
> > 
> > Git tag name is
> > 2.1.0-rc3
> > 
> > This release includes the following changes:
> > 
> > Ignite:
> > * Persistent cache store
> > * Added IgniteFuture.listenAsync() and IgniteFuture.chainAsync() mehtods
> > * Deprecated IgniteConfiguration.marshaller
> > * Updated Lucene dependency to version 5.5.2
> > * Machine learning: implemented K-means clusterization algorithm optimized
> > for distributed storages
> > * SQL: CREATE TABLE and DROP TABLE commands support
> > * SQL: New thin JDBC driver
> > * SQL: Improved performance of certain queries, when affinity node can be
> > calculated in advance
> > * SQL: Fixed return type of AVG() function
> > * SQL: BLOB type support added to thick JDBC driver
> > * SQL: Improved LocalDate, LocalTime and LocalDateTime support for Java 8
> > * SQL: Added FieldsQueryCursor interface to get fields metadata for
> > SqlFieldsQuery
> > * ODBC: Implemented DML statement batching
> > * Massive performance and stability improvements
> > 
> > Ignite.NET:
> > * Automatic remote assembly loading
> > * NuGet-based standalone node deployment
> > * Added conditional data removeal via LINQ DeleteAll
> > * Added TimestampAttribute to control DateTime serialization mode
> > * Added local collections joins support to LINQ.
> > 
> > Ignite CPP:
> > * Added Compute::Call and Compute::Broadcast methods
> > 
> > Web Console:
> > * Implemented support for UNIQUE indexes for key fields on import model
> > from RDBMS
> > * Added option to show full stack trace on Queries screen
> > * Added PK alias generation on Models screen.
> > 
> > Complete list of closed issues:
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%
> > 20fixVersion%20%3D%202.1%20AND%20(status%20%3D%20closed%20or%20status%20%3D%
> > 20resolved)
> > 
> > DEVNOTES
> > https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=refs/tags/2.1.0-rc3
> > 
> > RELEASE NOTES
> > https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.1.0-rc3
> > 
> > Please start voting.
> > 
> > +1 - to accept Apache Ignite 2.1.0-rc3
> > 0 - don't care either way
> > -1 - DO NOT accept Apache Ignite 2.1.0-rc3 (explain why)
> > 
> > This vote will go for 72 hours.
> > 
> > —
> > Denis
> > 




signature.asc
Description: Digital signature

Re: [VOTE] Apache Ignite 2.1.0 RC3

[Konstantin Boudnik]

Am I missing the location of the signing keys? I cannot verivy the signature
of the archive.

-1 (binding) until then.

Thanks
  Cos

On Thu, Jul 20, 2017 at 03:34PM, Denis Magda wrote:
> Igniters,
> 
> Setting off the vote one more time. Hope I’ll be successful this time, 
> keeping fingers crossed :)
> 
> We have uploaded a 2.1.0 release candidate to
> https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc3/
> 
> Git tag name is
> 2.1.0-rc3
> 
> This release includes the following changes:
> 
> Ignite:
> * Persistent cache store
> * Added IgniteFuture.listenAsync() and IgniteFuture.chainAsync() mehtods
> * Deprecated IgniteConfiguration.marshaller
> * Updated Lucene dependency to version 5.5.2
> * Machine learning: implemented K-means clusterization algorithm optimized
> for distributed storages
> * SQL: CREATE TABLE and DROP TABLE commands support
> * SQL: New thin JDBC driver
> * SQL: Improved performance of certain queries, when affinity node can be
> calculated in advance
> * SQL: Fixed return type of AVG() function
> * SQL: BLOB type support added to thick JDBC driver
> * SQL: Improved LocalDate, LocalTime and LocalDateTime support for Java 8
> * SQL: Added FieldsQueryCursor interface to get fields metadata for
> SqlFieldsQuery
> * ODBC: Implemented DML statement batching
> * Massive performance and stability improvements
> 
> Ignite.NET:
> * Automatic remote assembly loading
> * NuGet-based standalone node deployment
> * Added conditional data removeal via LINQ DeleteAll
> * Added TimestampAttribute to control DateTime serialization mode
> * Added local collections joins support to LINQ.
> 
> Ignite CPP:
> * Added Compute::Call and Compute::Broadcast methods
> 
> Web Console:
> * Implemented support for UNIQUE indexes for key fields on import model
> from RDBMS
> * Added option to show full stack trace on Queries screen
> * Added PK alias generation on Models screen.
> 
> Complete list of closed issues:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%
> 20fixVersion%20%3D%202.1%20AND%20(status%20%3D%20closed%20or%20status%20%3D%
> 20resolved)
> 
> DEVNOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=refs/tags/2.1.0-rc3
> 
> RELEASE NOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.1.0-rc3
> 
> Please start voting.
> 
> +1 - to accept Apache Ignite 2.1.0-rc3
> 0 - don't care either way
> -1 - DO NOT accept Apache Ignite 2.1.0-rc3 (explain why)
> 
> This vote will go for 72 hours.
> 
> —
> Denis
> 


signature.asc
Description: Digital signature

Re: SSL certificate for the CI server

[Konstantin Boudnik]

I have never heard about this provider, and it is great they are donating
their resources to the FOSS. I quick glance on their site has reveiled a
couple of issues:
- the page for the "Standard Agreement" returns 404 [1]. I won't be willing to
  agree to something I cannot read upfront.
- the process seems to be manual.

The reason I like [2] is because it's backed by EFF and has a huge user base
(over 100 millions certificates to date) [3]

The process has been debugged already for other Apache projects, so I don't
really see why we need to go to someone else?

[1] 
https://www.globalsign.com/en/repository/globalsign-subscriber-agreement-digital-certificates-and-services.pdf
[2] https://letsencrypt.org/
[3] 
https://www.eff.org/deeplinks/2017/06/lets-encrypt-has-issued-100-million-certificates

Thanks,
  Cos

On Wed, Jul 19, 2017 at 09:41PM, Aleksey Chetaev wrote:
> Hi,
> 
> A know GlobalSing support open source projects for
> free(https://www.globalsign.com/en/ssl/ssl-open-source/).
> We can request certificates from them, it will be more easy for me. Any
> objection?
> 
> 
> Denis Magda-2 wrote
> > Hi Cos,
> > 
> > Alexey Chetaev, please join the conversation and share your thoughts on
> > this.
> > 
> > —
> > Denis
> > 
> >> On Jul 19, 2017, at 9:44 AM, Konstantin Boudnik 
> 
> > cos@
> 
> >  wrote:
> >> 
> >> Hey guys.
> >> 
> >> I've noticed that https://ci.ignite.apache.org/ has two issues:
> >> - it has the invalid certificate
> >> - the CI server isn't responding on the https port (there's only ngnix)
> >> 
> >> I don't about the rest of the group here, but all my browsers are
> >> enforcing
> >> HTTPS connections for the obvious reasons. I have to add an exception
> >> for the CI server to get in, which is a minor inconvenience compared to
> >> the
> >> security risks. I suggest we fix both issues. 
> >> 1. Getting a valid certificate is easy and doesn't cost a dime nowadays.
> >>   Here's the very details set of instructions on how we do it for Apache
> >>   Bigtop. They are easily applicable in Ignite CI's case [1]. I'd be
> >> happy to
> >>   help with this.
> >> 2. Reconfiguring the server to respond only on HTTPS port. That's another
> >> easy
> >>   thing to do for anyone with the access to the box. I don't have this,
> >> so
> >>   it'd be someone else.
> >> 
> >> Thoughts?
> >>  Cos
> >> 
> >> [1]
> >> https://cwiki.apache.org/confluence/display/BIGTOP/Bigtop+CI+Setup+Guide#BigtopCISetupGuide-Advancedpart:SetupaSSLsecuredJenkinsmaster
> >>
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://apache-ignite-developers.2346864.n4.nabble.com/SSL-certificate-for-the-CI-server-tp19830p19840.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.


signature.asc
Description: Digital signature

SSL certificate for the CI server

[Konstantin Boudnik]

Hey guys.

I've noticed that https://ci.ignite.apache.org/ has two issues:
- it has the invalid certificate
- the CI server isn't responding on the https port (there's only ngnix)

I don't about the rest of the group here, but all my browsers are enforcing
HTTPS connections for the obvious reasons. I have to add an exception
for the CI server to get in, which is a minor inconvenience compared to the
security risks. I suggest we fix both issues. 
1. Getting a valid certificate is easy and doesn't cost a dime nowadays.
   Here's the very details set of instructions on how we do it for Apache
   Bigtop. They are easily applicable in Ignite CI's case [1]. I'd be happy to
   help with this.
2. Reconfiguring the server to respond only on HTTPS port. That's another easy
   thing to do for anyone with the access to the box. I don't have this, so
   it'd be someone else.

Thoughts?
  Cos
   
[1] 
https://cwiki.apache.org/confluence/display/BIGTOP/Bigtop+CI+Setup+Guide#BigtopCISetupGuide-Advancedpart:SetupaSSLsecuredJenkinsmaster
 


signature.asc
Description: Digital signature

Re: [CANCEL] [VOTE] Apache Ignite 2.1.0 RC1

[Konstantin Boudnik]

Won't the release manager be the "who"?
--
  With regards,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Mon, Jul 17, 2017 at 4:25 PM, Denis Magda  wrote:
> Guys, what’s the status? Who and when is going to send the next build for 
> vote?
>
> —
> Denis
>
>> On Jul 17, 2017, at 5:50 AM, Vladimir Ozerov  wrote:
>>
>> Officially cancelling the vote.
>>
>> -- Forwarded message --
>> From: Denis Magda 
>> Date: Sat, Jul 15, 2017 at 4:48 PM
>> Subject: Re: [VOTE] Apache Ignite 2.1.0 RC1
>> To: "dev@ignite.apache.org" 
>>
>>
>> -1
>>
>> Because of the lgpl libraries issue. Please fix the bug and restart the
>> vote.
>>
>> Denis
>>
>> On Saturday, July 15, 2017, Ilya Suntsov  wrote:
>>
>>> Lgpl binaries should not to be in svn. This build will be removed.
>>>
>>> 15 июля 2017 г. 1:52 PM пользователь "Sergey Kozlov" >> >
>>> написал:
>>>
 Igniters

 Could someone explain why we include LGPL binary fabric [1] in the
>>> release?
 Either it was a mistake or we should upload also SHA1/MD5/ASC checksums
>>> as
 well


 [1]
 https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc1/
 apache-ignite-fabric-lgpl-2.1.0-bin.zip

 On Fri, Jul 14, 2017 at 8:45 PM, Vladimir Ozerov >> >
 wrote:

> gniters!
>
> We have uploaded a 2.1.0 release candidate to
> https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc1/
>
> Git tag name is
> 2.1.0-rc1
>
> This release includes the following changes:
>
> Ignite:
> * Persistent cache store
> * Added IgniteFuture.listenAsync() and IgniteFuture.chainAsync()
>>> mehtods
> * Deprecated IgniteConfiguration.marshaller
> * Updated Lucene dependency to version 5.5.2
> * Machine learning: implemented K-means clusterization algorithm
 optimized
> for distributed storages
> * SQL: CREATE TABLE and DROP TABLE commands support
> * SQL: New thin JDBC driver
> * SQL: Improved performance of certain queries, when affinity node can
>>> be
> calculated in advance
> * SQL: Fixed return type of AVG() function
> * SQL: BLOB type support added to thick JDBC driver
> * SQL: Improved LocalDate, LocalTime and LocalDateTime support for
>>> Java 8
> * SQL: Added FieldsQueryCursor interface to get fields metadata for
> SqlFieldsQuery
> * ODBC: Implemented DML statement batching
> * Massive performance and stability improvements
>
> Ignite.NET:
> * Automatic remote assembly loading
> * NuGet-based standalone node deployment
> * Added conditional data removeal via LINQ DeleteAll
> * Added TimestampAttribute to control DateTime serialization mode
> * Added local collections joins support to LINQ.
>
> Ignite CPP:
> * Added Compute::Call and Compute::Broadcast methods
>
> Web Console:
> * Implemented support for UNIQUE indexes for key fields on import
>> model
> from RDBMS
> * Added option to show full stack trace on Queries screen
> * Added PK alias generation on Models screen.
>
> Complete list of closed issues:
> https://issues.apache.org/jira/issues/?jql=project%20%
>>> 3D%20IGNITE%20AND%
> 20fixVersion%20%3D%202.1%20AND%20(status%20%3D%
> 20closed%20or%20status%20%3D%20resolved)
>
> DEVNOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> plain;f=DEVNOTES.txt;hb=refs/tags/2.1.0-rc1
>
> RELEASE NOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.1.0-rc1
>
> Please start voting.
>
> +1 - to accept Apache Ignite 2.1.0-rc1
> 0 - don't care either way
> -1 - DO NOT accept Apache Ignite 2.1.0-rc1 (explain why)
>
> This vote will go for 72 hours.
>
> Vladimir.
>



 --
 Sergey Kozlov
 GridGain Systems
 www.gridgain.com

>>>
>

Re: [ignite] your /dist/ artifacts - 1 BAD signature

[Konstantin Boudnik]

BTW, keep in mind that /dist ends up being sync'ed across a bunch of
Apache mirrors. So, the experiments are better be kept to a less
visible environment.

Cos
--
  With regards,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Fri, Jul 14, 2017 at 10:26 PM, Denis Magda  wrote:
> Igniters,
>
> Especially Sergey K., Ilya S and Alexey Chetaev,
>
> Could you explain what those “TEST” artifacts are doing in the dist folder? 
> Are you trying out the new release procedure?
>
> In addition to the questions, please fix the issue following the issue 
> brought out below.
>
> —
> Denis
>
>> Begin forwarded message:
>>
>> From: Henk Penning 
>> Subject: [ignite] your /dist/ artifacts - 1 BAD signature
>> Date: July 14, 2017 at 10:07:11 PM PDT
>> To: priv...@ignite.apache.org
>> Cc: he...@apache.org, sboi...@apache.org
>> Reply-To: priv...@ignite.apache.org
>>
>> Hi PMC ignite,
>>
>>  I watch 'www.apache.org/dist/', and I noticed that :
>>
>>  -- you have 1 BAD pgp signature
>>
>>   ignite/2.1.0-TEST/apache-ignite-2.1.0-TEST-src.zip.asc
>>
>>  -- you have 3 unsigned artifacts :
>>
>>   ignite/2.1.0-TEST/apache-ignite-fabric-2.1.0-TEST-bin.zip
>>   ignite/2.1.0-TEST/apache-ignite-fabric-lgpl-2.1.0-TEST-bin.zip
>>   ignite/2.1.0-TEST/apache-ignite-hadoop-2.1.0-TEST-bin.zip
>>
>>  Please fix these problems soon ; for details, see
>>
>>http://mirror-vm.apache.org/~henkp/checker/sig.html#project-ignite
>>http://mirror-vm.apache.org/~henkp/checker/md5.html
>>
>>  For information on how to fix problems, see the faq :
>>
>>http://mirror-vm.apache.org/~henkp/checker/faq.html
>>
>>  Thanks a lot, regards,
>>
>>  Henk Penning -- apache.org infrastructure
>>
>>  PS. The contents of this message is generated,
>>  but the mail itself is sent "by hand".
>>  PS. Please cc me on all relevant emails.
>>
>>    _
>> Henk P. Penning, ICT-beta R Uithof BBL-761   _/ \_
>> Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
>> Princetonplein 5, 3584CC Utrecht, NL  F +31 30 253 4553 \_/ \_/
>> http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/
>>
>

Re: Apache Ignite 2.1 scope

[Konstantin Boudnik]

That's an interesting statement to make, considering the a PMC is
legally responsible for the release they are making and voting for.
What I believe it would achieve is to give a wider group of our users
a chance to get and install the new version and try some of the most
prominent features, while giving the feedback. Even if expressed in
the form of non-binding votes.
--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Sat, Jul 8, 2017 at 8:26 AM, Dmitriy Setrakyan <dsetrak...@apache.org> wrote:
> Cos,
>
> I am not sure what a 7 day vote will accomplish. As we all know, Apache
> [VOTE] is not about the release quality, but about proper build procedure,
> release signing, and licensing. I do not see the community needing more
> time than usual to verify this release.
>
> D.
>
> On Fri, Jul 7, 2017 at 8:14 PM, Konstantin Boudnik <c...@apache.org> wrote:
>
>> Fair enough, I will try to collect more and share with the team.
>>
>> And +1 on the proposed release schedule: considering the complexity of the
>> changes we better have some time to play with the bits. In fact, I'd
>> suggest
>> we give it 7 days for the [VOTE] so people have time to play with the bits.
>> Thoughts?
>>
>> Cos
>>
>> On Thu, Jul 06, 2017 at 11:06AM, Vladimir Ozerov wrote:
>> > Cos,
>> >
>> > I am not aware of performance degradation in regards to Cassandra. AFAIK
>> > there were extensive benchmarking prior to 2.0 release. And in the end
>> 2.0
>> > release had performance not worse than 1.9. If you have more information
>> on
>> > the matter, let's discuss it in the separate thread.
>> >
>> > On Thu, Jul 6, 2017 at 11:04 AM, Vladimir Ozerov <voze...@gridgain.com>
>> > wrote:
>> >
>> > > Vyacheslav, Denis,
>> > >
>> > > 7 July is too abrupt date. Scope of 2.1 is still too broad, and what is
>> > > more important - persistent store has been merged only several days
>> ago. We
>> > > need some room for stabilization. I propose the following timeline:
>> > > 16 July - code freeze
>> > > 17-21 July - QA
>> > > 21-24 July - vote and release
>> > >
>> > > On Thu, Jul 6, 2017 at 4:30 AM, Konstantin Boudnik <c...@apache.org>
>> wrote:
>> > >
>> > >> Thanks everyone for giving us enough time to take a look into the code
>> > >> and architecture of this new feature. The webinar was certainly quite
>> > >> helpful (thanks Denis!).
>> > >>
>> > >> It seems to be a good time to add the feature into the dot-release, so
>> > >> more users can have a taste of it "officially". I have a somewhat
>> > >> unrelated question though: it seems that 2.0 has significant
>> > >> performance degradation compared to 1.8 when it get to the working
>> > >> with external distributed storage (like Cassandra). Could it be caused
>> > >> by all the changes that were made between 1.8 and 2.0 in the
>> > >> preparation for the coming persistent store functionality? Are we
>> > >> publishing/collecting say yardstick reports for our own releases?
>> > >>
>> > >> Thanks!
>> > >>   Cos
>> > >> --
>> > >>   Take care,
>> > >> Konstantin (Cos) Boudnik
>> > >> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>> > >>
>> > >> Disclaimer: Opinions expressed in this email are those of the author,
>> > >> and do not necessarily represent the views of any company the author
>> > >> might be affiliated with at the moment of writing.
>> > >>
>> > >>
>> > >> On Tue, Jul 4, 2017 at 3:20 AM, Vladimir Ozerov <voze...@gridgain.com
>> >
>> > >> wrote:
>> > >> > Igniters,
>> > >> >
>> > >> > Persistent store has been merged to master branch! "master-bak"
>> branch
>> > >> was
>> > >> > created to keep the state before merge for safety. As release date
>> for
>> > >> 2.1
>> > >> > is mid July, I created "ignite-2.1" branch where we will stabilize
>> the
>> > >> > release as usual. Please push features 

Re: Apache Ignite 2.1 scope

[Konstantin Boudnik]

Fair enough, I will try to collect more and share with the team.

And +1 on the proposed release schedule: considering the complexity of the
changes we better have some time to play with the bits. In fact, I'd suggest
we give it 7 days for the [VOTE] so people have time to play with the bits.
Thoughts?

Cos

On Thu, Jul 06, 2017 at 11:06AM, Vladimir Ozerov wrote:
> Cos,
> 
> I am not aware of performance degradation in regards to Cassandra. AFAIK
> there were extensive benchmarking prior to 2.0 release. And in the end 2.0
> release had performance not worse than 1.9. If you have more information on
> the matter, let's discuss it in the separate thread.
> 
> On Thu, Jul 6, 2017 at 11:04 AM, Vladimir Ozerov <voze...@gridgain.com>
> wrote:
> 
> > Vyacheslav, Denis,
> >
> > 7 July is too abrupt date. Scope of 2.1 is still too broad, and what is
> > more important - persistent store has been merged only several days ago. We
> > need some room for stabilization. I propose the following timeline:
> > 16 July - code freeze
> > 17-21 July - QA
> > 21-24 July - vote and release
> >
> > On Thu, Jul 6, 2017 at 4:30 AM, Konstantin Boudnik <c...@apache.org> wrote:
> >
> >> Thanks everyone for giving us enough time to take a look into the code
> >> and architecture of this new feature. The webinar was certainly quite
> >> helpful (thanks Denis!).
> >>
> >> It seems to be a good time to add the feature into the dot-release, so
> >> more users can have a taste of it "officially". I have a somewhat
> >> unrelated question though: it seems that 2.0 has significant
> >> performance degradation compared to 1.8 when it get to the working
> >> with external distributed storage (like Cassandra). Could it be caused
> >> by all the changes that were made between 1.8 and 2.0 in the
> >> preparation for the coming persistent store functionality? Are we
> >> publishing/collecting say yardstick reports for our own releases?
> >>
> >> Thanks!
> >>   Cos
> >> --
> >>   Take care,
> >> Konstantin (Cos) Boudnik
> >> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
> >>
> >> Disclaimer: Opinions expressed in this email are those of the author,
> >> and do not necessarily represent the views of any company the author
> >> might be affiliated with at the moment of writing.
> >>
> >>
> >> On Tue, Jul 4, 2017 at 3:20 AM, Vladimir Ozerov <voze...@gridgain.com>
> >> wrote:
> >> > Igniters,
> >> >
> >> > Persistent store has been merged to master branch! "master-bak" branch
> >> was
> >> > created to keep the state before merge for safety. As release date for
> >> 2.1
> >> > is mid July, I created "ignite-2.1" branch where we will stabilize the
> >> > release as usual. Please push features and fixes planned for 2.1
> >> release to
> >> > this branch. The rest commits should go to master.
> >> >
> >> > Vladimir.
> >> >
> >> > On Mon, Jul 3, 2017 at 4:18 PM, Vladimir Ozerov <voze...@gridgain.com>
> >> > wrote:
> >> >
> >> >> Hi Denis,
> >> >>
> >> >> Awesome news! I'll take care of necessary release procedures if nobody
> >> >> minds.
> >> >>
> >> >> Vladimir.
> >> >>
> >> >> On Sat, Jul 1, 2017 at 12:25 AM, Denis Magda <dma...@apache.org>
> >> wrote:
> >> >>
> >> >>> Igniters,
> >> >>>
> >> >>> It’s time to refresh this abandoned thread and finally rollout out all
> >> >>> the changes appeared in 2.1.
> >> >>>
> >> >>> In addition, recently donated Persistent Store got the green light
> >> [1] to
> >> >>> become a part of the master branch (no one asked for extra time to
> >> dive
> >> >>> into its details) and, personally, it’s absolutely fine to make it
> >> >>> available in the nearest release.
> >> >>>
> >> >>> My proposal is to do the release by mid of July (closer to July
> >> 15th). Is
> >> >>> there anyone who is ready to take over as a release manager creating
> >> the
> >> >>> page like this [2] and handling all release related activities?
> >> >>>
> >> >>>
> >> >>> [1] http://apache-ignite-developers.2

Re: Apache Ignite 2.1 scope

[Konstantin Boudnik]

Thanks everyone for giving us enough time to take a look into the code
and architecture of this new feature. The webinar was certainly quite
helpful (thanks Denis!).

It seems to be a good time to add the feature into the dot-release, so
more users can have a taste of it "officially". I have a somewhat
unrelated question though: it seems that 2.0 has significant
performance degradation compared to 1.8 when it get to the working
with external distributed storage (like Cassandra). Could it be caused
by all the changes that were made between 1.8 and 2.0 in the
preparation for the coming persistent store functionality? Are we
publishing/collecting say yardstick reports for our own releases?

Thanks!
  Cos
--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Tue, Jul 4, 2017 at 3:20 AM, Vladimir Ozerov  wrote:
> Igniters,
>
> Persistent store has been merged to master branch! "master-bak" branch was
> created to keep the state before merge for safety. As release date for 2.1
> is mid July, I created "ignite-2.1" branch where we will stabilize the
> release as usual. Please push features and fixes planned for 2.1 release to
> this branch. The rest commits should go to master.
>
> Vladimir.
>
> On Mon, Jul 3, 2017 at 4:18 PM, Vladimir Ozerov 
> wrote:
>
>> Hi Denis,
>>
>> Awesome news! I'll take care of necessary release procedures if nobody
>> minds.
>>
>> Vladimir.
>>
>> On Sat, Jul 1, 2017 at 12:25 AM, Denis Magda  wrote:
>>
>>> Igniters,
>>>
>>> It’s time to refresh this abandoned thread and finally rollout out all
>>> the changes appeared in 2.1.
>>>
>>> In addition, recently donated Persistent Store got the green light [1] to
>>> become a part of the master branch (no one asked for extra time to dive
>>> into its details) and, personally, it’s absolutely fine to make it
>>> available in the nearest release.
>>>
>>> My proposal is to do the release by mid of July (closer to July 15th). Is
>>> there anyone who is ready to take over as a release manager creating the
>>> page like this [2] and handling all release related activities?
>>>
>>>
>>> [1] http://apache-ignite-developers.2346864.n4.nabble.com/
>>> Ignite-Persistent-Store-Ready-for-merge-td19160.html
>>> [2] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0
>>>
>>> —
>>> Denis
>>>
>>> > On Jun 1, 2017, at 9:24 AM, Alexander Paschenko <
>>> alexander.a.pasche...@gmail.com> wrote:
>>> >
>>> > IGNITE-5327 Create predefined cache templates for CREATE TABLE command
>>> > - minor comments left, ETA is Friday.
>>> >
>>> > IGNITE-5380 Validate cache QueryEntities in discovery thread - in
>>> > progress, the meat of code is written, but need to add lots of tests.
>>> > ETA is Friday.
>>> >
>>> > IGNITE-5188 Support AFFINITY KEY keyword for CREATE TABLE command - in
>>> > progress, made few first small steps, ETA is Friday.
>>> >
>>> > Rest is closed/patch available, ignite-4994 has been moved to 2.2.
>>> >
>>> > - Alex
>>> >
>>> > 2017-06-01 19:03 GMT+03:00 Sergey Chugunov :
>>> >>   1. IGNITE-5386 Inactive mode must be forced on starting up grid with
>>> >>   persistence is enabled
>>> >>   It is important improvement to fix critical bug IGNITE-5363.
>>> >>   Working on it, ETA - tomorrow.
>>> >>   2. IGNITE-5375 New PersistentStoreMetrics, MemoryMetrics interface
>>> >>   improvements
>>> >>   A lot of discussions were on this topic, ticket created only today
>>> and
>>> >>   requires several days to implement.
>>> >>
>>> >>
>>> >>
>>> >> On Thu, Jun 1, 2017 at 6:56 PM, Taras Ledkov 
>>> wrote:
>>> >>
>>> >>> Folks,
>>> >>>
>>> >>> IGNITE-4922 JDBC Driver: renew thin client based solution:
>>> >>>
>>> >>> On 2.1 the functionality of the new thin client JDBC driver will be
>>> >>> between deprecated Ignite thin JDBC and Ignite JDBCv2.
>>> >>> 1. The most functions of SQL query (include DML) are implemented and
>>> ready
>>> >>> for review;
>>> >>> 2. The most functions of JDBC metadata are implemented and ready for
>>> >>> review;
>>> >>> 3. Transactions, batching, streaming, blobs, scrollable / writable
>>> cursors
>>> >>> will not be supported in 2.1.
>>> >>>
>>> >>>
>>> >>>
>>> >>> On 01.06.2017 18:43, Vladimir Ozerov wrote:
>>> >>>
>>>  Folks,
>>> 
>>>  We are almost reached proposed feature-complete date (June 2), Could
>>> you
>>>  please share current status of your major features?
>>> 
>>>  On Tue, May 16, 2017 at 3:51 AM, Dmitriy Setrakyan <
>>> dsetrak...@apache.org
>>> >
>>>  wrote:
>>> 
>>>  Looks a little tight. Let's hope we can make it.
>>> >
>>> > On Mon, May 15, 2017 at 1:29 PM, Denis Magda 
>>> wrote:
>>> >
>>> 

Re: Distributed scheduling

[Konstantin Boudnik]

Seems like a simple API for an external cron-like service to invoke an
action in Ignite would suffice, no? There are about a million of
scheduling services like that already, some have very good integration
into orchestrators of all sorts. Perhaps a trivial REST would do
instead of durable services, etc.?

Cos
--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Mon, Jul 3, 2017 at 3:35 PM, Valentin Kulichenko
 wrote:
> Dmitry,
>
> Yes, this can be implemented using services in many cases, but:
>
> - It will require user to implement actual scheduling logic. It's quite a
> generic task, so I think it makes sense to have it directly on the API.
> - Most likely it will imply deploying separate service for each scheduled
> task. I don't think it's a very good idea.
> - Current services implementation is not durable. If cluster is restarted,
> all services are lost.
>
> -Val
>
> On Sat, Jul 1, 2017 at 12:34 AM, Dmitriy Setrakyan 
> wrote:
>
>> Val,
>>
>> In this case, we should have a notion of a named scheduler and ensure that
>> we don't schedule the same task more than once. This is beginning to look
>> more like a durable cluster singleton service, no?
>>
>> D.
>>
>> On Fri, Jun 30, 2017 at 1:39 PM, Valentin Kulichenko <
>> valentin.kuliche...@gmail.com> wrote:
>>
>> > I think this functionality should provide durable way of scheduled task
>> or
>> > closure execution on the cluster. Job descriptors should be persisted on
>> > server side and executed there.
>> >
>> > As for API, I believe this should be part of Compute Grid. I suggest to
>> > introduce IgniteCompute#withSchedulingPolicy(SchedulingPolicy policy)
>> > method, where SchedulingPolicy is smth like this:
>> >
>> > public interface SchedulingPolicy {
>> > /**
>> >  * @return Timestamp of next execution.
>> >  */
>> > public Date nextTime();
>> > }
>> >
>> > This will enable scheduling for all compute features (tasks, callables,
>> > closures, etc.) and also very flexible. Policy implementation can provide
>> > simple periodic scheduling, scheduling based on Cron or anything else.
>> >
>> > Thoughts?
>> >
>> > -Val
>> >
>> > On Fri, Jun 30, 2017 at 7:55 AM, Dmitriy Setrakyan <
>> dsetrak...@apache.org>
>> > wrote:
>> >
>> > > On Fri, Jun 30, 2017 at 12:29 AM, Alexey Kuznetsov <
>> > akuznet...@apache.org>
>> > > wrote:
>> > >
>> > > > Dmitriy,
>> > > >
>> > > > >> Can you provide a simple example of API calls that will make this
>> > > > possible?
>> > > > API could be like this:
>> > > > 1) via scheduler:
>> > > > Ignite ignite = Ignition.start();
>> > > >
>> > > > ignite.scheduler().schedulel(job, "0 0 * * *"); // This will execute
>> > job
>> > > > every day at 00:00
>> > > >
>> > > > 2) via compute
>> > > >
>> > > > Ignite ignite = Ignition.start();
>> > > >
>> > > > ignite.compute().schedulel(task, "0 0 * * *"); // This will execute
>> > > > compute
>> > > > task every day at 00:00
>> > > >
>> > > > Make sense?
>> > > >
>> > > >
>> > > Yes, it does, but I am failing to see how is this a *distributed*
>> > > scheduling. Are we persisting the scheduler somewhere in the cluster or
>> > is
>> > > it only triggered on the client side?
>> > >
>> >
>>

Re: any secondary file system for swift

[Konstantin Boudnik]

And just to be completely clear: are you referring to OpenStack Swift?
Please pardon my ignorance, but I though Swift is a storage "solution"
rather than a distributed file system. Are you referring to Ceph by
any chance?

I guess I am just confused a little bit and would appreciate if you
can clarify your point a little bit.

Thank you!
  Cos
--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Tue, Jun 13, 2017 at 9:01 AM, Antonio Si  wrote:
> Hi Vladimir
>
> Yes. That's what I meant.
>
> Thanks.
>
> Antonio.
>
> Sent from my iPhone
>
>> On Jun 12, 2017, at 11:51 PM, Vladimir Ozerov  wrote:
>>
>> Hi Antonio,
>>
>> Please clarify what file system do you mean? Is it secondary file system
>> for IGFS?
>>
>> Vladimir.
>>
>>> On Tue, Jun 13, 2017 at 8:14 AM, Antonio Si  wrote:
>>>
>>> Hi,
>>>
>>> I am new to Ignite.
>>>
>>> I am wondering if there is any implmentation for using a swift store
>>> as a secondary file system?
>>>
>>> Thanks.
>>>
>>> Antonio.
>>>

Re: Configuration issues with IGFS in Ignite 1.9

[Konstantin Boudnik]

Sorry, please disregard the last one - that's my omission. service.sh
script is still fine!
--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Fri, Jun 9, 2017 at 12:19 PM, Konstantin Boudnik <c...@apache.org> wrote:
> Vladimir,
>
> one more issue - it seems that ignite script (bin/ignite.sh) doesn't
> respond to 'stop' command anymore as it was the case in the earlier
> versions of it. As the result, linux init scripts have no control over
> it rather than simply kill the process. Is it the intention or am I
> missing something?
>
> Thank you very much!
>   Cos
>
> --
>   Take care,
> Konstantin (Cos) Boudnik
> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>
> Disclaimer: Opinions expressed in this email are those of the author,
> and do not necessarily represent the views of any company the author
> might be affiliated with at the moment of writing.
>
>
> On Fri, Jun 9, 2017 at 11:05 AM, Konstantin Boudnik <c...@apache.org> wrote:
>> Yey! That did the trick, thank you for your help! It'd be great to
>> have this fix for sure!
>> --
>>   Take care,
>> Konstantin (Cos) Boudnik
>> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>>
>> Disclaimer: Opinions expressed in this email are those of the author,
>> and do not necessarily represent the views of any company the author
>> might be affiliated with at the moment of writing.
>>
>>
>> On Fri, Jun 9, 2017 at 6:41 AM, Vladimir Ozerov <voze...@gridgain.com> wrote:
>>> Cos,
>>>
>>> This is a problem with our URI parsing. Please add a slash to the end and
>>> it should work: "hdfs://0f6e4ed13002.bigtop.apache.org:8020*/*". I'll
>>> create a ticket for this.
>>>
>>> On Thu, Jun 8, 2017 at 9:28 PM, Konstantin Boudnik <c...@apache.org> wrote:
>>>
>>>> Thank you for your help, Vladimir. Unfortunately, I am still seeing
>>>> the same behavior while attempting to bring up the service. The full
>>>> element's configuration could be found at [1]
>>>> Can we  perhaps get on a skype/hangout for a few minutes so we can
>>>> resolve this quickly? Unless, I am doing something silly and missing
>>>> it, of course.
>>>>
>>>> That'd be a great help!
>>>>
>>>> [1] https://gist.github.com/c0s/cfb2b78a87f4f7f3ef4c1fa0bb5c4dea
>>>>
>>>> --
>>>>   Take care,
>>>> Konstantin (Cos) Boudnik
>>>> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>>>>
>>>> Disclaimer: Opinions expressed in this email are those of the author,
>>>> and do not necessarily represent the views of any company the author
>>>> might be affiliated with at the moment of writing.
>>>>
>>>>
>>>> On Thu, Jun 8, 2017 at 1:23 AM, Vladimir Ozerov <voze...@gridgain.com>
>>>> wrote:
>>>> > Hi Cos,
>>>> >
>>>> > Please try this one:
>>>> >
>>>> > 
>>>> > >>> > class="org.apache.ignite.hadoop.fs.IgniteHadoopIgfsSecondaryFileSystem">
>>>> > 
>>>> > >>> > class="org.apache.ignite.hadoop.fs.CachingHadoopFileSystemFactory">
>>>> > 
>>>> > 
>>>> > 
>>>> > /etc/hadoop/conf/core-site.xml
>>>> > 
>>>> > 
>>>> > 
>>>> > 
>>>> > 
>>>> > 
>>>> > 
>>>> >
>>>> > Vladimir.
>>>> >
>>>> > On Wed, Jun 7, 2017 at 11:40 PM, Konstantin Boudnik <c...@apache.org>
>>>> wrote:
>>>> >
>>>> >> Guys,
>>>> >>
>>>> >> after upgrading the Bigtop stack from Ignite 1.5 to 1.9 we are seeing
>>>> >> a number of issues introduced by changed script interfaces and
>>>> >> similar. However, the one which I still can not fix so far is this.
>>>> >> The secondary file system is configured like this:
>>>> >>
>>>> >> 
>>>> >>   
>>&

Re: Configuration issues with IGFS in Ignite 1.9

[Konstantin Boudnik]

Vladimir,

one more issue - it seems that ignite script (bin/ignite.sh) doesn't
respond to 'stop' command anymore as it was the case in the earlier
versions of it. As the result, linux init scripts have no control over
it rather than simply kill the process. Is it the intention or am I
missing something?

Thank you very much!
  Cos

--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Fri, Jun 9, 2017 at 11:05 AM, Konstantin Boudnik <c...@apache.org> wrote:
> Yey! That did the trick, thank you for your help! It'd be great to
> have this fix for sure!
> --
>   Take care,
> Konstantin (Cos) Boudnik
> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>
> Disclaimer: Opinions expressed in this email are those of the author,
> and do not necessarily represent the views of any company the author
> might be affiliated with at the moment of writing.
>
>
> On Fri, Jun 9, 2017 at 6:41 AM, Vladimir Ozerov <voze...@gridgain.com> wrote:
>> Cos,
>>
>> This is a problem with our URI parsing. Please add a slash to the end and
>> it should work: "hdfs://0f6e4ed13002.bigtop.apache.org:8020*/*". I'll
>> create a ticket for this.
>>
>> On Thu, Jun 8, 2017 at 9:28 PM, Konstantin Boudnik <c...@apache.org> wrote:
>>
>>> Thank you for your help, Vladimir. Unfortunately, I am still seeing
>>> the same behavior while attempting to bring up the service. The full
>>> element's configuration could be found at [1]
>>> Can we  perhaps get on a skype/hangout for a few minutes so we can
>>> resolve this quickly? Unless, I am doing something silly and missing
>>> it, of course.
>>>
>>> That'd be a great help!
>>>
>>> [1] https://gist.github.com/c0s/cfb2b78a87f4f7f3ef4c1fa0bb5c4dea
>>>
>>> --
>>>   Take care,
>>> Konstantin (Cos) Boudnik
>>> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>>>
>>> Disclaimer: Opinions expressed in this email are those of the author,
>>> and do not necessarily represent the views of any company the author
>>> might be affiliated with at the moment of writing.
>>>
>>>
>>> On Thu, Jun 8, 2017 at 1:23 AM, Vladimir Ozerov <voze...@gridgain.com>
>>> wrote:
>>> > Hi Cos,
>>> >
>>> > Please try this one:
>>> >
>>> > 
>>> > >> > class="org.apache.ignite.hadoop.fs.IgniteHadoopIgfsSecondaryFileSystem">
>>> >     
>>> > >> > class="org.apache.ignite.hadoop.fs.CachingHadoopFileSystemFactory">
>>> > 
>>> > 
>>> > 
>>> > /etc/hadoop/conf/core-site.xml
>>> > 
>>> > 
>>> > 
>>> > 
>>> > 
>>> > 
>>> > 
>>> >
>>> > Vladimir.
>>> >
>>> > On Wed, Jun 7, 2017 at 11:40 PM, Konstantin Boudnik <c...@apache.org>
>>> wrote:
>>> >
>>> >> Guys,
>>> >>
>>> >> after upgrading the Bigtop stack from Ignite 1.5 to 1.9 we are seeing
>>> >> a number of issues introduced by changed script interfaces and
>>> >> similar. However, the one which I still can not fix so far is this.
>>> >> The secondary file system is configured like this:
>>> >>
>>> >> 
>>> >>   
>>> >> >> >> parent="igfsCfgBase">
>>> >>   
>>> >>
>>> >>   
>>> >>   
>>> >>   
>>> >>
>>> >>   
>>> >>   
>>> >> 
>>> >>   
>>> >>   
>>> >>   
>>> >> 
>>> >>   
>>> >>
>>> >>   
>>> >> >> >> class="org.apache.ignite.hadoop.fs.IgniteHadoopIgfsSecondaryFileS
>>> ystem">
>>> >>   >> >> value='hdfs://0f6e4ed13002.bigtop.apache.org:8020'/

Re: Configuration issues with IGFS in Ignite 1.9

[Konstantin Boudnik]

Yey! That did the trick, thank you for your help! It'd be great to
have this fix for sure!
--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Fri, Jun 9, 2017 at 6:41 AM, Vladimir Ozerov <voze...@gridgain.com> wrote:
> Cos,
>
> This is a problem with our URI parsing. Please add a slash to the end and
> it should work: "hdfs://0f6e4ed13002.bigtop.apache.org:8020*/*". I'll
> create a ticket for this.
>
> On Thu, Jun 8, 2017 at 9:28 PM, Konstantin Boudnik <c...@apache.org> wrote:
>
>> Thank you for your help, Vladimir. Unfortunately, I am still seeing
>> the same behavior while attempting to bring up the service. The full
>> element's configuration could be found at [1]
>> Can we  perhaps get on a skype/hangout for a few minutes so we can
>> resolve this quickly? Unless, I am doing something silly and missing
>> it, of course.
>>
>> That'd be a great help!
>>
>> [1] https://gist.github.com/c0s/cfb2b78a87f4f7f3ef4c1fa0bb5c4dea
>>
>> --
>>   Take care,
>> Konstantin (Cos) Boudnik
>> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>>
>> Disclaimer: Opinions expressed in this email are those of the author,
>> and do not necessarily represent the views of any company the author
>> might be affiliated with at the moment of writing.
>>
>>
>> On Thu, Jun 8, 2017 at 1:23 AM, Vladimir Ozerov <voze...@gridgain.com>
>> wrote:
>> > Hi Cos,
>> >
>> > Please try this one:
>> >
>> > 
>> > > > class="org.apache.ignite.hadoop.fs.IgniteHadoopIgfsSecondaryFileSystem">
>> > 
>> > > > class="org.apache.ignite.hadoop.fs.CachingHadoopFileSystemFactory">
>> >     
>> > 
>> > 
>> > /etc/hadoop/conf/core-site.xml
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> >
>> > Vladimir.
>> >
>> > On Wed, Jun 7, 2017 at 11:40 PM, Konstantin Boudnik <c...@apache.org>
>> wrote:
>> >
>> >> Guys,
>> >>
>> >> after upgrading the Bigtop stack from Ignite 1.5 to 1.9 we are seeing
>> >> a number of issues introduced by changed script interfaces and
>> >> similar. However, the one which I still can not fix so far is this.
>> >> The secondary file system is configured like this:
>> >>
>> >> 
>> >>   
>> >> > >> parent="igfsCfgBase">
>> >>   
>> >>
>> >>   
>> >>   
>> >>   
>> >>
>> >>   
>> >>   
>> >> 
>> >>   
>> >>   
>> >>   
>> >> 
>> >>   
>> >>
>> >>   
>> >> > >> class="org.apache.ignite.hadoop.fs.IgniteHadoopIgfsSecondaryFileS
>> ystem">
>> >>   > >> value='hdfs://0f6e4ed13002.bigtop.apache.org:8020'/>
>> >>   > >> value='/etc/hadoop/conf/core-site.xml'/>
>> >>   
>> >> 
>> >>   
>> >>
>> >> And we are getting the following error message:
>> >>
>> >> Caused by: java.lang.IllegalArgumentException: Can not create a Path
>> >> from an empty string
>> >> at org.apache.hadoop.fs.Path.checkPathArg(Path.java:126)
>> >> at org.apache.hadoop.fs.Path.(Path.java:134)
>> >> at org.apache.ignite.internal.processors.hadoop.impl.delegate.
>> >> HadoopBasicFileSystemFactoryDelegate.start(
>> HadoopBasicFileSystemFactoryDe
>> >> legate
>> >> .java:165)
>> >> at org.apache.ignite.internal.processors.hadoop.impl.delegate.
>> >> HadoopCachingFileSystemFactoryDelegate.start(
>> >> HadoopCachingFileSystemFactoryDele
>> >> gate.java:58)
>> >> at org.apache.ignite.internal.processors.hadoop.impl.delegate.
>> >> HadoopIgfsSeconda

Re: [DISCUSS] Webinar for Ignite Persistent Store walk-through

[Konstantin Boudnik]

That'd be great! Thank you!
--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Thu, Jun 8, 2017 at 12:54 PM, Denis Magda  wrote:
> Igniters,
>
> What’d you think if we arrange an internal webinar for our community to walk 
> through the features, capabilities and implementation details of the Ignite 
> Persistent Store [1]? That should help us understanding the donation better.
>
> Please reply if you will be happy to attend.
>
> [1] https://apacheignite.readme.io/docs/distributed-persistent-store 
> 
>
> —
> Denis

Re: Configuration issues with IGFS in Ignite 1.9

[Konstantin Boudnik]

Thank you for your help, Vladimir. Unfortunately, I am still seeing
the same behavior while attempting to bring up the service. The full
element's configuration could be found at [1]
Can we  perhaps get on a skype/hangout for a few minutes so we can
resolve this quickly? Unless, I am doing something silly and missing
it, of course.

That'd be a great help!

[1] https://gist.github.com/c0s/cfb2b78a87f4f7f3ef4c1fa0bb5c4dea

--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Thu, Jun 8, 2017 at 1:23 AM, Vladimir Ozerov <voze...@gridgain.com> wrote:
> Hi Cos,
>
> Please try this one:
>
> 
>  class="org.apache.ignite.hadoop.fs.IgniteHadoopIgfsSecondaryFileSystem">
> 
>  class="org.apache.ignite.hadoop.fs.CachingHadoopFileSystemFactory">
> 
> 
> 
> /etc/hadoop/conf/core-site.xml
> 
> 
> 
>     
>     
> 
> 
>
> Vladimir.
>
> On Wed, Jun 7, 2017 at 11:40 PM, Konstantin Boudnik <c...@apache.org> wrote:
>
>> Guys,
>>
>> after upgrading the Bigtop stack from Ignite 1.5 to 1.9 we are seeing
>> a number of issues introduced by changed script interfaces and
>> similar. However, the one which I still can not fix so far is this.
>> The secondary file system is configured like this:
>>
>> 
>>   
>> > parent="igfsCfgBase">
>>   
>>
>>   
>>   
>>   
>>
>>   
>>   
>> 
>>   
>>   
>>   
>> 
>>   
>>
>>   
>> > class="org.apache.ignite.hadoop.fs.IgniteHadoopIgfsSecondaryFileSystem">
>>   > value='hdfs://0f6e4ed13002.bigtop.apache.org:8020'/>
>>   > value='/etc/hadoop/conf/core-site.xml'/>
>>   
>> 
>>   
>>
>> And we are getting the following error message:
>>
>> Caused by: java.lang.IllegalArgumentException: Can not create a Path
>> from an empty string
>> at org.apache.hadoop.fs.Path.checkPathArg(Path.java:126)
>> at org.apache.hadoop.fs.Path.(Path.java:134)
>> at org.apache.ignite.internal.processors.hadoop.impl.delegate.
>> HadoopBasicFileSystemFactoryDelegate.start(HadoopBasicFileSystemFactoryDe
>> legate
>> .java:165)
>> at org.apache.ignite.internal.processors.hadoop.impl.delegate.
>> HadoopCachingFileSystemFactoryDelegate.start(
>> HadoopCachingFileSystemFactoryDele
>> gate.java:58)
>> at org.apache.ignite.internal.processors.hadoop.impl.delegate.
>> HadoopIgfsSecondaryFileSystemDelegateImpl.start(
>> HadoopIgfsSecondaryFileSystemDe
>> legateImpl.java:375)
>> at org.apache.ignite.hadoop.fs.IgniteHadoopIgfsSecondaryFileS
>> ystem.start(IgniteHadoopIgfsSecondaryFileSystem.java:261)
>> at org.apache.ignite.internal.processors.igfs.IgfsImpl.<
>> init>(IgfsImpl.java:186)
>> at org.apache.ignite.internal.processors.igfs.IgfsContext.<
>> init>(IgfsContext.java:101)
>> at org.apache.ignite.internal.processors.igfs.IgfsProcessor.
>> start(IgfsProcessor.java:130)
>> at org.apache.ignite.internal.IgniteKernal.startProcessor(
>> IgniteKernal.java:1644)
>> at org.apache.ignite.internal.IgniteKernal.start(
>> IgniteKernal.java:903)
>> ... 10 more
>> Failed to start grid: Can not create a Path from an empty string
>>
>> Removing the value from cfgPath doesn't change anything. I'd
>> appreciate if someone can point me to the right direction: current
>> config examples aren't helping much either. Thanks!
>> --
>>   Take care,
>> Konstantin (Cos) Boudnik
>> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>>
>> Disclaimer: Opinions expressed in this email are those of the author,
>> and do not necessarily represent the views of any company the author
>> might be affiliated with at the moment of writing.
>>

Configuration issues with IGFS in Ignite 1.9

[Konstantin Boudnik]

Guys,

after upgrading the Bigtop stack from Ignite 1.5 to 1.9 we are seeing
a number of issues introduced by changed script interfaces and
similar. However, the one which I still can not fix so far is this.
The secondary file system is configured like this:


  

  

  
  
  

  
  

  
  
  

  

  

  
  
  

  

And we are getting the following error message:

Caused by: java.lang.IllegalArgumentException: Can not create a Path
from an empty string
at org.apache.hadoop.fs.Path.checkPathArg(Path.java:126)
at org.apache.hadoop.fs.Path.(Path.java:134)
at 
org.apache.ignite.internal.processors.hadoop.impl.delegate.HadoopBasicFileSystemFactoryDelegate.start(HadoopBasicFileSystemFactoryDelegate
.java:165)
at 
org.apache.ignite.internal.processors.hadoop.impl.delegate.HadoopCachingFileSystemFactoryDelegate.start(HadoopCachingFileSystemFactoryDele
gate.java:58)
at 
org.apache.ignite.internal.processors.hadoop.impl.delegate.HadoopIgfsSecondaryFileSystemDelegateImpl.start(HadoopIgfsSecondaryFileSystemDe
legateImpl.java:375)
at 
org.apache.ignite.hadoop.fs.IgniteHadoopIgfsSecondaryFileSystem.start(IgniteHadoopIgfsSecondaryFileSystem.java:261)
at 
org.apache.ignite.internal.processors.igfs.IgfsImpl.(IgfsImpl.java:186)
at 
org.apache.ignite.internal.processors.igfs.IgfsContext.(IgfsContext.java:101)
at 
org.apache.ignite.internal.processors.igfs.IgfsProcessor.start(IgfsProcessor.java:130)
at 
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1644)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:903)
... 10 more
Failed to start grid: Can not create a Path from an empty string

Removing the value from cfgPath doesn't change anything. I'd
appreciate if someone can point me to the right direction: current
config examples aren't helping much either. Thanks!
--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.

Re: Fwd: Persistent Distributed Store Metrics

[Konstantin Boudnik]

On Mon, Jun 05, 2017 at 07:41PM, Dmitriy Setrakyan wrote:
> On Mon, Jun 5, 2017 at 6:46 PM, Konstantin Boudnik <c...@apache.org> wrote:
> 
> > Wow, hold on - as far as I remember there was a VOTE to accept the
> > contribution of the code into the project _on a branch_. We haven't vetted
> > its
> > inclusion into the next release, We are still at the phase of getting
> > familiar
> > with the code.
> >
> 
> Cos, the community has been vetting the inclusion of the new code for over
> 3 weeks already (the process and dates are documented here [2]). To be
> honest, I am not sure what the appropriate time frame should be, but I
> would think that a month would be a good check-in point.

I would think it should be as long as we, as the community, are comfortable
with the massive change coming into the release. We already been through the
discussion on the timing, etc. and I don't want to harp on that.

> There is also an active stabilization thread for the persistence branch
> [3]. I encouraged the community to get involved and post any questions or
> concerns there as well.
> 
> There is an upcoming in-memory computing conference that is coming up in
> June in Amsterdam [4], where there are many Ignite talks scheduled. It
> would be great to be able to talk about the persistence features of Ignite
> there as well. I would like to ask the community to mobilize with reviewing
> the donated code, so we could have something concrete to tell the audience
> on the conference.

I am sure that having the code on the branch is good enough to be able to talk
about this. Having this in the release isn't really a contingency to be able
to make a presentation, right?

Cos

> [2]
> http://incubator.apache.org/ip-clearance/persistent-distributed-store-ignite.html
> [3]
> http://apache-ignite-developers.2346864.n4.nabble.com/Persistent-Store-Stabilization-for-release-td18288.html
> [4] https://imcsummit.org/
> 
> 
> 
> > And from what I am seeing in the discussions like this [1], we need to be
> > extra careful.
> >
> 
> I would keep the discussion in [1] separate from the persistence store.
> These are 2 unrelated issues. I will respond on [1] either today or
> tomorrow, but I agree in general that it should be fixed ASAP.
> 
> 
> > BTW, you have sent this email 9 days before the vote had happened! A bit
> > too
> > soon, if you ask me.
> >
> 
> Cos, this email was sent 1 week after the initial donated code branch was
> presented to the community (see [2] above). The developers involved were
> eager to make it available to the users as soon as possible, but no code
> has been merged to the master branch yet.
> 
> I would like to encourage everyone in the community to participate in the
> persistence branch coding discussions, like the one in this thread, and
> familiarize themselves with the code.
> 
> 
> >
> > [1] https://is.gd/UQCr51
> >
> > Cos
> >
> > On Wed, May 17, 2017 at 11:16AM, Dmitriy Govorukhin wrote:
> > > Folk,
> > >
> > > As you know, ignite 2.1 will contain new module (pds), it will be
> > > provide ability to store data on disk. Let's discuss what type of
> > > metrics we need for this?
> > > I think it must be metrics per memory policy, per cache, checkpoint,
> > > and global metrics which will be aggregate all metrics.
> > >
> > > I did sketch.
> > >
> > > PersistentStoreMetrics.java
> > >
> > > public interface PersistentStoreMetrics {
> > >
> > > // Global metrics.
> > >
> > > public long getMemorySize();
> > >
> > > public long getDiskSize();
> > >
> > > public long getPagesInMemory();
> > >
> > > public long getPagesSizeInMemory();
> > >
> > > public long getPagesOnDisk();
> > >
> > > public long getPagesSizeOnDisk();
> > >
> > > public long getFreePages();
> > >
> > > public long getFreePagesSize();
> > >
> > > public long getDirtyPages();
> > >
> > > public long getDirtyPagesSize();
> > >
> > > public long walLog();
> > >
> > > public long walLogSize();
> > >
> > > // Frequency.
> > >
> > > public long getPagesRead();
> > >
> > > public long getPagesWrite();
> > >
> > > public long getFsync();
> > >
> > > public long getWal();
> > >
> > > public long getAverageWalFsyncTime();
> > >
> > > // Per cache.
&g

Re: Persistent Distributed Store Metrics

[Konstantin Boudnik]

Wow, hold on - as far as I remember there was a VOTE to accept the
contribution of the code into the project _on a branch_. We haven't vetted its
inclusion into the next release, We are still at the phase of getting familiar
with the code. 

And from what I am seeing in the discussions like this [1], we need to be
extra careful.

BTW, you have sent this email 9 days before the vote had happened! A bit too
soon, if you ask me.

[1] https://is.gd/UQCr51

Cos

On Wed, May 17, 2017 at 11:16AM, Dmitriy Govorukhin wrote:
> Folk,
> 
> As you know, ignite 2.1 will contain new module (pds), it will be
> provide ability to store data on disk. Let's discuss what type of
> metrics we need for this?
> I think it must be metrics per memory policy, per cache, checkpoint,
> and global metrics which will be aggregate all metrics.
> 
> I did sketch.
> 
> PersistentStoreMetrics.java
> 
> public interface PersistentStoreMetrics {
> 
> // Global metrics.
> 
> public long getMemorySize();
> 
> public long getDiskSize();
> 
> public long getPagesInMemory();
> 
> public long getPagesSizeInMemory();
> 
> public long getPagesOnDisk();
> 
> public long getPagesSizeOnDisk();
> 
> public long getFreePages();
> 
> public long getFreePagesSize();
> 
> public long getDirtyPages();
> 
> public long getDirtyPagesSize();
> 
> public long walLog();
> 
> public long walLogSize();
> 
> // Frequency.
> 
> public long getPagesRead();
> 
> public long getPagesWrite();
> 
> public long getFsync();
> 
> public long getWal();
> 
> public long getAverageWalFsyncTime();
> 
> // Per cache.
> 
> public PersistentStoreCacheMetrics cache(String name);
> 
> public PersistentStoreCacheMetrics cache(int cacheId);
> 
> // For last checkpoint.
> 
> public PersistentStoreCheckpointMetrics getLastCheckPoint();
> }
> 
> >>>
> 
> PersistentStoreCacheMetrics.java
> 
> public interface PersistentStoreCacheMetrics {
> 
> public String name();
> 
> public double getFillFactor();
> 
> public double getFillFactor(int part);
> 
> public long getMemorySize();
> 
> public long getDiskSize();
> 
> public long getPagesInMemory();
> 
> public long getPagesSizeInMemory();
> 
> public long getPagesOnDisk();
> 
> public long getPagesSizeOnDisk();
> 
> public long getFreePages();
> 
> public long getFreePagesSize();
> 
> public long getDirtyPages();
> 
> public long getDirtyPagesSize();
> 
> public long getPagesRead();
> 
> public long getPagesWritten();
> }
> 
> >>>
> 
> PersistentStoreCheckpointMetrics.java
> 
> public interface PersistentStoreCheckpointMetrics {
> 
> public long getTotalPages();
> 
> //TODO Page type is internal?
> public long[] pagesType();
> 
> public long getExecutingTime();
> 
> public long getFsyncTime();
> 
> public long getPagesCopyOnWrite();
> }

[jira] [Created] (IGNITE-5413) Ignite shouldn't expose nor send (clear-text) env variables to a 3rd endpoint

[Konstantin Boudnik (JIRA)]

Konstantin Boudnik created IGNITE-5413:
--

 Summary: Ignite shouldn't expose nor send (clear-text) env 
variables to a 3rd endpoint
 Key: IGNITE-5413
 URL: https://issues.apache.org/jira/browse/IGNITE-5413
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.1.4
Reporter: Konstantin Boudnik
Priority: Blocker
 Fix For: 2.1


Apache Ignite is periodically accessing to 
https://ignite.run/update_status_ignite-plain-text.php

It is enabled by default at least in org.apache.ignite:ignite-core:1.9.0, but 
of course it has been happening for a long time.

Corresponding code is 
https://github.com/apache/ignite/blob/1d0b0765134a81e6626a9ef1c70939085f954847/modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/ClusterProcessor.java#L81-L82

Posting JVM env variable (or any other user's specific information) without an 
explicit user's consent is a bad idea and should be disabled by default. 
See  
https://github.com/apache/ignite/blob/1d0b0765134a81e6626a9ef1c70939085f954847/modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridUpdateNotifier.java#L313
for more details.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

[Konstantin Boudnik]

All great points, thank you Raúl!

+1
--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Fri, May 19, 2017 at 4:08 AM, Raúl Kripalani <raul@evosent.com> wrote:
> Nice! Sorry for being out of touch lately. I'm glad to see GridGain donate
> additional components to the Ignite ecosystem.
>
> IIUC:
>
>1) GG implemented PDS for a commercial customer, but it is now being
> donated to the community => I assume GG has obtained clearance from that
> customer first.
>
>2) It appears that PDS is a module of Ignite, but changes are required
> to the core in the existing codebase for the integration to work => Correct?
>
>3) We use SemVer [1], and there have been talks about potentially
> merging this into 2.1, rather than 3.x. => Is it safe to assume that
> integrating the PDS will not lead to any *breaking changes* in APIs?
>
>4) I believe the VOTE to accept the donation should be *decoupled* from
> any VOTEs –or decisions– on *what* to do with the donation and *when* to do
> it. Although it's sane and healthy to discuss the future of the donation
> inside its new home, ultimately there should be no time pressure by the
> donor with regards to the ultimate destination of their donation.
>
>5) Normally the code belonging to the donation is first put in
> "quarantine" inside the codebase, i.e. a separate repo or a separate
> branch, where the community can review, test, peruse, integrate, etc. In
> this sense, I agree with Dmitriy. The natural fit seems to be a branch in
> this case.
>
> If we just focus on whether to accept the donation and place the code into
> a separate branch –without pressure to release for 2.1, just a vision to do
> so– would there be consensus?
>
> [1] http://semver.org/
>
> Cheers,
> Raúl.
>
>
> On Fri, May 19, 2017 at 2:36 AM, Dmitriy Setrakyan <dsetrak...@apache.org>
> wrote:
>
>> Cos, Roman,
>>
>> This has nothing to do with any deadlines, but rather with an easier and
>> more efficient process.
>>
>> I am not sure how keeping the code in a separate code base is better for
>> the community than keeping it in a separate Apache Ignite branch, where we
>> can integrate it into Ignite CI process, run tests, stabilize, all while
>> the community is getting familiar with it. Keeping the code base outside of
>> Apache Ignite GIT makes it much more difficult to integrate or stabilize.
>> Moreover, if the code is in a separate Ignite branch, we can get the
>> community help to work on it and discuss issues on the dev list.
>>
>> I would propose to move the code to a separate branch in Apache Ignite
>> right now, especially given that the paperwork has already been taken care
>> of. We can still decide within the Ignite community not to accept it down
>> the road, in which case we can toss away the branch.
>>
>> Would you agree with this approach?
>>
>> D.
>>
>> On Wed, May 17, 2017 at 5:01 PM, Roman Shaposhnik <r...@apache.org> wrote:
>>
>> > On Wed, May 17, 2017 at 3:04 PM, Konstantin Boudnik <c...@apache.org>
>> > wrote:
>> > > Well, here's the issue with "simple move from private repo". This is a
>> > > huge chunk of code. And while employees of Gridgain are quite familiar
>> > > with it (or so I presume), the rest of the community is not. I, for
>> > > one, don't consider that the fact it has been tested and integrated
>> > > with AI 2.0 and, effectively, outside of AI 2.0 is a reasonable "go"
>> > > criteria.
>> >
>> > Cos is absolutely correct here. Strong +1 to the above.
>> >
>> > > I am sorry that I have to repeat this after 1.5 years after project's
>> > > graduation from the Incubator. However, I, personally and otherwise,
>> > > feel like a community process of creating software should be thought
>> > > through in the spirit of the community, rather than "release dates" or
>> > > "feature richness". Which means that the community has to be on board
>> > > with the decisions like this. And "on board" doesn't mean "majority of
>> > > the votes" as we, fortunately, aren't playing in democracy @apache.
>> > > Release dates are relevant to an entity, building and selling
>> > > products. in Apache we're are working on projects, and while releases

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

[Konstantin Boudnik]

Well, here's the issue with "simple move from private repo". This is a
huge chunk of code. And while employees of Gridgain are quite familiar
with it (or so I presume), the rest of the community is not. I, for
one, don't consider that the fact it has been tested and integrated
with AI 2.0 and, effectively, outside of AI 2.0 is a reasonable "go"
criteria.

I am sorry that I have to repeat this after 1.5 years after project's
graduation from the Incubator. However, I, personally and otherwise,
feel like a community process of creating software should be thought
through in the spirit of the community, rather than "release dates" or
"feature richness". Which means that the community has to be on board
with the decisions like this. And "on board" doesn't mean "majority of
the votes" as we, fortunately, aren't playing in democracy @apache.
Release dates are relevant to an entity, building and selling
products. in Apache we're are working on projects, and while releases
are important here, they convey a very different meaning.

We also have this documented contribution process [1]. Is there a good
reason to circumvent it in this particular case?

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-1.CreateGitHubpull-request

Thanks,
  Cos
--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Wed, May 17, 2017 at 12:55 PM, Denis Magda <dma...@apache.org> wrote:
> Hi Cos, thanks,
>
> My view is the following.
>
> Here is an endeavor to release AI 2.1 with improved DDL, .NET and C++ 
> capabilities in June (this is discussed in a separate thread).
>
> It will be much better if the storage can get into that release as well to 
> make it even more solid.
>
> As for the stabilization and testing the feature has already been integrated 
> and perfectly tested with recent AI 2.0 version. This is why, personally, I 
> don’t see any reason why this can affect the vote or potential release date. 
> Simply, we just need to move it from the private repo to the ASF one.
>
> —
> Denis
>
>> On May 17, 2017, at 1:03 PM, Konstantin Boudnik <c...@apache.org> wrote:
>>
>> Hey guys,
>>
>> I will try to look at it before the week's end. I wonder what's the
>> rush for the vote? The normal development process for any big feature
>> is to bring the code to a brunch, run through a stabilization cycle
>> and then merge into the mainline. Why are we doing something different
>> this time around?
>>
>> Regards,
>>  Cos
>> --
>>  Take care,
>> Konstantin (Cos) Boudnik
>> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>>
>> Disclaimer: Opinions expressed in this email are those of the author,
>> and do not necessarily represent the views of any company the author
>> might be affiliated with at the moment of writing.
>>
>>
>> On Tue, May 16, 2017 at 6:44 PM, Denis Magda <dma...@apache.org> wrote:
>>> Cos, Roman,
>>>
>>> Would you have time to look at the donation in the nearest time? It’s useful
>>> to hear your feedback before the voting is started.
>>>
>>> —
>>> Denis
>>>
>>> Begin forwarded message:
>>>
>>> From: Denis Magda <dma...@apache.org>
>>> Subject: Re: GridGain Donates Persistent Distributed Store To ASF (Apache
>>> Ignite)
>>> Date: May 15, 2017 at 4:37:43 PM PDT
>>> To: dev@ignite.apache.org
>>> Reply-To: dev@ignite.apache.org
>>>
>>> The receipt of the software grant (the persistent store) was acknowledged by
>>> Craig Russel.
>>>
>>> Now, we need to move on with this
>>>
>>> In the meanwhile, I’ve prepared the IP Clearance page referring to the
>>> template below but failed to commit the changes to ASF repo:
>>> http://incubator.apache.org/ip-clearance/ip-clearance-template.html
>>>
>>> *Roman S.*, *Cos*, could you help me with this by granting karma or
>>> committing the form from under your account?
>>>
>>>
>>> Roman, Cos, could you help with this?
>>>
>>> *Alex G.*, please add Apache 2.0 copyrights to all source files that are
>>> going to be donated. Presently there is no copyright at all.
>>>
>>> Everyone interested please spend some time exploring the store's docs and
>>> sources shared in my previous email. If no one has any concerns I will
>>&g

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

[Konstantin Boudnik]

Hey guys,

I will try to look at it before the week's end. I wonder what's the
rush for the vote? The normal development process for any big feature
is to bring the code to a brunch, run through a stabilization cycle
and then merge into the mainline. Why are we doing something different
this time around?

Regards,
  Cos
--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Tue, May 16, 2017 at 6:44 PM, Denis Magda <dma...@apache.org> wrote:
> Cos, Roman,
>
> Would you have time to look at the donation in the nearest time? It’s useful
> to hear your feedback before the voting is started.
>
> —
> Denis
>
> Begin forwarded message:
>
> From: Denis Magda <dma...@apache.org>
> Subject: Re: GridGain Donates Persistent Distributed Store To ASF (Apache
> Ignite)
> Date: May 15, 2017 at 4:37:43 PM PDT
> To: dev@ignite.apache.org
> Reply-To: dev@ignite.apache.org
>
> The receipt of the software grant (the persistent store) was acknowledged by
> Craig Russel.
>
> Now, we need to move on with this
>
> In the meanwhile, I’ve prepared the IP Clearance page referring to the
> template below but failed to commit the changes to ASF repo:
> http://incubator.apache.org/ip-clearance/ip-clearance-template.html
>
> *Roman S.*, *Cos*, could you help me with this by granting karma or
> committing the form from under your account?
>
>
> Roman, Cos, could you help with this?
>
> *Alex G.*, please add Apache 2.0 copyrights to all source files that are
> going to be donated. Presently there is no copyright at all.
>
> Everyone interested please spend some time exploring the store's docs and
> sources shared in my previous email. If no one has any concerns I will
> proceed with the donation formalities.
>
> —
> Denis
>
> On May 12, 2017, at 2:59 PM, Denis Magda <dma...@apache.org> wrote:
>
> Folks,
>
> The repository with the donation is ready and available for review:
> https://github.com/agoncharuk/ignite/tree/pds-donate
>
> Big and main part of the sources is aggregated in “modules/pds”. The rest,
> that connects Apache Ignite memory architecture and SQL engine is under
> “core” and “indexing” modules. Alex Goncharuk should be able to point to
> specific files or commits if required.
>
> Here is a description:
> * Persistent Store Overview:
> https://cwiki.apache.org/confluence/display/IGNITE/Persistent+Store+Overview
> * Persistent Store Internal Design:
> https://cwiki.apache.org/confluence/display/IGNITE/Persistent+Store+Internal+Design
>
> The SGA will be signed and sent on Monday.
>
> In the meanwhile, I’ve prepared the IP Clearance page referring to the
> template below but failed to commit the changes to ASF repo:
> http://incubator.apache.org/ip-clearance/ip-clearance-template.html
>
> *Roman S.*, *Cos*, could you help me with this by granting karma or
> committing the form from under your account?
>
> —
> Denis
>
> On Apr 25, 2017, at 9:56 AM, Konstantin Boudnik <c...@boudnik.org> wrote:
>
> While no one is suggesting an IP trap laid out in the non-SGA'ed code
> in this particular case, we don't want to setup a precedent like this.
>
> From the overall ASF perspective I +1 what Roman has just said.
>
> Thanks,
> --
> Take care,
> Konstantin (Cos) Boudnik
>
>
> On Wed, Apr 19, 2017 at 11:41 PM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
>
> On Wed, Apr 19, 2017 at 6:21 PM, Dmitriy Setrakyan
> <dsetrak...@apache.org> wrote:
>
> On Wed, Apr 19, 2017 at 6:00 PM, Konstantin Boudnik <c...@apache.org> wrote:
>
> On Tue, Apr 18, 2017 at 11:54PM, Dmitriy Setrakyan wrote:
>
>
> Would a standard SGA suffice here?
>
> I believe that ASF guidelines suggest that a discussion should happen
> first. Once the community gets enough information, we will move to a PMC
> vote. I was under the impression that once the PMC vote passes, then the
> SGA should be provided. Or does GridGain need to provide a signed SGA
>
> right
>
> away?
>
>
> That reminds me of that Pelosi's self-inflicted conundrum of "In order
> to see the bill, we should pass the bill" ;)
>
>
> Haha :)
>
> SGA != code. In my view, the code should be provided to the community for a
> review. But I am struggling to see why should an SGA be signed prior to the
> community accepting the donation.
>
>
> There's no such thing as SGA without a reference to a code base.
>
> Also, as I explained -- as a community member I would refuse to look
> at the code base that doesn't have a proper licensing attached to it.
> SGA established this kind of proper licensing.
>
> Now, SGA is deinetly not the only way to do so, but it is the easiest
> and since you'd have to do it anyway the most convenient for the
> community.
>
> Thanks,
> Roman.
>
>
>
>

Cloud deployment documentation is missing

[Konstantin Boudnik]

Hi guys,

I am looking at
  https://ignite.apache.org/features/deploy.html

and all of the following links are broken
http://apacheignite.readme.io/docs/aws-config
http://apacheignite.readme.io/docs/gce-configuration
http://apacheignite.readme.io/docs/generic-cloud-configuration

They all generating 404 on readme.io. Not sure if they are missing
just from 1.9 or it is a placeholder for something that will come
later on?

--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.

[jira] [Created] (IGNITE-5106) Website still contains links to to "incubator-ignite"

[Konstantin Boudnik (JIRA)]

Konstantin Boudnik created IGNITE-5106:
--

 Summary: Website still contains links to to "incubator-ignite" 
 Key: IGNITE-5106
 URL: https://issues.apache.org/jira/browse/IGNITE-5106
 Project: Ignite
  Issue Type: Bug
  Components: website
Affects Versions: 1.1.4
Reporter: Konstantin Boudnik
 Fix For: 2.0


At least some of the examples referred by the website pages are pointed to 
"incubator-ignite" mirror on the github. Which were empty for a long time.

Let's get this fixed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

[Konstantin Boudnik]

On Tue, Apr 18, 2017 at 11:54PM, Dmitriy Setrakyan wrote:
> 
> Would a standard SGA suffice here?
> 
> I believe that ASF guidelines suggest that a discussion should happen
> first. Once the community gets enough information, we will move to a PMC
> vote. I was under the impression that once the PMC vote passes, then the
> SGA should be provided. Or does GridGain need to provide a signed SGA right
> away?

That reminds me of that Pelosi's self-inflicted conundrum of "In order
to see the bill, we should pass the bill" ;)

Cos

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

[Konstantin Boudnik]

Thank you guys for quick feedback!

So I guess once this and the source code/SGA addressing concerns from Roman's
emails are available to all of us - we can reconvene for the constructive
discussion!

With regards,
  Cos

On Wed, Apr 19, 2017 at 04:46PM, Denis Magda wrote:
> >> 5. Can we have a discussion about the design of this new layer so people
> >> here
> >>   can understand better what's being offered, how to take the advantage of
> >>   it, and - most importantly - to offer their own insights and
> >> improvements
> >>   into this new subsystems before it's landed in the source code? And it
> >>   would safe a lot of time on Q as well.
> >> 
> > 
> > Yes, good idea. Denis, do you have a high level architecture for the
> > proposed persistence?
> 
> It will be prepared right after Apache Ignite 2.0 release. Presently, don’t
> have time to wrap it up in a doc form.
> 
> —
> Denis
> 
> > On Apr 18, 2017, at 10:44 PM, Dmitriy Setrakyan <dsetrak...@apache.org> 
> > wrote:
> > 
> > Cos, good questions! My answers are inline...
> > 
> > On Tue, Apr 18, 2017 at 4:17 PM, Konstantin Boudnik <c...@apache.org
> > <mailto:c...@apache.org>> wrote:
> > 
> >> Great news indeed! Thanks for sharing!
> >> 
> >> Before we jump on the voting and all that, can we have a chance to learn
> >> more
> >> about this new feature and its integration points with the rest of the
> >> platform? A few questions come to mind immediately:
> >> 
> >> 1. This is an "optional disk layer", so it could be turned off
> >> _completely_ and
> >>   have no effect on those who don't want nor need to use it, right?
> >> 
> > 
> > Yes
> > 
> > 
> >> 2. Does it have any performance implications on the in-memory operations?
> >> 
> > 
> > No, as long as the persistence is turned off, the in-memory operations will
> > not be impacted.
> > 
> > 
> >> 3. When you say it is "fully ... ANSI-99 SQL compliant fault-tolerant"
> >> does it
> >>   mean that _all_ SQL operations are now now supported through SQL or
> >> still
> >>   some of them only available through the JAVA APIs? THe fault tolerance
> >> is
> >>   for the data-center only as before, right? No new WAN-able HA has been
> >>   introduced?
> >> 
> > 
> > Well... I would say most SQL operations are going to be supported,
> > including CREATE, DROP, INSERT, UPDATE, DELETE, SELECT, and of course,
> > distributed joins.
> > 
> > And yes, you are right about the fault tolerance.
> > 
> > 
> >> 4. With addition of this new model, are there any backward compatibility
> >>   issues that would affect Ignite's application developers?
> >> 
> > 
> > I don't think so. All incompatible changes should have been introduced in
> > 2.0. I will let other community members comment here...
> > 
> > 
> >> 5. Can we have a discussion about the design of this new layer so people
> >> here
> >>   can understand better what's being offered, how to take the advantage of
> >>   it, and - most importantly - to offer their own insights and
> >> improvements
> >>   into this new subsystems before it's landed in the source code? And it
> >>   would safe a lot of time on Q as well.
> >> 
> > 
> > Yes, good idea. Denis, do you have a high level architecture for the
> > proposed persistence?
> > 
> > 
> >> 
> >> I am confused a little bit by these two slightly controversial statements:
> >> - "GG... has been developing a unique distributed persistent store...for
> >> more
> >>  than a year in-house"
> >> - "we decided at GridGain that this tremendous feature should be open
> >> source
> >>  from the very beginning"
> >> 
> >> So, it sounds like the code has been under the development for a while and
> >> it
> >> isn't opened up "from the very beginning", unless there's a new meaning of
> >> the
> >> word beginning I am not aware of just yet :) It feels like this could be a
> >> significant amount of the code to be digested by the community.
> >> 
> > 
> > Yes, you are right. Many of us wanted to open source this functionality
> > from the get go. In any case, this makes a great addition to the project. I
> > hope we will be able to provide enough documentation and feedback on the
> &

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

[Konstantin Boudnik]

Great news indeed! Thanks for sharing!

Before we jump on the voting and all that, can we have a chance to learn more
about this new feature and its integration points with the rest of the
platform? A few questions come to mind immediately:

1. This is an "optional disk layer", so it could be turned off _completely_ and
   have no effect on those who don't want nor need to use it, right?
2. Does it have any performance implications on the in-memory operations?
3. When you say it is "fully ... ANSI-99 SQL compliant fault-tolerant" does it
   mean that _all_ SQL operations are now now supported through SQL or still
   some of them only available through the JAVA APIs? THe fault tolerance is
   for the data-center only as before, right? No new WAN-able HA has been
   introduced?
4. With addition of this new model, are there any backward compatibility
   issues that would affect Ignite's application developers?
5. Can we have a discussion about the design of this new layer so people here
   can understand better what's being offered, how to take the advantage of
   it, and - most importantly - to offer their own insights and improvements
   into this new subsystems before it's landed in the source code? And it
   would safe a lot of time on Q as well.

I am confused a little bit by these two slightly controversial statements:
- "GG... has been developing a unique distributed persistent store...for more
  than a year in-house"
- "we decided at GridGain that this tremendous feature should be open source
  from the very beginning"

So, it sounds like the code has been under the development for a while and it
isn't opened up "from the very beginning", unless there's a new meaning of the
word beginning I am not aware of just yet :) It feels like this could be a
significant amount of the code to be digested by the community.

Appreciate your thoughts on this! Thanks,
  Cos

On Mon, Apr 17, 2017 at 07:37PM, Denis Magda wrote:
> Igniters,
> 
> GridGain, as one of the most active Apache Ignite contributors, has been
> developing a unique distributed persistent store specifically for Apache
> Ignite for more than a year in-house. It’s a fully ACID and ANSI-99 SQL
> compliant fault-tolerant solution. 
> 
> The store transparently integrates with Apache Ignite as an optional disk
> layer (in addition to the existing RAM layer) via the new page memory
> architecture that to be released in Apache Ignite 2.0. This allows storing
> supersets of data on disk while having a subset in memory not worrying about
> that you forgot to preload (warmup) your caches!
> 
> Assuming that the storage goes to ASF as a part of Apache Ignite 2.1 release
> the following will be supported by Ignite out-of-the-box:
> 
> * SQL queries execution over the data that is both in RAM and on disk: no
> need to preload the whole data set in memory.
> 
> * Cluster instantaneous restarts: once your cluster ring is recovered after
> a restart your applications are fully operational even if they highly
> utilize SQL queries.
> 
> As for the use cases, it means that Apache Ignite will be possible to use as
> a distributed SQL database with memory-first concept.
> 
> And we decided at GridGain that this tremendous feature should be open
> source from the very beginning.
> 
> Guys, could you advise how I can start official donation process?
> 
> —
> Denis
> 
> 
>  
> 
>
>  

Re: Move documentation from readme.io to GitHub pages

[Konstantin Boudnik]

I hate to be that guy, but mentors warned this very project no to do
this in the first place. At least once [1] on the dev@, and a few
times off-line

[1] https://is.gd/ZRPOrH

Cos

--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Tue, Apr 11, 2017 at 9:57 PM, Dmitriy Setrakyan
 wrote:
> Pavel,
>
> We all agree that the documentation should be in our GIT repo in either
> Markdown or AsciiDoc format. However, it is a very big undertaking to
> migrate it from readme and properly structure it. If anyone in the
> community would volunteer, would be great.
>
> D.
>
> On Tue, Apr 11, 2017 at 9:36 PM, Pavel Tupitsyn 
> wrote:
>
>> > Git approach is no way to go for us because all the documentation has to
>> be hosted on ASF side
>>
>> Well, our Git repository [1] is hosted by ASF, isn't it?
>> GitHub pages just generates HTML from MarkDown via Jekyll [2] static site
>> generator.
>>
>> I understand the concern about GitHub pages, though.
>> And Igor is right about different versions, seems like it may be not so
>> easy with GH pages.
>>
>>
>> So I propose to use Jekyll, but do not use GitHub pages:
>> * Keep documentation in our Git repository in MarkDown format
>> * Generate HTML when release comes out and upload it to ignite.apache.org
>> (same as we do for API docs [3])
>>
>> Seems to be easy enough. The hardest part is to come up with a good
>> template.
>>
>> Thoughts?
>>
>>
>> [1] https://git-wip-us.apache.org/repos/asf?p=ignite.git
>> [2] https://jekyllrb.com/
>> [3] https://ignite.apache.org/releases/1.8.0/javadoc/
>>
>> On Tue, Apr 11, 2017 at 7:09 PM, Denis Magda  wrote:
>>
>> > Pavel,
>> >
>> > I totally agree that it’s becoming more and more inconvenient to run the
>> > documentation on readme.io . At the same time the Git
>> > approach is no way to go for us because all the documentation has to be
>> > hosted on ASF side. Presently we violate this policy and I look forward
>> we
>> > fix it pretty soon.
>> >
>> > So, in general, all the documentation content has to become a part of
>> > Apache Ignite site and available from there. Here are some of the
>> examples
>> > of another ASF projects:
>> > http://spark.apache.org/docs/2.1.0/ > >
>> > https://zeppelin.apache.org/contribution/documentation.html <
>> > https://zeppelin.apache.org/contribution/documentation.html>
>> > https://hadoop.apache.org/docs/r2.7.2/ > > docs/r2.7.2/>
>> >
>> > Are you aware of any ready-to-be-used documentation libs that can be
>> > easily reused by us?
>> >
>> > —
>> > Denis
>> >
>> > > On Apr 11, 2017, at 2:02 AM, Pavel Tupitsyn 
>> > wrote:
>> > >
>> > > Igniters,
>> > >
>> > > Currently we host documentation on
>> > > apacheignite.readme.io (and also apacheignite-net.readme.io,
>> > > apacheignite-cpp.readme.io, apacheignite-mix.readme.io, etc).
>> > >
>> > > readme.io has a lot of problems mostly due to lack of proper version
>> > > control:
>> > > * Each "version" is just a copy. When fixing something, you have to
>> > update
>> > > all versions.
>> > > * No good way to review changes.
>> > > * "Propose edit" functionality is a joke. You can only accept or reject
>> > an
>> > > edit, no way to communicate with contributor, etc
>> > >
>> > > GitHub Pages solves all these problems:
>> > > https://github.com/blog/2233-publish-your-project-
>> > documentation-with-github-pages
>> > >
>> > > Basically, we'll have a separate folder in our Git repository where
>> > > documentation is stored in markdown format.
>> > > This way the process for updating docs is exactly the same as any other
>> > > code change.
>> > > Pull request with new feature can contain the docs for this feature,
>> and
>> > so
>> > > on.
>> > >
>> > > Thoughts?
>> >
>> >
>>

Re: Write access to Apache Ignite repository

[Konstantin Boudnik]

+1
PMC members don't have _any_ special privileges when it gets to the code access

Cos
--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Fri, Mar 17, 2017 at 1:13 PM, Dmitriy Setrakyan
 wrote:
> All committers, PMC or not, should have write access to the code.
>
> On Fri, Mar 17, 2017 at 12:54 PM, Denis Magda  wrote:
>
>> CC-ing the dev list.
>>
>> Igor, it looks strange to me. I received a notification saying that
>> ‘isapego’ was established. Did you setup the password?
>>
>> BTW, if to refer to this page [1] then only PMC members have a write
>> access to the repository:
>> They have write access to the code repository,
>>
>> *Dmitriy, Cos*, am I missing something?
>>
>> *Igor Rudyak*, *Pavel*, *Andrey Gura*, do you have the write access?
>>
>> [1] http://www.apache.org/foundation/how-it-works.html#pmc-members <
>> http://www.apache.org/foundation/how-it-works.html#pmc-members>
>>
>> —
>> Denis
>>
>> > On Mar 17, 2017, at 7:36 AM, Igor Sapego  wrote:
>> >
>> > It seems like I still do not have write access to apache repository.
>> >
>> > Best Regards,
>> > Igor
>>
>>

Re: Getting Access to Ignite's blog on ASF

[Konstantin Boudnik]

And done. Also, assigned you as 'admin' so you can do things if you need to ;)

Thanks,
  Cos
--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Sun, Mar 5, 2017 at 1:59 PM, Denis Magda <dma...@apache.org> wrote:
> Cos,
>
> Had hard time looking for the “login” link ) Please add ‘dmagda’ account to 
> Ignite’s blog.
>
> —
> Denis
>
>> On Mar 4, 2017, at 7:19 PM, Konstantin Boudnik <c...@apache.org> wrote:
>>
>> Hi Denis.
>>
>> I reckon you'd need to register on the roller (that blog site) and
>> share your account name with me, so I can add this to the ignite's
>> blog.
>>
>> --
>> Regards,
>>  Konstantin (Cos) Boudnik
>> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>>
>> Disclaimer: Opinions expressed in this email are those of the author,
>> and do not necessarily represent the views of any company the author
>> might be affiliated with at the moment of writing.
>>
>>
>> On Fri, Mar 3, 2017 at 1:52 PM, Denis Magda <dma...@apache.org> wrote:
>>> Hi Cos,
>>>
>>> Could you explain how I can sign in into Ignite’s blog on ASF and edit it?
>>> https://blogs.apache.org/ignite/
>>>
>>> —
>>> Denis
>

Re: Ignite ASF Confluence edit rights

[Konstantin Boudnik]

Yup, this is a contribution all right. Anyone with admin creds for the Ignite
space should be able to go and add permissions to a person with Wiki account. 

Cos

On Mon, Jan 23, 2017 at 11:43AM, Denis Magda wrote:
> Dmitriy, Cos,
> 
> Does contributors (not committers) have write permissions on Ignite wiki?
> Looks like they don’t.
> 
> Alexander, as a temporal solution, please ask the committer that reviewed
> and merged your changes to update this page as well.
> 
> —
> Denis
> 
> > On Jan 23, 2017, at 2:22 AM, Alexander Fedotov 
> >  wrote:
> > 
> > Hi folks,
> > 
> > In scope of the IGNITE-3207
> >  Ignite 2.0 Migration
> > Guide needs to be updated
> > Apache+Ignite+2.0+Migration+Guide
> > 
> > .
> > Unfortunately, currently I don't have rights to edit the page.
> > Who can grant me ones?
> > 
> > -- 
> > Kind regards,
> > Alexander.
> 

Re: Ignite ASF blog

[Konstantin Boudnik]

The blog
https://blogs.apache.org/ignite/

has been configured. I have admin rights so please let me know if you want to
start contributing and I will grant you the credentials for it.

Cheers,
  Cos

On Fri, Jan 13, 2017 at 08:39AM, Konstantin Boudnik wrote:
> FYI
> https://issues.apache.org/jira/browse/INFRA-13324
> 
> once the JIRA is finished, we'd have an office Apache blog for Ignite, listed
> and syndicated across all ASF resources. Hence raising the visibility of the
> project.
> 
> Regards,
>   Cos
> 
> On Sat, Nov 26, 2016 at 01:21PM, Konstantin Boudnik wrote:
> > Gents, 
> > 
> > I would encourage you to use
> > 
> > https://blogs.apache.org/
> > 
> > as this place gets contant attention of the ASF media team and all the blogs
> > here got quite a bit of the spot light. In fact, I would encourage this 
> > group
> > to start using it. I'd be happy to help to set this up.
> > 
> > Cos
> > 
> > On Wed, Nov 23, 2016 at 10:34AM, Denis Magda wrote:
> > > Pavel,
> > > 
> > > Do you mind blogging about ASP.NET session state [1] and Entity Framework 
> > > 2nd level cache [2] support after 1.8 release goes public?
> > > 
> > > Also I would remind everyone in the community that it’s always welcomed 
> > > to share your experience or Ignite related news over blog posts. We track 
> > > all the posts on this page.
> > > https://ignite.apache.org/blogs.html 
> > > <https://ignite.apache.org/blogs.html>
> > > 
> > > 
> > > [1] https://apacheignite-net.readme.io/docs/aspnet-session-state-caching 
> > > <https://apacheignite-net.readme.io/docs/aspnet-session-state-caching>
> > > [2] 
> > > https://apacheignite-net.readme.io/docs/entity-framework-second-level-cache
> > >  
> > > <https://apacheignite-net.readme.io/docs/entity-framework-second-level-cache>
> > > 
> > > —
> > > Denis

Ignite ASF blog [Was: Blogging about new .NET features]

[Konstantin Boudnik]

FYI
https://issues.apache.org/jira/browse/INFRA-13324

once the JIRA is finished, we'd have an office Apache blog for Ignite, listed
and syndicated across all ASF resources. Hence raising the visibility of the
project.

Regards,
  Cos

On Sat, Nov 26, 2016 at 01:21PM, Konstantin Boudnik wrote:
> Gents, 
> 
> I would encourage you to use
> 
> https://blogs.apache.org/
> 
> as this place gets contant attention of the ASF media team and all the blogs
> here got quite a bit of the spot light. In fact, I would encourage this group
> to start using it. I'd be happy to help to set this up.
> 
> Cos
> 
> On Wed, Nov 23, 2016 at 10:34AM, Denis Magda wrote:
> > Pavel,
> > 
> > Do you mind blogging about ASP.NET session state [1] and Entity Framework 
> > 2nd level cache [2] support after 1.8 release goes public?
> > 
> > Also I would remind everyone in the community that it’s always welcomed to 
> > share your experience or Ignite related news over blog posts. We track all 
> > the posts on this page.
> > https://ignite.apache.org/blogs.html <https://ignite.apache.org/blogs.html>
> > 
> > 
> > [1] https://apacheignite-net.readme.io/docs/aspnet-session-state-caching 
> > <https://apacheignite-net.readme.io/docs/aspnet-session-state-caching>
> > [2] 
> > https://apacheignite-net.readme.io/docs/entity-framework-second-level-cache 
> > <https://apacheignite-net.readme.io/docs/entity-framework-second-level-cache>
> > 
> > —
> > Denis

Re: [RESULT] [VOTE] Apache Ignite 1.8.0 Release (RC1)

[Konstantin Boudnik]

I don't think INFRA has any control of how something is pushed into Maven
central. Interestingly enough, looking thought the artifacts in Maven, I see
a whole bunch of the component that are pulled from the latest releases yet
are presented in the Maven. Say geospacial is only published up to 1.2.0, etc.

Looks like some house-cleaning needs to be done.
  Cos

On Mon, Dec 12, 2016 at 12:42PM, Denis Magda wrote:
>Cos, Roman S.,
>Is there any hint on or some other way on how we can get attention of
>Apache Infra team to this issue?
>https://issues.apache.org/jira/browse/INFRA-13073
>a**
>Denis
> 
>  On Dec 10, 2016, at 7:45 AM, Denis Magda  wrote:
>  Created an INFRA ticket to double check that this is not an
>  infrastructure issue
>  https://issues.apache.org/jira/browse/INFRA-13073
>  
>    >
> 
>  Sergey, Anton, please keep an eye on it.
> 
>  a**
>  Denis
> 
>On Dec 10, 2016, at 6:49 AM, Denis Magda  wrote:
> 
>Well, thanks for pointing out to this.
> 
>Sergey, looks like you missed something at some releasing phase. If I
>create a project from 1.8 examples then Maven cana**t locate binaries
>for 1.8.0. Please fix this ASAP.
> 
>a**
>Denis
> 
>  On Dec 10, 2016, at 3:57 AM, ae**c,**c,**@163 <18624049...@163.com>
>  wrote:
> 
>  Hi:
> 
>  http://repo.maven.apache.org/maven2/org/apache/ignite
> 
>  the site above, not updated?
> 
>  aa*" 2016/12/9 22:06, Sergey Kozlov aa**e**:
> 
>Hi
> 
>Maven repository has been released.
> 
>
> https://repository.apache.org/content/repositories/releases/org/apache/ignite/
> 
>On Fri, Dec 9, 2016 at 4:41 PM, ae**c,**c,**@163
><18624049...@163.com> wrote:
> 
>  maven repo is not updated?
> 
>  aa*" 2016/12/9 21:37, D-*N*D-uD- 1/2D-,N* D- N*D-+-D-DEGD--oD-
>  3/4D-^2D-DEG aa**e**:
> 
>Hi,
> 
>Update notifier for 1.7.0 shows that version is up to date.
>Could anybody
>fix it please?
> 
>
> +--+
> 
>  Ignite ver. 1.7.0#20160801-sha1:383273e3f6
>  6f702de2482466dce954d570a8ccf2
>  
> +---
>  ---+
> 
>...
> 
>[16:32:54,180][INFO ][main][GridDiscoveryManager] Topology
>snapshot
>[ver=1,
>servers=1, clients=0, CPUs=4, heap=1.0GB]
>[16:33:03,833][INFO
>][ignite-update-notifier-timer][GridUpdateNotifier]
>Your version is up to date.
> 
>--
>Thanks,
>Ksenia
> 
>On Fri, Dec 9, 2016 at 4:14 PM, Pavel Tupitsyn
>
>wrote:
> 
>I've updated the site, there were commented parts on Download
>page from
> 
>  Denis, so that was easy :)
>  Main and News pages also updated.
> 
>  Just a reminder - any committer can update the site, just
>  modify files in
>  SVN, and changes will appear online:
>  https://svn.apache.org/repos/asf/ignite/site/trunk
> 
>  On Fri, Dec 9, 2016 at 1:07 PM, Vladimir Ozerov
>  
>  wrote:
> 
>  Denis,
> 
>Release has been propagated to mirrors, so you can go
>ahead with site
>update.
> 
>Vladimir.
> 
>On Fri, Dec 9, 2016 at 1:28 AM, Denis Magda
> wrote:
> 
>Great, thanks!
> 
>  Released all the docs (Java, .NET, C++, etc.) and update
>  the site
>  partially.
> 
>  I cana**t go ahead and update the downloads page [1] on
>  the site because
> 
>the
> 
>  binaries and sources havena**t been uploaded yet. I get
>  404 error every
> 
>time
> 
>  I try to download one of the below.
>  
> http://apache.osuosl.org/ignite/1.8.0/apache-ignite-1.8.0-src.zip
>  <
>  
> http://apache.osuosl.org/ignite/1.8.0/apache-ignite-1.8.0-src.zip>
>  

Re: [VOTE] Apche Ignite PMC Chair Election

[Konstantin Boudnik]

On Mon, Dec 12, 2016 at 12:12PM, Denis Magda wrote:
> Denis Magda
> 
> 
> Regardless of the fact that I’m a GridGain employee and that GridGain still
> represents the majority of our community, I would truly like to make our

One's affiliation is mostly the fact of one's biography and quite irrelevant
for the Foundation. The fact that some of the PMC members here still consider
themselves first as an employee of company X and only then the as a member of
Ignite PMC is a strong indication that we need to revisit some of the lessons
from the incubation. Without a solid separation of church and the state,
errr  the project and where the paycheck is coming from - all the yearning
for "diversity" is just a wishful thinking.

Cos

> community more diversified and transparent and less dependent of GridGain.
> Being a PMC chair will motivate me to learn even more about Apache
> processes, principles and leverage the overall knowledge and fully relying
> on your support and experience of other open source project move our
> community to the diversified future.
> 
> —
> Denis
> 
> > On Dec 10, 2016, at 12:24 PM, Dmitriy Setrakyan <dsetrak...@apache.org> 
> > wrote:
> > 
> > According to the discussion on the dev list [1], the following candidates
> > were proposed for the Apache Ignite PMC Chair position:
> > 
> > Vladimir Ozerov
> > Konstantin Boudnik
> > Valentin Kulichenko
> > Denis Magda
> > Branko Čibej
> > 
> > The vote is taking place on the dev list, however only votes from Apache
> > Ignite PMC members will be considered as binding.
> > 
> > *Note that this is not +1 or -1 vote. Please reply to this email specifying
> > the name of your preferred candidate for the Ignite PMC chair position
> > (feel free to explain why).*
> > 
> > The vote will go for 72 hours. Candidate who gets the most amount of votes
> > (not the majority) will be elected.
> > 
> > Note, that I specifically removed my name from the list, because the whole
> > point is to rotate a PMC chair, and not to reelect one.
> > 
> > [1] http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-PMC-Chair-
> > rotation-time-td11941.html
> 

Re: [VOTE] Apche Ignite PMC Chair Election

[Konstantin Boudnik]

On Sat, Dec 10, 2016 at 12:24PM, Dmitriy Setrakyan wrote:
> According to the discussion on the dev list [1], the following candidates
> were proposed for the Apache Ignite PMC Chair position:
> 
>  Vladimir Ozerov
>  Konstantin Boudnik
>  Valentin Kulichenko
>  Denis Magda
>  Branko Čibej
> 
> The vote is taking place on the dev list, however only votes from Apache
> Ignite PMC members will be considered as binding.

Yes, think "electoral" vs "popular" ;)

> *Note that this is not +1 or -1 vote. Please reply to this email specifying
> the name of your preferred candidate for the Ignite PMC chair position
> (feel free to explain why).*
> 
> The vote will go for 72 hours. Candidate who gets the most amount of votes
> (not the majority) will be elected.
> 
> Note, that I specifically removed my name from the list, because the whole
> point is to rotate a PMC chair, and not to reelect one.
> 
> [1] http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-PMC-Chair-
> rotation-time-td11941.html

Re: Blogging about new .NET features

[Konstantin Boudnik]

Gents, 

I would encourage you to use

https://blogs.apache.org/

as this place gets contant attention of the ASF media team and all the blogs
here got quite a bit of the spot light. In fact, I would encourage this group
to start using it. I'd be happy to help to set this up.

Cos

On Wed, Nov 23, 2016 at 10:34AM, Denis Magda wrote:
> Pavel,
> 
> Do you mind blogging about ASP.NET session state [1] and Entity Framework 2nd 
> level cache [2] support after 1.8 release goes public?
> 
> Also I would remind everyone in the community that it’s always welcomed to 
> share your experience or Ignite related news over blog posts. We track all 
> the posts on this page.
> https://ignite.apache.org/blogs.html 
> 
> 
> [1] https://apacheignite-net.readme.io/docs/aspnet-session-state-caching 
> 
> [2] 
> https://apacheignite-net.readme.io/docs/entity-framework-second-level-cache 
> 
> 
> —
> Denis

Re: ignite-spark module in Hadoop Accelerator

[Konstantin Boudnik]

In fact I am very much agree with you. Right now, running the "accelerator"
component in Bigtop disto gives one a pretty much complete fabric anyway. But
in order to make just an accelerator component we perform quite a bit of
woodoo magic during the packaging stage of the Bigtop build, shuffling jars
from here and there. And that's quite crazy, honestly ;)

Cos
 
On Mon, Nov 21, 2016 at 03:33PM, Valentin Kulichenko wrote:
> I tend to agree with Denis. I see only these differences between Hadoop
> Accelerator and Fabric builds (correct me if I miss something):
> 
>- Limited set of available modules and no optional modules in Hadoop
>Accelerator.
>- No ignite-hadoop module in Fabric.
>- Additional scripts, configs and instructions included in Hadoop
>Accelerator.
> 
> And the list of included modules frankly looks very weird. Here are only
> some of the issues I noticed:
> 
>- ignite-indexing and ignite-spark are mandatory. Even if we need them
>for Hadoop Acceleration (which I doubt), are they really required or can be
>optional?
>- We force to use ignite-log4j module without providing other logger
>options (e.g., SLF).
>- We don't include ignite-aws module. How to use Hadoop Accelerator with
>S3 discovery?
>- Etc.
> 
> It seems to me that if we try to fix all this issue, there will be
> virtually no difference between Fabric and Hadoop Accelerator builds except
> couple of scripts and config files. If so, there is no reason to have two
> builds.
> 
> -Val
> 
> On Mon, Nov 21, 2016 at 3:13 PM, Denis Magda <dma...@apache.org> wrote:
> 
> > > On the separate note, in the Bigtop, we start looking into changing the
> > way we
> > > deliver Ignite and we'll likely to start offering the whole 'data fabric'
> > > experience instead of the mere "hadoop-acceleration”.
> >
> > And you still will be using hadoop-accelerator libs of Ignite, right?
> >
> > I’m thinking of if there is a need to keep releasing Hadoop Accelerator as
> > a separate delivery.
> > What if we start releasing the accelerator as a part of the standard
> > fabric binary putting hadoop-accelerator libs under ‘optional’ folder?
> >
> > —
> > Denis
> >
> > > On Nov 21, 2016, at 12:19 PM, Konstantin Boudnik <c...@apache.org> wrote:
> > >
> > > What Denis said: spark has been added to the Hadoop accelerator as a way
> > to
> > > boost the performance of more than just MR compute of the Hadoop stack,
> > IIRC.
> > > For what it worth, Spark is considered a part of Hadoop at large.
> > >
> > > On the separate note, in the Bigtop, we start looking into changing the
> > way we
> > > deliver Ignite and we'll likely to start offering the whole 'data fabric'
> > > experience instead of the mere "hadoop-acceleration".
> > >
> > > Cos
> > >
> > > On Mon, Nov 21, 2016 at 09:54AM, Denis Magda wrote:
> > >> Val,
> > >>
> > >> Ignite Hadoop module includes not only the map-reduce accelerator but
> > Ignite
> > >> Hadoop File System component as well. The latter can be used in
> > deployments
> > >> like HDFS+IGFS+Ignite Spark + Spark.
> > >>
> > >> Considering this I’m for the second solution proposed by you: put both
> > 2.10
> > >> and 2.11 ignite-spark modules under ‘optional’ folder of Ignite Hadoop
> > >> Accelerator distribution.
> > >> https://issues.apache.org/jira/browse/IGNITE-4254 <
> > https://issues.apache.org/jira/browse/IGNITE-4254>
> > >>
> > >> BTW, this task may be affected or related to the following ones:
> > >> https://issues.apache.org/jira/browse/IGNITE-3596 <
> > https://issues.apache.org/jira/browse/IGNITE-3596>
> > >> https://issues.apache.org/jira/browse/IGNITE-3822
> > >>
> > >> —
> > >> Denis
> > >>
> > >>> On Nov 19, 2016, at 1:26 PM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> > >>>
> > >>> Hadoop Accelerator is a plugin to Ignite and this plugin is used by
> > Hadoop
> > >>> when running its jobs. ignite-spark module only provides IgniteRDD
> > which
> > >>> Hadoop obviously will never use.
> > >>>
> > >>> Is there another use case for Hadoop Accelerator which I'm missing?
> > >>>
> > >>> -Val
> > >>>
> > >>> On Sat, Nov 19, 2016 at 3:12 AM, Dmitriy Setrakyan 

Re: [VOTE] Use Upsource for Code Review

[Konstantin Boudnik]

On Mon, Nov 21, 2016 at 12:57PM, Dmitriy Setrakyan wrote:
> Cos, I see your point, but I think this one falls under procedural issue,
> no?

Not really. We are talking about a use of a tool to improve the review
process. Dictating a tool would be a step to a wrong direction. It's like
imposing the use of IDEA and banishing all Eclipse users (although, I wouldn't
mind really ;)

Dictation of a development technology is where the rift happens, IMO. But when
we are on the same page as the result of the consensus, rather than a fiat -
that's a different story.

Cos

k On Mon, Nov 21, 2016 at 12:21 PM, Konstantin Boudnik <c...@apache.org> wrote:
> 
> > What are we voting for this?
> >
> > Fortunately, Apache isn't about democracy. [1]
> >
> > [1] https://www.apache.org/foundation/voting.html
> >
> > Cos
> >
> > On Wed, Nov 16, 2016 at 01:08PM, Pavel Tupitsyn wrote:
> > > Following the discussion on Upsource [1],
> > > I would like to call a vote on accepting it as our official code review
> > > tool.
> > >
> > > [ ] +1  approve
> > > [ ] +0  no opinion
> > > [ ] -1  disapprove (and reason why)
> > >
> > > This vote will go on for 5 days.
> > >
> > > [1] http://apache-ignite-developers.2346864.n4.nabble.
> > > com/Code-Review-Tool-Proposal-Upsource-td12195.html
> >

Re: [DISCUSS] PMC Chair rotation time

[Konstantin Boudnik]

Ok, 

This was a great discussion, thanks for the deep insight, Roman!

looks like this thread has stewed for a while and it is time to [VOTE]. The
following candidates were put forward during the [DISCUSS] (in the order of
their appearance on the thread):

  Dmitriy Setrakyan
  Vladimir Ozerov
  Konstantin Boudnik
  Valentin Kulichenko
  Denis Magda
  Branko Čibej
  
Considering the number of the candidates I propose to use First-past-the-post
voting, with a single-round/single winner rules, where the candidate
collecting the most votes (not the majority) wins. [1]
 
Dmitriy, would you do the honors and start the formal [VOTE]?


[1] https://en.wikipedia.org/wiki/First-past-the-post_voting

Thanks,
  Cos

On Thu, Nov 10, 2016 at 08:19PM, Roman Shaposhnik wrote:
> On Wed, Nov 2, 2016 at 11:32 AM, Dmitriy Setrakyan
> <dsetrak...@apache.org> wrote:
> > While all the candidates suggested so far look good, I would propose Denis
> > Magda as the next PMC chair. His participation in the project does not only
> > have to do with the code, but also with Ignite project overall, including
> > website, documentation, new tickets, design, etc.
> 
> Sorry to come to this thread rather late, but I wanted to offer a somewhat
> different perspective that hopefully can help reframe this discussion
> a little bit.
> Note, that what I'm about to say is coming from a non-coding (on Ignite) 
> member
> of the PMC. In fact, I stayed on the PMC after graduation more with my ASF
> member hat on, rather than as somebody who wanted to directly contribute
> to where the technology was going. My concern during your incubation days
> was (and still is!) how well are you guys doing on the community development
> front.
> 
> If you recall, the diversity requirement (the fact that more than 80% of 
> project
> members work for the same company) came up during our graduation. While
> it wasn't a blocking requirement it still was a very valid concern. 
> Monocultures
> are really nasty for open source communities.
> 
> I think it would be fair to say that Ignite community hasn't really
> improved much
> diversity-wise since its graduation. And I honestly feel that this is,
> to a larger
> extent, because the focus is now missing. It was well understood that in order
> to graduate the community had to do all it can to demonstrate a
> positive trajectory
> in that direction. And we did. But we kind of dropped the ball on it since.
> 
> With that in mind, I offer my view on what a change in the Chair could
> offer: a renewed
> focus on community growth and development. If you agree with this premise than
> somebody like Branko or Cos who could act as a forcing function to constantly
> remind us about what else can we do to grow and develop this community would
> be an ideal choice for the Chair (after all Branko's "tough love" was
> probably the
> most useful part of Ignite's experience in the Incubator).
> 
> Now, of course, strictly speaking you don't have to be a Chair to do
> that. But lets
> face it -- that helps. And besides, a project's Chair doesn't really
> have any special
> powers when it comes to technological consensus, but anything that has to do
> with external community the VP title that the chair gets can help quite a bit.
> 
> Long story short: if Branko or Cos (as former mentors) would like to
> commit to 6 more
> months of the same hands-on mentorship focused on community development -- 
> they
> would have my wholehearted support.
> 
> Thanks,
> Roman (with my PMC member hat on).

Re: [VOTE] Use Upsource for Code Review

[Konstantin Boudnik]

What are we voting for this?

Fortunately, Apache isn't about democracy. [1]

[1] https://www.apache.org/foundation/voting.html

Cos

On Wed, Nov 16, 2016 at 01:08PM, Pavel Tupitsyn wrote:
> Following the discussion on Upsource [1],
> I would like to call a vote on accepting it as our official code review
> tool.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> This vote will go on for 5 days.
> 
> [1] http://apache-ignite-developers.2346864.n4.nabble.
> com/Code-Review-Tool-Proposal-Upsource-td12195.html

Re: ignite-spark module in Hadoop Accelerator

[Konstantin Boudnik]

What Denis said: spark has been added to the Hadoop accelerator as a way to
boost the performance of more than just MR compute of the Hadoop stack, IIRC.
For what it worth, Spark is considered a part of Hadoop at large. 

On the separate note, in the Bigtop, we start looking into changing the way we
deliver Ignite and we'll likely to start offering the whole 'data fabric'
experience instead of the mere "hadoop-acceleration".

Cos

On Mon, Nov 21, 2016 at 09:54AM, Denis Magda wrote:
> Val,
> 
> Ignite Hadoop module includes not only the map-reduce accelerator but Ignite
> Hadoop File System component as well. The latter can be used in deployments
> like HDFS+IGFS+Ignite Spark + Spark. 
> 
> Considering this I’m for the second solution proposed by you: put both 2.10
> and 2.11 ignite-spark modules under ‘optional’ folder of Ignite Hadoop
> Accelerator distribution.
> https://issues.apache.org/jira/browse/IGNITE-4254 
> 
> 
> BTW, this task may be affected or related to the following ones:
> https://issues.apache.org/jira/browse/IGNITE-3596 
> 
> https://issues.apache.org/jira/browse/IGNITE-3822
> 
> —
> Denis
> 
> > On Nov 19, 2016, at 1:26 PM, Valentin Kulichenko 
> >  wrote:
> > 
> > Hadoop Accelerator is a plugin to Ignite and this plugin is used by Hadoop
> > when running its jobs. ignite-spark module only provides IgniteRDD which
> > Hadoop obviously will never use.
> > 
> > Is there another use case for Hadoop Accelerator which I'm missing?
> > 
> > -Val
> > 
> > On Sat, Nov 19, 2016 at 3:12 AM, Dmitriy Setrakyan 
> > wrote:
> > 
> >> Why do you think that spark module is not needed in our hadoop build?
> >> 
> >> On Fri, Nov 18, 2016 at 5:44 PM, Valentin Kulichenko <
> >> valentin.kuliche...@gmail.com> wrote:
> >> 
> >>> Folks,
> >>> 
> >>> Is there anyone who understands the purpose of including ignite-spark
> >>> module in the Hadoop Accelerator build? I can't figure out a use case for
> >>> which it's needed.
> >>> 
> >>> In case we actually need it there, there is an issue then. We actually
> >> have
> >>> two ignite-spark modules, for 2.10 and 2.11. In Fabric build everything
> >> is
> >>> good, we put both in 'optional' folder and user can enable either one.
> >> But
> >>> in Hadoop Accelerator there is only 2.11 which means that the build
> >> doesn't
> >>> work with 2.10 out of the box.
> >>> 
> >>> We should either remove the module from the build, or fix the issue.
> >>> 
> >>> -Val
> >>> 
> >> 
> 

Re: new committer: Igor Rudyak

[Konstantin Boudnik]

Congrats, Igor - well deserved! Welcome!

On Mon, Nov 14, 2016 at 11:35AM, Igor Rudyak wrote:
> Thanks. Will try to do my best for the project.
> 
> Igor
> 
> 
> On Mon, Nov 14, 2016 at 11:03 AM, Denis Magda  wrote:
> 
> > The Project Management Committee (PMC) for Apache Ignite
> > has invited Igor Rudyak to become a committer and we are pleased
> > to announce that he has accepted.
> >
> > Igor is known inside of Apache Ignite community for such a valuable and
> > priceless contribution as Cassandra CacheStore implementation for Apache
> > Ignite which was developed my him from scratch and being maintained for a
> > while.
> >
> > Being a committer enables easier contribution to the
> > project since there is no need to go via the patch
> > submission process. This should enable better productivity.
> > Being a PMC member enables assistance with the management
> > and to guide the direction of the project.
> >
> > —
> > Denis

Re: Downloads on the web site

[Konstantin Boudnik]

Interesting read, Denis, although there's more shades in it than SDtimes can
be aware about.

Dima, I was referring to this blog-post
https://www.datastax.com/2016/10/take-a-bow-planet-cassandra

but has posted a link to this very thread instead. THanks for catching that!

Cos

On Fri, Nov 04, 2016 at 03:33PM, Denis Magda wrote:
> This might be a link that is related to the topic
> http://sdtimes.com/apache-foundation-board-reining-datastax/ 
> 
> 
> Good case so far.
> 
> —
> Denis
> 
> > On Nov 4, 2016, at 9:00 AM, Dmitriy Setrakyan  wrote:
> > 
> > Cos, this link is wrong.
> > 
> > On Fri, Nov 4, 2016 at 1:14 AM, Konstantin I Boudnik  
> > wrote:
> > 
> >> This blog post from DataStax [1] has reminded me of the conversation we
> >> had during the incubation on how to model community web-sites and how
> >> "Planet Cassandra" is doing this. Evidently, after years of the
> >> explanations and the deliberations, DataStax had finally came to their
> >> senses and stopped this violation of the Apache Cassandra trademark once
> >> and for all.
> >> 
> >> [1] https://is.gd/DBrGHB
> >> 
> >> Cos
> >> 
> >> On 2015-03-13 03:54 (+0300), Dmitriy Setrakyan 
> >> wrote:
> >>> Henry, Brane,
> >>> 
> >>> I completely see your points and agree. I actually finally had some time
> >>> today to look into this and will be removing the link shortly. However,
> >>> although I want to comply with ASF rules, I truly believe that having a
> >>> downloadable binary at all times increases usability and popularity of
> >> the
> >>> project.
> >>> 
> >>> With that in mind, I have asked GridGain to host the download link of
> >>> Apache Ignite community edition in the mean time, granted that it will be
> >>> made clear to the users and the community that it is not an official
> >> Apache
> >>> release. This approach is also taken by Datastax with their
> >> planetcassandra
> >>> portal, http://planetcassandra.org/try-cassandra/, perhaps for similar
> >>> reasons. Once we have a legitimate release candidate, we will revert back
> >>> to the normal download process.
> >>> 
> >>> I should be able to set this up within a couple of days.
> >>> 
> >>> D.
> >>> 
> >>> On Wed, Mar 11, 2015 at 8:42 PM, Henry Saputra 
> >>> wrote:
> >>> 
>  I agree. Please do remove the RC1 download links.
>  
>  The main reasons of any project need to be in incubator when joining
>  ASF is to make sure that the community know how to develop in the
>  Apache way.
>  
>  I am hoping that you do not guess or believe that things should work
>  as you think it is.
>  
>  ALL initial committers please read and understand how to release
>  documentation [1] and document about being ASF committer [2]
>  
>  What we are expecting from the new PPMCs are please try to understand
>  how ASF work and do not just do things based what you already knew.
>  When in doubt you can look at Apache websites or ask mentors in dev@
>  list or even go to incubator general@ list.
>  
>  [1] http://www.apache.org/dev/release-publishing.html
>  [2] http://www.apache.org/dev/new-committers-guide.html
>  
>  On Tue, Mar 10, 2015 at 9:36 PM, Branko Čibej 
> >> wrote:
> > On 10.03.2015 22:17, Dmitriy Setrakyan wrote:
> >> Brane,
> >> 
> >> The RC1 was a legitimate Ignite release candidate as it was
> >> submitted
>  for a
> >> vote. Please let us know if there are certain documented guidelines
> >> here
> >> that we are not aware of.
> > 
> > It's all documented here:
> > 
> > http://www.apache.org/dev/release.html
> > 
> > Specifically, this is written *in bold* on that page:
> > 
> >Do not include any links on the project website that might
> >> encourage
> >non-developers to download and use nightly builds, snapshots,
> >release candidates, or any other similar package.
> > 
> > It is fine to call a specific package a "release candidate" and even
> > publish is as an ASF release under that name, but in the case of
> > Ignite's RC1 and RC2, these are /not/ official releases because they
> > have not been approved as such by the PPMC and IPMC.
> > 
> >> Moreover, this RC1 zip archive provides users with the ability to
> >> kick
>  the
> >> tires with Apache Ignite ahead of time, before the official 1.0
> >> release
>  is
> >> out. I am not sure how removing it serves either community or user
> >> base
>  of
> >> the Ignite project.
> > 
> > Then tell people how to fetch a tag or specific commit from the git
> > repository, or simply how to clone a read-only (possibly shallow)
> >> copy.
> > It definitely doesn't serve the Ignite community or user base to post
> > confusing links to the 

Re: [DISCUSS] PMC Chair rotation time

[Konstantin Boudnik]

Just to reiterate the original premise for the rotation [1]:

- it provides an opportunity to anyone in the PMC to try this hat on and get
more involved in the inner-workings of the ASF and see how the board operates
- it guarantees that once you're a chair you aren't stuck holding the bag
forever and can pass it on if your time allocation changes
- such a policy makes the PMC very transparent


It ain't about supervision, as Chair doesn't have any magical powers over the
PMC. It is mostly about helping the board to provide a better view into the
project and be the representative of the board in the PMC. Most of the time it
is boring, but once in a while it might require quite a bit of an ability to
negotiate with people and be tasteful, if a situation gets sensitive for
whatever reason. Being a Chair doesn't mean he or she will lead the technical
side of the project: this responsibility comes as a consequence of one's merit,
rather than an official title of a sort.

[1] https://is.gd/bnVoaa

Cheers,
  Cos

On Tue, Nov 01, 2016 at 02:31PM, Denis Magda wrote:
> Fully support Cos’s proposal. 
> 
> It’s always a good intention to rotate positions like this even if
> everything runs smooth under a supervision of the present chair. Moreover,
> Dmitriy deserved some time to relax for the great job he did under this role 
> :)
> 
> From my side I would propose one more nominee - Valentin Kulichenko who
> brings significant efforts spreading out the knowledge in and out of the
> community, spends enormous amount of time assisting Ignite community and
> contributes to the overall future of the project.
> 
> As for my position, I’m not going to play mannerly games and would say that
> I’m ready to take over this role if the community decides so. Why? This is a
> matter of curiosity and abilities to make and learn more simply because
> you’ll be responsible for something new.
> 
> —
> Denis
> 
> > On Nov 1, 2016, at 8:00 AM, Sergi Vladykin <sergi.vlady...@gmail.com> wrote:
> > 
> > I'd say that the most proved candidate is Vladimir Putin :) But I want to
> > nominate some more trusted guys to make sure that our election is true and
> > representative:
> > 
> > 1. I want to nominate Vladimir Ozerov, who plays a big role in our
> > engineering efforts to make Apache Ignite successful.
> > 
> > 2. Also I'd like to nominate Konstantin Boudnik who is the most experienced
> > Apache and who keeps the true Open Source Spirit in the project.
> > 
> > MAKE APACHE IGNITE GREAT AGAIN
> > 
> > Sergi
> > 
> > 
> > 
> > 2016-11-01 17:20 GMT+03:00 Anton Vinogradov <a...@apache.org>:
> > 
> >> Hi,
> >> 
> >> Since everything works fine, I see no reason to change anything, so,
> >> Dmitriy Setrakyan is a proven candidate.
> >> But, anyways, I cannot but mention another good candidate, who works a lot
> >> to build this community, it is Denis Magda.
> >> 
> >> On Tue, Nov 1, 2016 at 4:34 PM, Konstantin Boudnik <c...@apache.org> wrote:
> >> 
> >>> As per the [VOTE] we held back in 2015, I'd like to start a discussion
> >>> about
> >>> the PMC Chair for the next year. The original [VOTE] can be found in [1]
> >>> 
> >>> Please make your nominations. Once we have the list of the candidates
> >> we'll
> >>> start the [VOTE] to determine the "lucky" winner.
> >>> 
> >>> [1] https://lists.apache.org/thread.html/55ee3b1c07f6e37ff06b0ab8caa4ac
> >>> 13443b20ca2275546a60055964@1444775452@%3Cdev.ignite.apache.org%3E
> >>> 
> >>> --
> >>> Take care,
> >>>  Cos
> >>> 
> >>> 
> >> 
> 

[DISCUSS] PMC Chair rotation time

[Konstantin Boudnik]

As per the [VOTE] we held back in 2015, I'd like to start a discussion about
the PMC Chair for the next year. The original [VOTE] can be found in [1]

Please make your nominations. Once we have the list of the candidates we'll
start the [VOTE] to determine the "lucky" winner.

[1] 
https://lists.apache.org/thread.html/55ee3b1c07f6e37ff06b0ab8caa4ac13443b20ca2275546a60055964@1444775452@%3Cdev.ignite.apache.org%3E

-- 
Take care,
  Cos

Re: Release notes preparations...

[Konstantin Boudnik]

Great! Thanks for updating the page! I've noticed that we are still using
unsecure md5 and sha1, but i guess this is a topic for a different time ;)

Cheers,
  Cos

On Wed, Aug 10, 2016 at 12:26PM, Pavel Tupitsyn wrote:
> Cos, you are right.
> 
> More than 300 (!) tickets has been moved to 1.8 yesterday when I released
> 1.7 version in JIRA.
> 
> For what it's worth, I've added a step to vote verification:
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
> 
> Pavel
> 
> On Tue, Aug 9, 2016 at 9:37 PM, Konstantin Boudnik <c...@apache.org> wrote:
> 
> > Gents,
> >
> > this has triggered the recollection of the release notes conversation we
> > had
> > the other day. Looks like the ticket queue isn't getting pruned in time of
> > the
> > release, so the changes like that are happening postfactum. This is either
> > leads to more load on the RM, or might be error-prone.
> >
> > I want to share some of the RM best practices that I have observed and used
> > myself in other projects (Bigtop, Hadoop, etc.). JIRA cleaning/pruning is
> > normally one of the steps _leading_ to release. It helps to narrow down the
> > scope of the work that still is needed to be done before the release could
> > be
> > cut. Once the scope is decided and all JIRAs considered for later are
> > moved to
> > the consequent release, JIRA software allow you to generate the release
> > notes
> > file, that can be included into the release itself. This provide a
> > necessary
> > connection between the source code in the release and the issues addressed
> > by
> > it. Once the release is published, the RM needs to officially _release_ the
> > version in the JIRA software. At this point, the number of unfinished
> > ticket
> > against that version should be exactly 0. It is just a matter of the
> > house-keeping and a good engineering practice. And it helps to keep down
> > the
> > amount of the mess.
> >
> > Hope it makes sense.
> >   Cos
> >
> > - Forwarded message from "Pavel Tupitsyn (JIRA)" <j...@apache.org>
> > -
> >
> > Date: Tue, 9 Aug 2016 12:32:32 + (UTC)
> > From: "Pavel Tupitsyn (JIRA)" <j...@apache.org>
> > To: c...@apache.org
> > Subject: [jira] [Updated] (IGNITE-2437) Zeppelin interperet doesn't import
> > external dependencies
> >
> >
> >  [ https://issues.apache.org/jira/browse/IGNITE-2437?page=
> > com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> >
> > Pavel Tupitsyn updated IGNITE-2437:
> > ---
> > Fix Version/s: (was: 1.7)
> >1.8
> >
> > > Zeppelin interperet doesn't import external dependencies
> > > --------
> > >
> > > Key: IGNITE-2437
> > > URL: https://issues.apache.org/jira/browse/IGNITE-2437
> > > Project: Ignite
> > >  Issue Type: Bug
> > >  Components: general
> > >Affects Versions: 1.5.0.final
> > > Environment: zeppelin 0.5.5
> > > ignite 1.5.0.final
> > >Reporter: Konstantin Boudnik
> > >Assignee: Andrey Gura
> > > Fix For: 1.8
> > >
> > >
> > > After configuring Ignite's interpreter for Zeppelin, tried to run the
> > following
> > > {code}
> > > %dep
> > > z.load("/usr/lib/ignite/libs/ignite-cache-objects.jar")
> > > %ignite
> > > import io.company._
> > > console>:23: error: object company is not a member of package io
> > >import io.company._
> > > {code}
> > > same code works just fine in spark interpreter though.
> >
> >
> >
> > --
> > This message was sent by Atlassian JIRA
> > (v6.3.4#6332)
> >
> > - End forwarded message -
> >

Re: Ignite 1.7 RELEASE_NOTES

[Konstantin Boudnik]

On Wed, Aug 03, 2016 at 10:47AM, Pavel Tupitsyn wrote:
> Cos, we track versions in JIRA. There are 230 closed issues for 1.7:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%201.7%20AND%20status%20%3D%20closed
> We can't just dump all of them to release notes.

Well, a lot of other projects do. And some others don't ;) I guess it depends
on what you want in the RN.

Cos

> On Tue, Aug 2, 2016 at 10:31 PM, Konstantin Boudnik <c...@apache.org> wrote:
> 
> > Tracking the "Fixed in release" on the JIRA tickets would take care about
> > any
> > gaps pretty much automatically. In general it's a good idea for an RM to
> > run a
> > spring-cleaning on the JIRA tickets to scope up the release. Then once all
> > tickets are fixed, you can simply _generate_ the release notes with a
> > single-button click.
> >
> > Cos
> >
> > On Mon, Aug 01, 2016 at 01:43PM, Pavel Tupitsyn wrote:
> > > Igniters,
> > >
> > > RELEASE_NOTES.txt in ignite-1.7 branch does not look complete to me.
> > There
> > > are likely more noteworthy changes since 1.6.
> > >
> > > Let's discuss the changes to be included in release notes and fix them.
> > >
> > > Please reply to this email with your proposals.
> > >
> > > Pavel.
> >

Re: Ignite 1.7 RELEASE_NOTES

[Konstantin Boudnik]

Tracking the "Fixed in release" on the JIRA tickets would take care about any
gaps pretty much automatically. In general it's a good idea for an RM to run a
spring-cleaning on the JIRA tickets to scope up the release. Then once all
tickets are fixed, you can simply _generate_ the release notes with a
single-button click.

Cos

On Mon, Aug 01, 2016 at 01:43PM, Pavel Tupitsyn wrote:
> Igniters,
> 
> RELEASE_NOTES.txt in ignite-1.7 branch does not look complete to me. There
> are likely more noteworthy changes since 1.6.
> 
> Let's discuss the changes to be included in release notes and fix them.
> 
> Please reply to this email with your proposals.
> 
> Pavel.

Re: kick off a discussion

[Konstantin Boudnik]

On Wed, Jul 13, 2016 at 05:30AM, Dmitriy Setrakyan wrote:
> Hi Alex,
> 
> I believe most of your comments have to do with disk-based functionality,
> especially in regard to backups, snapshots, etc. However, Ignite is
> currently an in-memory system, at least for the nearest future. Let me know
> if I misunderstood something.

And the nearest future is defined by? This is a collaborative project, as
you all learned during the incubation, and the statements like "the X only
does bar for now" should be consensual. If there's a will to work on the new
functionality which is demanded by the users, and the said functionality is
expected to expand the applicability of the technology - I don't really see
why and how it could be put to hold.

Fortunately, there are a number of ways this development could be put through,
and it doesn't really require much of the moving parts (in fact it is done all
the time in the same way right now): let's put the new development on a
branch, and start moving. There's JIRA and there's the CI to help to validate
and coordinate the work. Sounds like an easy decision to me.

Cos

> On Tue, Jul 12, 2016 at 9:44 PM, Alexandre Boudnik <
> alexander.boud...@gmail.com> wrote:
> 
> > Dmitriy, thank you for your time and questions, which helped me to
> > realize what I forget to mentioned!
> > See my answers inline; later I'll combine everything together to help
> > to the next readers :)
> >
> > I put together some implementation ideas in Apache Ignite JIRA, as
> > promised: https://issues.apache.org/jira/browse/IGNITE-3457. I see
> > this facility as another CacheStore implementation, so it wouldn't
> > interfere with base principals of Ignite platform.
> >
> >
> > On Mon, Jul 11, 2016 at 1:15 AM, Dmitriy Setrakyan
> >  wrote:
> > > My answers are inline…
> > >
> > > On Sat, Jul 9, 2016 at 3:04 AM, Dmitriy Setrakyan  > >
> > > wrote:
> > >
> > >> Thanks Sasha!
> > >>
> > >> Resending to the dev list.
> > >>
> > >> D.
> > >>
> > >> On Fri, Jul 8, 2016 at 2:02 PM, Alexandre Boudnik <
> > alexan...@boudnik.org>
> > >> wrote:
> > >>
> > >>> Apache Ignite a great platform but it lacks of certain capabilities,
> > >>> which are common in RDMS world, such as:
> > >>> - Consistent on-line backup for data on entire cluster (or for
> > >>> specified set of caches)
> > >>>
> > >>
> > > I think you mean data center replication here. It is not an easy feature
> > to
> > > implement, and so far has been handled by commercial vendors of Ignite,
> > > e.g. GridGain.
> > >
> > Actually not. Right here I meant exactly what I said: full or
> > incremental backup of all/selected caches in consistent state so it
> > can be used for the purpose of being able to restore them in case of
> > data loss or data corruption. One of important use cases is the OLAP
> > systems (let's say for banking), which has been built on Apache Ignite
> > platform.
> >
> > And you right, data center replication can be easily implemented based
> > on log/snapshot shipment.
> >
> > >
> > >> - Hierarchal snapshots for specified set caches
> > >>>
> > >>
> > > What do you mean by hierarchical?
> > >
> > In this particular case the notion of hierarchical snapshots is very
> > similar to the same notion used in SAN appliances or by Virtual Box or
> > vmware. Using concept of snapshots we can do all this amazing things:
> > - full and incremental backup
> > - restore
> > - rollback to checkpoint
> > - roll forward
> > much easier, with minimal memory and I/O overhead.
> >
> > >
> > >> - Transaction log
> > >>>
> > >>
> > > Why does Ignite need it for in-memory transactions?
> > >
> > At least it is required to provide roll-forward functionality, when
> > you restores the state of the cache from checkpoint (the cache state
> > before snapshot has been made) and then reapply transactions one by
> > one.
> >
> > >
> > >> - Restore cluster state as of certain point in time
> > >>>
> > >>
> > > Given that such restorability may introduce lots of memory overhead, does
> > > it really make sense  for an in-memory cache?
> > >
> > Actually, it will not consume any memory. It will use external memory,
> > such as HDD/SSD space instead. And yes, I think that this
> > functionality makes complete sense for our users IRL, who will love
> > it.
> >
> > >
> > >> - Rolling forward from snapshot with ability to filter/modify
> > transactions
> > >>>
> > >>
> > > Same as above
> > >
> > The same as above: my customers in trenches are begging for that feature.
> >
> > >
> > >> - Asynchronous replication based either on log shipment or snapshot
> > >>> shipment
> > >>> -- Between clusters
> > >>>
> > >>
> > > This is the same as data center replication, no?
> > Including but not limited to: log shipment or snapshot shipment also
> > could be used to implement so called "better-than-lambda-architecture"
> > for BI and OLAP, when data replicated to a query-able datasource let's
> > say Oracle as soon as they 

Re: Apache Ignite - New Release

[Konstantin Boudnik]

Yup, looks like having a minor bump is totally warranted.

On Mon, Jul 11, 2016 at 10:11PM, Sergi Vladykin wrote:
> Yakov,
> 
> Good idea.
> 
> Alexey,
> 
> Why not just bump it to 1.7 as we do usually?
> 
> Sergi
> 
> 
> 
> On Mon, Jul 11, 2016 at 9:21 PM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
> 
> > There were also numerous contributions merged with small API improvements.
> > +1 for making a new release.
> >
> > Since the changes are mostly bugfixes, should we make it a point release?​
> >

Re: kick off a discussion

[Konstantin Boudnik]

On Mon, Jul 11, 2016 at 08:15AM, Dmitriy Setrakyan wrote:
> My answers are inline…
> 
> On Sat, Jul 9, 2016 at 3:04 AM, Dmitriy Setrakyan 
> wrote:
> 
> > Thanks Sasha!
> >
> > Resending to the dev list.
> >
> > D.
> >
> > On Fri, Jul 8, 2016 at 2:02 PM, Alexandre Boudnik 
> > wrote:
> >
> >> Apache Ignite a great platform but it lacks of certain capabilities,
> >> which are common in RDMS world, such as:
> >> - Consistent on-line backup for data on entire cluster (or for
> >> specified set of caches)
> >>
> >
> I think you mean data center replication here. It is not an easy feature to
> implement, and so far has been handled by commercial vendors of Ignite,
> e.g. GridGain.

Apache Geode (incubating) has added the DC replication a couple months ago, so
I don't see why Ignite shouldn't?

Cos

> > - Hierarchal snapshots for specified set caches
> >>
> >
> What do you mean by hierarchical?
> 
> 
> > - Transaction log
> >>
> >
> Why does Ignite need it for in-memory transactions?
> 
> 
> > - Restore cluster state as of certain point in time
> >>
> >
> Given that such restorability may introduce lots of memory overhead, does
> it really make sense  for an in-memory cache?
> 
> 
> > - Rolling forward from snapshot with ability to filter/modify transactions
> >>
> >
> Same as above
> 
> 
> > - Asynchronous replication based either on log shipment or snapshot
> >> shipment
> >> -- Between clusters
> >>
> >
> This is the same as data center replication, no?
> 
> 
> > -- Continues data export to let’s say RDMS
> >>
> >
> Don’t we already support it with our write-through feature to a database?
> 
> 
> > It is also a necessity to reduce cold start time for huge clusters
> >> with strict SLAs.
> >>
> >
> What part are you trying to speed up here? Are you talking about loading
> data from databases?
> 
> 
> >
> >> I'll put some implementation ideas in JIRA later on. I believe that
> >> this list is far from being complete, but I want the community to
> >> discuss these abovementioned use cases.
> >>
> >> --Sasha
> >>
> >
> >

Re: Migration from json-lib 2.4 to Jackson

[Konstantin Boudnik]

On Thu, Jun 09, 2016 at 04:37PM, Alexey Kuznetsov wrote:
> And one more question: ignite-zookeeper module has 2 dependencies to
> Jackson 1.9.13.
> It is possible to replace them to Jackson 2.x dependencies?

That's the huge problem the whole Hadoop ecosystem faces: every project is 
using whatever they feel like, which causes multiple versions conflicts in the
downstream. You might be able to bump the version and get rid of the
transitive dependency in the benign case of a json lib. In extreme cases it
might not work though

Cos

> On Thu, Jun 9, 2016 at 4:06 PM, Alexey Kuznetsov 
> wrote:
> 
> > Hi, All!
> >
> > I started to work on IGNITE-3277 [1]: migration from very outdated lib
> > json-lib (last release was on 2010-12-14).
> >
> > And I found reference to this lib in ignite-osgi-karaf module in file
> > "features.xml".
> >
> > lines 206-207
> >  > dependency="true">mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.ezmorph/${ezmorph.bundle.version}
> >  > dependency="true">mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.json-lib/${jsonlib.bundle.version}
> >
> > Raul, as a maintainer of this module, could you tell me how I should fix
> > "features.xml"?
> >
> > I'm going to use in ignite-rest-http two new dependencies:
> >
> > 
> > com.fasterxml.jackson.core
> > jackson-core
> > 2.7.4
> > 
> >
> > 
> > com.fasterxml.jackson.core
> > jackson-databind
> > 2.7.4
> > 
> >
> > And will drop two old deps:
> >
> > 
> > net.sf.json-lib
> > json-lib
> > ${jsonlib.version}
> > jdk15
> > 
> >
> > 
> > net.sf.ezmorph
> > ezmorph
> > ${ezmorph.version}
> > 
> >
> > Please, advice.
> >
> >
> > 1. https://issues.apache.org/jira/browse/IGNITE-3277
> >
> > --
> > Alexey Kuznetsov
> > GridGain Systems
> > www.gridgain.com
> >
> 
> 
> 
> -- 
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com


signature.asc
Description: Digital signature

Dynamic (-like) byte-code modifications [Was: Documentation for AOP-based Grid Enabling]

[Konstantin Boudnik]

Thanks for putting the docs together Prachi! 

I am also quite a bit surprised that Ignite has the support for AOP. As a side
topic, and the one for an overall amusement: 

 - do people think it might be a good time to revisit the use of "last
   century" programming techniques, which are build time only, poorly
   supported by the modern IDEs and very sensitive to the underlying
   signature and control-flow changes?

To make it clear, when I say 'build-time only' I meant that a (re)-compilation
of the existing code is needed in order to inject the invocation hooks and
change the control-flow of one's application.

As a solid alternative, there's MOP after all, which is cleaner, more
light-weight, and truly dynamic. Besides, do we see much of the use for AOP
nowadays?

The reason the topic has caught my attention, is my personal dissatisfaction
with AOP frameworks in the past. And I don't see any evidences there are
getting any better in the last 6-7 years.

Cos

On Tue, May 31, 2016 at 04:22PM, Denis Magda wrote:
> Prachi,
> 
> Looks good to me. 
> 
> If there is anyone in the community who made it hands dirty with AOP and
> Ignite please review the documentation from Prachi as well.
> 
> —
> Denis
> 
> > On May 27, 2016, at 2:17 PM, Denis Magda  wrote:
> > 
> > Hi Prachi,
> > 
> > Great, to be honest I didn’t suspect Ignite supports this functionality.
> > 
> > Will try my hands dirty with the examples provided in the doc in the 
> > nearest days and will provide you with a feedback.
> > 
> > —
> > Denis
> > 
> >> On May 26, 2016, at 9:56 PM, Prachi Garg  wrote:
> >> 
> >> Engineers,
> >> 
> >> I have added documentation for AOP-based Grid Enabling -
> >> http://apacheignite.gridgain.org/docs/aop-based-grid-enabling.
> >> 
> >> Can someone please review?
> >> 
> >> -P
> > 
> 


signature.asc
Description: Digital signature

Re: Ignite Release Schedules - a suggestion

[Konstantin Boudnik]

On Tue, May 17, 2016 at 01:09AM, endianignite wrote:
> With regard to branch structure, I took some time to think and have a
> suggestion.  Feel free to pick holes in it.
> 
> Major feature releases would continue to have major version numbers: e.g.,
> 1.7, 1.8, 2.x and so on.  Bug-fix releases would be minor releases: e.g.,
> 1.7.1, 1.7.2, 1.7.x, etc.  Major releases get their own branch, although it
> will probably be sensible to keep major features on their own JIRA branch
> before being merged on to the release branch.  Once a major release "goes
> gold", bug fixes would be continued on that release branch, and the next
> major release would go to a new branch.  Bug fixes on the current "gold"
> branch would be merged regularly in to the new major release branch, until
> that new major release branch is ready to "go gold", at which point the
> cycle would repeat, and new bug fixes would go on to the newly released
> major release branch.

How would you propagate bug fixed among releases in this case?

> In the above scheme, master becomes deprecated, but there is still only one
> major release branch that is "gold" at any one time.  We would not be in a
> situation where 1.7.x was still being developed on once 1.8.x has been
> released.
> 
> 
>  
> 
> 
> 
> --
> View this message in context: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Release-Schedules-a-suggestion-tp8867p8939.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.


signature.asc
Description: Digital signature

Re: Halfway to Ignite 1.6

[Konstantin Boudnik]

You can still talk about the release even if it is in the final stages. What
would be unfortunate is to miss some of the good features (like IGNITE-1371)
just because of an arbitrary date of an even of some kind, which has no
relevance to the project itself.

For what it worth, rushing releases (ie a product company way of satisfying a
time-boxed effort, aka PM-lust for scheduling) tends to end up in a
substantially lower quality of the releases.

Cos

On Mon, May 16, 2016 at 05:09PM, Dmitriy Setrakyan wrote:
> I will be presenting at IMC Summit next week in Bay Area, and it sure would
> be nice to talk about 1.6 release and the new features. Would be great if
> we could send it for vote on Wednesday morning. This would give a chance
> for the vote to pass by EOD on Friday, if everything is OK.
> 
> D.
> 
> On Mon, May 16, 2016 at 7:50 AM, Sergey Kozlov  wrote:
> 
> > Guys
> >
> > I'm concerned that we postpone once again the date of code freeze. It
> > shifts dates of testing and release and it seems we won't be able to send
> > to voting this week
> >
> > On Mon, May 16, 2016 at 5:43 PM, Anton Vinogradov <
> > avinogra...@gridgain.com>
> > wrote:
> >
> > > Thanks everyone for checking!
> > >
> > > Only 8 tickets left!
> > >
> > > Seems contributors still need 1-2 days to pass codereview and merge final
> > > changes.
> > > We postponed code freeze till Wednesday UTC 19-00. Hope, this will be the
> > > last time.
> > >
> > > On Mon, May 16, 2016 at 3:56 PM, Anton Vinogradov <
> > > avinogra...@gridgain.com>
> > > wrote:
> > >
> > > > Igniters,
> > > >
> > > > We still have 32 issues with status "In Progress" or "Patch Available"
> > > and
> > > > fixVersion = 1.6.
> > > > Full list
> > > > <
> > >
> > https://issues.apache.org/jira/issues/?filter=-1=(status%20%3D%20%22In%20Progress%22%20or%20status%20%3D%20%22Patch%20Available%22)%20AND%20fixVersion%20%3D%201.6%20and%20project%20%3D%20Ignite
> > >
> > > can
> > > > be found here.
> > > >
> > > > Please change fixVersion for issues can't be resolved at 1.6 to 1.7,
> > and
> > > > close other issues before code freeze.
> > > >
> > > > On Mon, May 16, 2016 at 12:57 AM, Andrey Gura 
> > > wrote:
> > > >
> > > >> Guys,
> > > >>
> > > >> I've finished with improvements for JDBC drivers [1]. I hope somebody
> > > will
> > > >> review and merge it before code freeze.
> > > >> Also I created issue related with query execution from client nodes
> > [2].
> > > >> It
> > > >> affects system behaviour that related with [1] and [3]. I don't think
> > > that
> > > >> it is critical because walk around exists.
> > > >>
> > > >> [1] https://issues.apache.org/jira/browse/IGNITE-2382
> > > >> [2] https://issues.apache.org/jira/browse/IGNITE-3136
> > > >> [3] https://issues.apache.org/jira/browse/IGNITE-2455
> > > >>
> > > >> On Fri, May 13, 2016 at 6:24 PM, Anton Vinogradov 
> > > wrote:
> > > >>
> > > >> > Igniters,
> > > >> >
> > > >> > We postponed code freeze till monday UTC 19-00.
> > > >> >
> > > >> > On Thu, May 12, 2016 at 1:48 PM, Anton Vinogradov 
> > > >> wrote:
> > > >> >
> > > >> > > Typo fix:
> > > >> > > Pushes to ignite-1.6 are allowed till Friday (*May *13) 19:00 UTC.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > On Thu, May 12, 2016 at 1:41 PM, Anton Vinogradov 
> > > >> wrote:
> > > >> > >
> > > >> > >> Igniters,
> > > >> > >>
> > > >> > >> Ignite 1.6 almost ready to be finally tested.
> > > >> > >>
> > > >> > >> Branch ignite-1.6 now contains all changes scheduled for 1.6.
> > > >> > >>
> > > >> > >> In case you want to add something else to this release, please
> > note
> > > >> that
> > > >> > >> pushes to ignite-1.6 allowed till Friday (Aug 13) 19:00 UTC.
> > > >> > >> After that date only fixes will allowed.
> > > >> > >>
> > > >> > >> On Fri, May 6, 2016 at 4:18 PM, Anton Vinogradov 
> > > >> wrote:
> > > >> > >>
> > > >> > >>> Igniters,
> > > >> > >>>
> > > >> > >>> We're going to release Ignite 1.6 in the nearest future.
> > > >> > >>> Branch ignite-1.6 was created and already contains changes
> > > scheduled
> > > >> > for
> > > >> > >>> 1.6.
> > > >> > >>>
> > > >> > >>> And from now on, I propose to start testing and fixing
> > ignite-1.6
> > > >> > source
> > > >> > >>> code to provide stable release.
> > > >> > >>>
> > > >> > >>> As you know we have a huge amount of tests and some of them now
> > > >> failing
> > > >> > >>> at release branch.
> > > >> > >>> Fails can be found here:
> > > >> > >>>
> > > >> > >>>
> > > >> >
> > > >>
> > >
> > http://149.202.210.143:8111/project.html?projectId=IgniteTests=projectOverview_IgniteTests=ignite-1.6
> > > >> > >>>
> > > >> > >>> So, feel free to start investigations and fix issues :)
> > > >> > >>>
> > > >> > >>
> > > >> > >>
> > > >> > >
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Andrey Gura
> > > >> GridGain Systems, Inc.
> > > >> www.gridgain.com
> > > >>
> > > >
> > 

Re: 1.5.0.final is breaking packaging: osgi dependency is non-existent

[Konstantin Boudnik]

On Mon, May 16, 2016 at 04:09AM, Andrey Kornev wrote:
> I'd love to elaborate, Konstantin, but I can't. I have no experience with
> the package management tools, neither yum nor rpm.

Understood, and that's ok. I am rather trying to understand where these could
possible be coming from.

> BTW, those Spring dependencies are optional, as far as I know. They are only
> required if Spring framework is used by the application (Spring XML
> configuration, for example).

Well, in case of HDFS and Spark accelerators Spring is used and packed all
along. Are you saying I would need to pick up some OSGI libs as well? If so,
where they could be found after the build is done? I wasn't able to spot them,
unfortunately.

Thanks!
  Cos

> > Date: Sun, 15 May 2016 10:20:57 -0400
> > From: c...@apache.org
> > To: dev@ignite.apache.org
> > Subject: Re: 1.5.0.final is breaking packaging: osgi dependency is 
> > non-existent
> > 
> > Thanks for checking out Andrey. Do you mind to elaborate on 'something'? The
> > way I see it, is that rpmbuilder performs certain checks to declare the
> > package dependencies, and the osgi once are popping up from somewhere. Which
> > wasn't the case before OSGI was added. Which lead me to believe that the 
> > issue
> > might be rooting from missing jars or something similar. Hence, my this 
> > email
> > thread.
> > 
> > Were my assumptions incorrect.
> > Thanks
> >   Cos
> > 
> > On Thu, May 05, 2016 at 04:39AM, Andrey Kornev wrote:
> > > Anton,
> > > 
> > > My first impression after having taken a look at bigtop's JIRA ticket is
> > > that the issue is not so much with OSGi per se, but rather it has 
> > > something
> > > to do with Ignite's HDFS accelerator yum packaging.
> > > 
> > > Regards
> > > Andrey
> > > 
> > > > Date: Thu, 5 May 2016 13:55:26 +0300
> > > > Subject: Re: 1.5.0.final is breaking packaging: osgi dependency is 
> > > > non-existent
> > > > From: avinogra...@gridgain.com
> > > > To: dev@ignite.apache.org
> > > > 
> > > > Igniters,
> > > > 
> > > > Issue is critical for Bigtop project.
> > > > In case someone familiar with OSGI please have a look.
> > > > 
> > > > On Wed, May 4, 2016 at 11:15 AM, Anton Vinogradov 
> > > > <avinogra...@gridgain.com>
> > > > wrote:
> > > > 
> > > > > Roman, Raul,
> > > > >
> > > > > As far as I remember you're familiar with OSGI. Could you please have 
> > > > > a
> > > > > look at this?
> > > > >
> > > > > On Wed, May 4, 2016 at 6:09 AM, Konstantin Boudnik <c...@boudnik.org>
> > > > > wrote:
> > > > >
> > > > >> Hey guys
> > > > >>
> > > > >> For your information: adding osgi into the product is breaking the
> > > > >> dependency matrix of the bigtop packages. For more info see
> > > > >> https://issues.apache.org/jira/browse/BIGTOP-2421
> > > > >>
> > > > >> --
> > > > >> Take care,
> > > > >> Cos
> > > > >> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
> > > > >> Cos' pubkey: http://people.apache.org/~cos/cos.asc
> > > > >>
> > > > >>   Wisdom of the hour 
> > > > >>
> > > > >>
> > > > >
> > > 
> 


signature.asc
Description: Digital signature

Re: Ignite Release Schedules - a suggestion

[Konstantin Boudnik]

I don't think the extrapolation works in this particular case, although it
looks scary ;) However, I agree, shorter bug fix & smaller feature releases
might make a lot of sense, considering how actively the userbase and community
grow. However, major features take longer time to mature and be integrated
into the master, hence they should be carried on the branches (an good example
such is IGNITE-1371). And this might lead, in the extreme case, to the
multi-release universe.

Hence coming Dmitriy's quesion about branching model. So I would like to, once
again, offer 
http://nvie.com/posts/a-successful-git-branching-model/

which effectively and transparently allow to support multiple release trains.

But in general, releases shouldn't be a big deal and any committer can call a
release at any given moment. All it needs to pass is >3 PMC votes to become an
official one. Easier the release process is and more release managers (RMs) we
have - shorter the release spam might become.

Cos

On Fri, May 13, 2016 at 02:21AM, endianignite wrote:
> Dear Igniters,
> 
> First of all, congratulations on heading towards the 1.6 release.  Each
> Ignite release is a huge amount of work, done to a very high standard by a
> great group of people.  I raise my hat to each and every one of you!
> 
> I would like to open a discussion regarding release schedules, and how we
> currently perform releases.  Right now, we have very large waterfall
> releases, that are a combination of substantial numbers of bug fixes, along
> with significant new features - binary marshaling from 1.5 is one that I
> witnessed first hand.  The integration of all of these changes can be
> challenging, and from my observation tends to extend the time taken to go
> from the final code freeze to the point of release.  Some data from the
> release dates:
> 
> Release,Date,DaysSinceLastRelease
> 1.0,02-Apr-15,
> 1.1,28-May-15,56
> 1.2,29-Jun-15,32
> 1.3,21-Jul-15,22
> 1.4,28-Sep-15,69
> 1.5,04-Jan-16,98
> 1.6*,31-May-16,148
> 1.7+,03-Dec-16,186
> 1.8+,17-Jul-17,226.7
> 1.9+,11-Apr-18,267.4
> 2.0+,13-Feb-19,308.1
> 
> *estimated date
> +extrapolated date.  Equation: date=407*releaseVersion-505.9 taken from
> Excel best-fit line, R^2=0.9906.  
> 
> As you can see, the time between releases is trending upwards since 1.3, and
> on a very steep gradient.  Doing some (admittedly silly) extrapolation, at
> the current it could take 308 days to go from a future version 1.9 to a 2.0
> release, just assuming the current growth rate.  This could mean that a bug
> found in April 2018 would not be released until February 2019!  Currently
> I'm facing a bug (https://issues.apache.org/jira/browse/IGNITE-2080) that
> was found in Dec-15, fixed in Feb-16, but will not be released until
> May/June 2015.  
> 
> In my opinion this is not sustainable if we want Ignite to grow in userbase
> and functionality, whilst retaining a reputation for stability and being
> bug-free, as I'm sure we all do.  Therefore, as a sign of Ignite's growing
> maturity, I would like to suggest that we adopt a release schedule where bug
> fixes are released on a timed-release basis, and new features are included
> in less frequent major releases.  There are many examples of this kind of
> release schedule: Intel's tick-tock cycle, Ubuntu's timed-release cycle,
> Redhat's major/minor/asynch cycle.  
> 
> I propose that the release schedule for Ignite would be separated in to two
> streams: bug fixes and major features.  The first stream, bug fixes, would
> close for code freeze every month, undergo testing and QA and then be
> released, hopefully within two weeks of the code freeze.  Bugs not fixed in
> time for the code freeze would be pushed to the next monthly cycle.  The
> Major Features stream would be over a significantly longer period, although
> I would still suggest that it be less than the current 3-5 month interval.  
> 
> Finally, if you got this far then well done, you have got staying power.  I
> hope that you will take the above thoughts and analysis in the way that they
> are offered, as a positive, and not as criticism (which they are not).
> 
> I'm really interested to hear your thoughts on this subject.  I'm happy to
> try and lead a release cycle change if the community would like me to, or to
> assist someone within GridGain if that makes more sense.
> 
> Kind regards
> Mike
> 
> 
> 
> 
> --
> View this message in context: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Release-Schedules-a-suggestion-tp8867.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.


signature.asc
Description: Digital signature

Re: HDFS CacheStore

[Konstantin Boudnik]

Cristian,

Great idea!
a couple of comments:
 - HDFS supports truncate since at least v. 2.7.0 (see HDFS-3107)
 - integration with HBase would increase the operational complexity, which is
   already high in HBase, to new levels. Besides, using HBase as the
   compaction mechanism shouldn't be called HDFS CacheStore
 - do you think this can be combined with IGFS on top of HDFS?

Thoughts?
  Cos

On Fri, May 13, 2016 at 10:35AM, Cristian Malinescu wrote:
> Hello folks - reloading on the topic to add a HDFS CacheStore module, is
> anybody interested in brainstorming upon the idea? I want to be consistent
> and make sure I capture most of the ideas, opinions and options before
> proceeding brute force :). As long as HDFS paradigm is append-only, maybe a
> plain integration with HBase would be a better option as going this path
> Ignite will offload the need to manage HDFS compaction to HBase.
> Cheers
> Cris


signature.asc
Description: Digital signature

Re: 1.5.0.final is breaking packaging: osgi dependency is non-existent

[Konstantin Boudnik]

Thanks for checking out Andrey. Do you mind to elaborate on 'something'? The
way I see it, is that rpmbuilder performs certain checks to declare the
package dependencies, and the osgi once are popping up from somewhere. Which
wasn't the case before OSGI was added. Which lead me to believe that the issue
might be rooting from missing jars or something similar. Hence, my this email
thread.

Were my assumptions incorrect.
Thanks
  Cos

On Thu, May 05, 2016 at 04:39AM, Andrey Kornev wrote:
> Anton,
> 
> My first impression after having taken a look at bigtop's JIRA ticket is
> that the issue is not so much with OSGi per se, but rather it has something
> to do with Ignite's HDFS accelerator yum packaging.
> 
> Regards
> Andrey
> 
> > Date: Thu, 5 May 2016 13:55:26 +0300
> > Subject: Re: 1.5.0.final is breaking packaging: osgi dependency is 
> > non-existent
> > From: avinogra...@gridgain.com
> > To: dev@ignite.apache.org
> > 
> > Igniters,
> > 
> > Issue is critical for Bigtop project.
> > In case someone familiar with OSGI please have a look.
> > 
> > On Wed, May 4, 2016 at 11:15 AM, Anton Vinogradov <avinogra...@gridgain.com>
> > wrote:
> > 
> > > Roman, Raul,
> > >
> > > As far as I remember you're familiar with OSGI. Could you please have a
> > > look at this?
> > >
> > > On Wed, May 4, 2016 at 6:09 AM, Konstantin Boudnik <c...@boudnik.org>
> > > wrote:
> > >
> > >> Hey guys
> > >>
> > >> For your information: adding osgi into the product is breaking the
> > >> dependency matrix of the bigtop packages. For more info see
> > >> https://issues.apache.org/jira/browse/BIGTOP-2421
> > >>
> > >> --
> > >> Take care,
> > >> Cos
> > >> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
> > >> Cos' pubkey: http://people.apache.org/~cos/cos.asc
> > >>
> > >>   Wisdom of the hour 
> > >>
> > >>
> > >
> 


signature.asc
Description: Digital signature

1.5.0.final is breaking packaging: osgi dependency is non-existent

[Konstantin Boudnik]

Hey guys

For your information: adding osgi into the product is breaking the
dependency matrix of the bigtop packages. For more info see
https://issues.apache.org/jira/browse/BIGTOP-2421

-- 
Take care,
Cos
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
Cos' pubkey: http://people.apache.org/~cos/cos.asc

  Wisdom of the hour 



signature.asc
Description: Digital signature

Re: a question about CLA and contributions to the project

[Konstantin Boudnik]

Alexander,

Having ICLA for contributors is 'nice to have' but isn't mandatory.
Once when/if a person is invited to become a committer, the ICLA is the must.
It is called ICLA for a reason: I == Individual

If your employer is going to do a donation of existing code, it will have to
go through the process of signing SGA or CCLA. For more information please
check [1]

From a personal experience and what I was seeing for many years now: if you're
really interested in contributing and work with the project beyond your
existing engagement with the employer, I'd go with simple ICLA: it is less
formal, easier to do. And last but not least, the job is just a job, but OSS
involvement is often-times something that lasts for a long time, during which
one can change a job a number of times.

Cheers,
Cos

[1] https://www.apache.org/licenses/#clas

On Thu, Apr 14, 2016 at 02:54PM, AlexanderSavelyev wrote:
> Hello!
> 
> I am considering a possibility of active participation in Apache Ignite
> community. One formal question, which I have not found an answer to in FAQs
> and anywhere else: Is it a mandatory prerequisite to sign an Apache
> contributor license agreement to engage in community and submit
> code/contributions?
> 
> Does situation change, if from a formal standpoint if the contributions will
> be made by my employer - a company?
> 
> Thank you very much for your time and answers in advance!
> 
> Regards,
> 
> Alex


signature.asc
Description: Digital signature

Re: Switching back to review-then-commit process

[Konstantin Boudnik]

It saddens me to see this coming to it ;(

On Thu, Mar 03, 2016 at 02:54PM, Denis Magda wrote:
> Igniters,
> 
> I would propose to switch back to review-then-commit process. This
> process has to be followed by both contributors and committers.
> 
> There is a reason for this I have in mind. Ignite is a complex
> platform with several big modules. Some of the people may be experts
> in module A while others in module B etc.
> If a committer, who is good in module A, makes changes in module B
> merging the changes without a review this can break module's B
> internal functionality that the committer didn't take into account.
> 
> My proposal is to introduce a list of maintainers for every Ignite
> module like it's done in Spark [1] and a rule that will require a
> committer to get an approval from a module maintainer before merging
> changes.
> 
> Thoughts?
> 
> --
> Denis
> 
> [1] 
> https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-ReviewProcessandMaintainers
> 
> 
> 


signature.asc
Description: Digital signature

Re: Apache Arrow and Apache Ignite

[Konstantin Boudnik]

On Fri, Feb 26, 2016 at 09:22PM, Dood@ODDO wrote:
> On 2/25/2016 11:06 AM, Konstantin Boudnik wrote:
> >On Wed, Feb 24, 2016 at 02:02PM, Dood@ODDO wrote:
> >>On 2/24/2016 1:31 PM, Konstantin Boudnik wrote:
> >>>On Sat, Feb 20, 2016 at 02:13PM, Dood@ODDO wrote:
> >>>>That's the million dollar question - I think we should approach the
> >>>>Arrow people and get a conversation going. We want to be ahead of
> >>>>the curve, not behind it - Arrow seems to be making quite a stir,
> >>>>not to mention that it was fast-tracked to mature project status
> >>>>apparently solely based on the people/companies involved ;-)
> >>>I am afraid you misunderstand the point of the 'fast tracking'. To start 
> >>>with,
> >>>ASF doesn't case what companies are involved nor there's no such thing as 
> >>>fast
> >>>tracking. However, there's 'direct to TLP' track, that allows for a 
> >>>community
> >>>that has enough ASF members and other people, with lengthy involvement into
> >>>Apache projects, to go directly into TLP. The reason is simple: these 
> >>>people
> >>>are well versed in Apache Way and the incubation isn't required for me.
> >>>
> >>>So, please stop using this 'fast-tracked' confusion.
> >>>   Cos
> >>>
> >>>P.S. Another point: TLP != 'mature project status'. Please educate yourself
> >>>about the Apache incubation, before making statement like this in the 
> >>>future.
> >>>
> >>I will educate myself. What you need to do is learn to be polite. I
> >>am not sure you can teach that though ;(
> >If you don't mind elaborating on what particularly was impolite in my email, 
> >you'll
> >put me forever into your debts. And teach me a lesson of good manners too.
> >
> >Cos
> I don't know, you just came off as angered by what I said. You took
> the time to supposedly educate me how "fast tracking" is not the
> same as " taking a project directly to TLP" (which I think is
> obviously the same as fast tracking since it skipped the incubating
> phase). Then you took more time to educate me how people/companies
> are not what Apache looked at when fast tracking this project
> (pardon, taking the route called "direct to TLP") but you said that
> people experienced in the ways of Apache are what allowed for this
> project to be fast tracked (pardon again, taken "direct to TLP").

See, I too time to educate you on a variety of topics and provided you with
the pointers for future reading. How polite is that?

> Incidentally, who can join the dev list on the Arrow project at this
> stage? I tried a week ago and was unsuccessful. I was under the
> impression that anyone can join it.

dev@ lists are indeed open for everyone. If you email to
dev-subscribe@arrow.a.o hasn't been answered, try once again - sometimes
emails get dropped. You also can write to dev-owner@arrow.a.o and let them
know, that your request wasn't addressed. 

Cos


signature.asc
Description: Digital signature

Re: Apache Arrow and Apache Ignite

[Konstantin Boudnik]

On Wed, Feb 24, 2016 at 02:02PM, Dood@ODDO wrote:
> On 2/24/2016 1:31 PM, Konstantin Boudnik wrote:
> >On Sat, Feb 20, 2016 at 02:13PM, Dood@ODDO wrote:
> >>That's the million dollar question - I think we should approach the
> >>Arrow people and get a conversation going. We want to be ahead of
> >>the curve, not behind it - Arrow seems to be making quite a stir,
> >>not to mention that it was fast-tracked to mature project status
> >>apparently solely based on the people/companies involved ;-)
> >I am afraid you misunderstand the point of the 'fast tracking'. To start 
> >with,
> >ASF doesn't case what companies are involved nor there's no such thing as 
> >fast
> >tracking. However, there's 'direct to TLP' track, that allows for a community
> >that has enough ASF members and other people, with lengthy involvement into
> >Apache projects, to go directly into TLP. The reason is simple: these people
> >are well versed in Apache Way and the incubation isn't required for me.
> >
> >So, please stop using this 'fast-tracked' confusion.
> >   Cos
> >
> >P.S. Another point: TLP != 'mature project status'. Please educate yourself
> >about the Apache incubation, before making statement like this in the future.
> >
> 
> I will educate myself. What you need to do is learn to be polite. I
> am not sure you can teach that though ;(

If you don't mind elaborating on what particularly was impolite in my email, 
you'll
put me forever into your debts. And teach me a lesson of good manners too.

Cos


signature.asc
Description: Digital signature

Re: Apache Arrow and Apache Ignite

[Konstantin Boudnik]

On Sat, Feb 20, 2016 at 02:13PM, Dood@ODDO wrote:
> That's the million dollar question - I think we should approach the
> Arrow people and get a conversation going. We want to be ahead of
> the curve, not behind it - Arrow seems to be making quite a stir,
> not to mention that it was fast-tracked to mature project status
> apparently solely based on the people/companies involved ;-)

I am afraid you misunderstand the point of the 'fast tracking'. To start with,
ASF doesn't case what companies are involved nor there's no such thing as fast
tracking. However, there's 'direct to TLP' track, that allows for a community
that has enough ASF members and other people, with lengthy involvement into
Apache projects, to go directly into TLP. The reason is simple: these people
are well versed in Apache Way and the incubation isn't required for me.

So, please stop using this 'fast-tracked' confusion.
  Cos

P.S. Another point: TLP != 'mature project status'. Please educate yourself
about the Apache incubation, before making statement like this in the future.

> On 2/20/2016 11:14 AM, Dmitriy Setrakyan wrote:
> >It sounds to me that it does not store it’s own data, but allows to process
> >data from somewhere else, right? If yes, will I be able to take Ignite data
> >with Arrow and convert it to a columnar format for some other processing?
> >
> >On Sat, Feb 20, 2016 at 2:48 AM, Roman Shtykh 
> >wrote:
> >
> >>It's a standard (including format and algorithms) to share in-memory data
> >>between several big data platforms.
> >>In my understanding, it is like placing data in in-memory columns in
> >>Parquet and being able to use it in Kudu without serializing/deserializing.
> >>
> >>-Roman
> >>
> 


signature.asc
Description: Digital signature

Re: Re: Ignite Readme.IO UX issue

[Konstantin Boudnik]

And once again I would like to encourage this community to consider making
the documentation as a part of the source code, which would solve many issues
like that.

Cos

On Fri, Jan 29, 2016 at 10:58AM, 李玉珏 wrote:
> Hi
> 
> The following address:
> https://github.com/apacheignite/documentation/tree/v1.5
> The git commit comment that "automatic commit from readme", I think 
> readme.io with automatic backup function, and before this content is 
> always updated, but  recent canot synchronize with the online version.
> I logged in readme.io and also did not find automatic backup related 
> settings, only the export function, I do not know how this is going on.
> 
> If do not have this backup, if I can get the export file from the 
> community when the new version is released, there is no problem.
> 
> 
> Sent from Mail Master
> 
> 
> 
> On 2016-01-29 07:33 , Dmitriy Setrakyan Wrote:
> 
> Hi Yujie Li,
> 
> Can you please suggest what official github backup function you would like
> us to enable? I can’t find anything directly in Github, other than just a
> zip download.
> 
> Thanks,
> D.
> 
> On Wed, Jan 27, 2016 at 4:05 AM, 李玉珏@163 <18624049...@163.com> wrote:
> 
> > Hi:
> >
> > I have seen the changes in the document. I also found that part of the
> > DataGrid has added a new section called "Lock".
> > I maintain manual approach is, first from github document backup find
> > changes, then according to the change point to find the online version of
> > the difference and according to the online version do translation to ensure
> > document consistency, because I know there is a part of the document is not
> > open.
> > So, I would like to have the official github backup function, otherwise I
> > can't know what parts of the document have changed.
> >
> > 在 16/1/27 11:11, Dmitriy Setrakyan 写道:
> >
> > The version that corresponds to the documentation translated in Chinese is
> >> 1.5.0-b1:
> >> https://apacheignite.readme.io/v1.5-b1
> >>
> >> The new v.1.5 contains mainly the following changes:
> >> - Hadoop and Spark were moved to a separate space:
> >> https://apacheignite-fs.readme.io/docs
> >> - Every category has an overview session now, e.g. Clustering, Data
> >> Structures, etc.
> >>
> >> You should be able to compare the GIT repos to apply the changes. Let me
> >> know if you have more questions.
> >>
> >> D.
> >>
> >> On Tue, Jan 26, 2016 at 4:13 AM, 李玉珏@163 <18624049...@163.com> wrote:
> >>
> >> Hi：
> >>>
> >>> I found that there was update on the online manual, but the GitHub backup
> >>> is not updated.What is the reason?
> >>>
> >>> Https://github.com/apacheignite/documentation/tree/v1.5
> >>>
> >>> I was through the GitHub document to update the Chinese version of the
> >>> document, if you do not have this backup, I can not know that the
> >>> document
> >>> has been adjusted.
> >>>
> >>> 在 16/1/26 01:28, Dmitriy Setrakyan 写道:
> >>>
> >>> Hadoop/IGFS documentation is being refactored right now. Could be a side
> >>>
>  effect of what you were observing.
> 
>  Btw, everyone with login to readme can file a support issue. However, I
>  would not do it yet, while Prachi is still working on refactoring.
> 
>  D.
> 
>  On Mon, Jan 25, 2016 at 6:51 AM, Alexey Kuznetsov <
>  akuznet...@gridgain.com>
>  wrote:
> 
>  Hi!
> 
> > Does someone knows it is possible or not to "sync" left pane with
> > documentation categories and right pane with content of some selected
> > category?
> >
> > For example: https://apacheignite.readme.io/docs/igfs
> >
> > I see some IGFS documentation, but on the left pane I do not see
> > selected
> > category "IGFS", I need to scroll down. This is very annoying when you
> > are
> > reading several related topics - you need to scroll every time.
> >
> > As I know readme.io is a kind of CMS, so who knows how to open an
> > issue
> > for
> > them?
> > Do they have any kind of JIRA / mail list / support forum?
> >
> > --
> > Alexey Kuznetsov
> > GridGain Systems
> > www.gridgain.com
> >
> >
> >
> >>>
> >
> >


signature.asc
Description: Digital signature

Re: Ignite Readme.IO UX issue

[Konstantin Boudnik]

On Mon, Jan 25, 2016 at 09:28AM, Dmitriy Setrakyan wrote:
> Hadoop/IGFS documentation is being refactored right now. Could be a side
> effect of what you were observing.
> 
> Btw, everyone with login to readme can file a support issue. However, I
> would not do it yet, while Prachi is still working on refactoring.

Is there a JIRA for this? Would be easier to track, perhaps

> 
> D.
> 
> On Mon, Jan 25, 2016 at 6:51 AM, Alexey Kuznetsov 
> wrote:
> 
> > Hi!
> >
> > Does someone knows it is possible or not to "sync" left pane with
> > documentation categories and right pane with content of some selected
> > category?
> >
> > For example: https://apacheignite.readme.io/docs/igfs
> >
> > I see some IGFS documentation, but on the left pane I do not see selected
> > category "IGFS", I need to scroll down. This is very annoying when you are
> > reading several related topics - you need to scroll every time.
> >
> > As I know readme.io is a kind of CMS, so who knows how to open an issue
> > for
> > them?
> > Do they have any kind of JIRA / mail list / support forum?
> >
> > --
> > Alexey Kuznetsov
> > GridGain Systems
> > www.gridgain.com
> >


signature.asc
Description: Digital signature

Re: Marking fixed JIRAs against releases

[Konstantin Boudnik]

perhaps, someone with JIRA admin permissions need to rename the version number
then to avoid the confusion?

Cos

On Fri, Jan 22, 2016 at 06:57PM, Dmitriy Setrakyan wrote:
> I would say 1.5.0.final (the beta did not include all the fixes).
> 
> On Fri, Jan 22, 2016 at 5:26 PM, Konstantin Boudnik <c...@apache.org> wrote:
> 
> > Another issue: JIRA has release 1.5, however to my knowledge the project
> > had
> > at least
> > 1.5.0-b1
> > 1.5.0.final
> >
> > Which one JIRA's version is related to?
> >   Cos
> >
> > On Thu, Jan 21, 2016 at 05:33AM, Konstantin Boudnik wrote:
> > > There might be a way to enforce it on the JIRA side, I just have no
> > idea, to
> > > be honest. The best way is to file INFRA and ask them to help
> > >
> > > Cos
> > >
> > > On Tue, Jan 19, 2016 at 04:12PM, Yakov Zhdanov wrote:
> > > > Cos, very good catch.
> > > >
> > > > 1. Agree with Dmitry that it would be better to enforce version is set
> > on
> > > > close/resolution.
> > > > 2. As far as already closed tickets let's have everyone review tickets
> > > > closed by himself and put proper fixVersion.
> > > >
> > > > --Yakov
> > > >
> > > > 2016-01-19 9:53 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>:
> > > >
> > > > > Cos, to my knowledge, the release notes are generated by searching
> > for a
> > > > > fix version, so the tickets you are pointing out will likely be
> > missed.
> > > > >
> > > > > Generally speaking all fixed tickets should have a fix version.
> > Let’s make
> > > > > sure that we follow this rule going forward. (Any way to enforce it?)
> > > > >
> > > > > D.
> > > > >
> > > > > On Mon, Jan 18, 2016 at 3:50 PM, Konstantin Boudnik <c...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Guys,
> > > > > >
> > > > > > as a fall-out from another conversation I've ran the following
> > search on
> > > > > > JIRA
> > > > > >
> > > > > > project = ignite and status in (Fixed, Closed) and fixVersion
> > is null
> > > > > >
> > > > > > and we have 150 (yes, some of them are dups and won't fixes)
> > closed/fixed
> > > > > > tickets without explicit fixVersion on them. How do we keep track
> > of what
> > > > > > is a
> > > > > > particular release and what's not? How the Release Notes are
> > generated?
> > > > > >
> > > > > > Regards,
> > > > > >   Cos
> > > > > >
> > > > >
> >
> >
> >


signature.asc
Description: Digital signature

[jira] [Created] (IGNITE-2437) Zeppelin interperet doesn't import external dependencies

[Konstantin Boudnik (JIRA)]

Konstantin Boudnik created IGNITE-2437:
--

 Summary: Zeppelin interperet doesn't import external dependencies
 Key: IGNITE-2437
 URL: https://issues.apache.org/jira/browse/IGNITE-2437
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.5
 Environment: zeppelin 0.5.5
ignite 1.5.0.final
Reporter: Konstantin Boudnik


After configuring Ignite's interpreter for Zeppelin, tried to run the following 
{code}
%dep
z.load("/usr/lib/ignite/libs/ignite-cache-objects.jar")

%ignite
import io.company._
console>:23: error: object company is not a member of package io
   import io.company._
{code}

same code works just fine in spark interpreter though. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Marking fixed JIRAs against releases

[Konstantin Boudnik]

Another issue: JIRA has release 1.5, however to my knowledge the project had
at least 
1.5.0-b1
1.5.0.final

Which one JIRA's version is related to?
  Cos

On Thu, Jan 21, 2016 at 05:33AM, Konstantin Boudnik wrote:
> There might be a way to enforce it on the JIRA side, I just have no idea, to
> be honest. The best way is to file INFRA and ask them to help
> 
> Cos
> 
> On Tue, Jan 19, 2016 at 04:12PM, Yakov Zhdanov wrote:
> > Cos, very good catch.
> > 
> > 1. Agree with Dmitry that it would be better to enforce version is set on
> > close/resolution.
> > 2. As far as already closed tickets let's have everyone review tickets
> > closed by himself and put proper fixVersion.
> > 
> > --Yakov
> > 
> > 2016-01-19 9:53 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>:
> > 
> > > Cos, to my knowledge, the release notes are generated by searching for a
> > > fix version, so the tickets you are pointing out will likely be missed.
> > >
> > > Generally speaking all fixed tickets should have a fix version. Let’s make
> > > sure that we follow this rule going forward. (Any way to enforce it?)
> > >
> > > D.
> > >
> > > On Mon, Jan 18, 2016 at 3:50 PM, Konstantin Boudnik <c...@apache.org>
> > > wrote:
> > >
> > > > Guys,
> > > >
> > > > as a fall-out from another conversation I've ran the following search on
> > > > JIRA
> > > >
> > > > project = ignite and status in (Fixed, Closed) and fixVersion is 
> > > > null
> > > >
> > > > and we have 150 (yes, some of them are dups and won't fixes) 
> > > > closed/fixed
> > > > tickets without explicit fixVersion on them. How do we keep track of 
> > > > what
> > > > is a
> > > > particular release and what's not? How the Release Notes are generated?
> > > >
> > > > Regards,
> > > >   Cos
> > > >
> > >




signature.asc
Description: Digital signature

Re: Marking fixed JIRAs against releases

[Konstantin Boudnik]

There might be a way to enforce it on the JIRA side, I just have no idea, to
be honest. The best way is to file INFRA and ask them to help

Cos

On Tue, Jan 19, 2016 at 04:12PM, Yakov Zhdanov wrote:
> Cos, very good catch.
> 
> 1. Agree with Dmitry that it would be better to enforce version is set on
> close/resolution.
> 2. As far as already closed tickets let's have everyone review tickets
> closed by himself and put proper fixVersion.
> 
> --Yakov
> 
> 2016-01-19 9:53 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>:
> 
> > Cos, to my knowledge, the release notes are generated by searching for a
> > fix version, so the tickets you are pointing out will likely be missed.
> >
> > Generally speaking all fixed tickets should have a fix version. Let’s make
> > sure that we follow this rule going forward. (Any way to enforce it?)
> >
> > D.
> >
> > On Mon, Jan 18, 2016 at 3:50 PM, Konstantin Boudnik <c...@apache.org>
> > wrote:
> >
> > > Guys,
> > >
> > > as a fall-out from another conversation I've ran the following search on
> > > JIRA
> > >
> > > project = ignite and status in (Fixed, Closed) and fixVersion is null
> > >
> > > and we have 150 (yes, some of them are dups and won't fixes) closed/fixed
> > > tickets without explicit fixVersion on them. How do we keep track of what
> > > is a
> > > particular release and what's not? How the Release Notes are generated?
> > >
> > > Regards,
> > >   Cos
> > >
> >


signature.asc
Description: Digital signature

Re: What is jdbc:ignite:cfg ??

[Konstantin Boudnik]

On Wed, Jan 20, 2016 at 03:32PM, Andrey Gura wrote:
> Dmitry,
> 
> We can suggest to Zepplin comunity introduce parameters per
> notebook/paragraph that can be passed to interpreter.
> 
> The second option is adding some keywords that can be parsed by
> interpreter.
> 
> I think that Val's suggestion is more suitable at this moment.

I actually like Val's ideas as well. What he is proposing is the way to
improve UX of the product. See, more and more ppl - especially in this
FastData arena - aren't developers. They won't know an exception even if you
hit them over the head with one. Hence, whenever an exception is thrown in the
UI like Zeppelin, that's the end of the world for most of them.

Ideally, we need to go an extra mile to hide all this complexity as much as
possible. In fact, the complexity is what killing all these cool technologies.
In order to run some simple linear regression calculation, one has to be an
expert in Unix, Java, system integration, and god knows what else ;) 

Cos

> On Wed, Jan 20, 2016 at 1:10 AM, Dmitriy Setrakyan <dsetrak...@apache.org>
> wrote:
> 
> > Can we just start a different client connection per-notebook? This way user
> > can specify different default cache per notebook, no?
> >
> > Andrey, we already have the explanation for why it does not work. Can you
> > provide some ideas on what needs to happen to make it work?
> >
> > D.
> >
> > On Tue, Jan 19, 2016 at 11:22 AM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Andrey,
> > >
> > > My answers are inline...
> > >
> > > On Tue, Jan 19, 2016 at 4:14 AM, Andrey Gura <ag...@gridgain.com> wrote:
> > >
> > > > Val,
> > > >
> > > > I have a couple of questions:
> > > >
> > > > 1. What cache should be used by JDBC driver for query execution when no
> > > > cache name in JDBC URL? I see only one option: any user cache. But it
> > can
> > > > bring some random behavior. Caches can be created/deleted dynamically
> > and
> > > > JDBC connection can refer to removed cache.
> > > >
> > >
> > > If cache name is not provided in the URL, all cache names have to be
> > > provided in the query (except the default cache if it exists). If one of
> > > the names refers to non-existing cache, exception will be thrown. Default
> > > cache is not different from this standpoint - if the query contains a
> > type
> > > without cache name specified and default cache doesn't exist, exception
> > is
> > > thrown as well.
> > >
> > >
> > > >
> > > > 2. How user should refer to default cache in queries in case when some
> > > non
> > > > default cache name used as connection parameter?
> > > >
> > >
> > > This is something that is not possible now anyway, right? Actually, I've
> > > never seen an example of the default cache being used, especially if
> > > multiple caches are used. So I would not sacrifice usability to support
> > > this use case. If one wants to query the default cache, leave it blank in
> > > the URL and explicitly specify names of all other caches.
> > >
> > >
> > > >
> > > >
> > > >
> > > > On Tue, Jan 19, 2016 at 12:47 AM, Valentin Kulichenko <
> > > > valentin.kuliche...@gmail.com> wrote:
> > > >
> > > > > I think we can just remove the requirement of having the default
> > cache
> > > > when
> > > > > no cache name is provided in the JDBC URL. I don't see any reason to
> > > > refuse
> > > > > connection in this case, because if query doesn't properly specify
> > > cache
> > > > > names for all participating types, the exception will be thrown
> > anyway.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > -Val
> > > > >
> > > > > On Mon, Jan 18, 2016 at 6:35 AM, Andrey Gura <ag...@gridgain.com>
> > > wrote:
> > > > >
> > > > > > Cos,
> > > > > >
> > > > > > if cache name isn't specified in JDBC URL then default cache will
> > be
> > > > > used.
> > > > > >
> > > > > > If default cache isn't created then driver will throw exception
> > with
> > > > > > "Client is invalid. Probably cache name is wrong" message.
> > 

Marking fixed JIRAs against releases

[Konstantin Boudnik]

Guys,

as a fall-out from another conversation I've ran the following search on
JIRA

project = ignite and status in (Fixed, Closed) and fixVersion is null

and we have 150 (yes, some of them are dups and won't fixes) closed/fixed
tickets without explicit fixVersion on them. How do we keep track of what is a
particular release and what's not? How the Release Notes are generated?

Regards,
  Cos


signature.asc
Description: Digital signature

Re: Json support in Ignite

[Konstantin Boudnik]

One other thing to keep in mind, that JSON data is often not-flattened ie
coming with hierarchical structures. In which case, querying it from Ignite
would be a non-trivial if at all possible.

Cos

On Thu, Jan 14, 2016 at 09:09AM, Dmitriy Setrakyan wrote:
> I would consider a case for generating hash-code by iterating through all
> the fields by default. We need to make sure that the iteration order is the
> same on both ends.
> 
> User can always override it, no?
> 
> D.
> 
> On Thu, Jan 14, 2016 at 8:10 AM, Andrey Gura  wrote:
> 
> > Hi,
> >
> >
> > > > Also we need following functionality for json objects
> > > >
> > > > 1. Possibility to map json cache key to affinity key. This can be
> > > achieved
> > > > with custom affinity mapper:
> > > >
> > > > cache.setAffinityMapper(new AffinityKeyMapper() {
> > > > @Override public Object affinityKey(Object key) {
> > > > return
> > ((JsonObject)key).getJsonNumber("orgId").longValue();
> > > > }
> > > > });
> > > >
> > >
> > > We can also have a special field within JSON Object, called
> > > ignite_affinity_field=bla
> >
> >
> > +1
> >
> > It looks like we are over architecting here.
> > >
> > > Keys should not have many fields, and most likely will have one or two.
> > > Iterating through fields and generating hash-code or equals the standard
> > > way seems reasonable (as opposed to creating a whole architecture around
> > > how to get hash and equals fields).
> > >
> > > If it makes sense, we should cache the hash code value inside the key
> > > object after it has been generated once.
> > >
> >
> > I don't think that we should have some constraints here. If user wants to
> > use specific set of fields for hashCode/equals he should have such
> > possibility.
> >
> > There is one more problem in hashCode/equals: how to handle cases when
> > specified field isn't mandatory?
> >
> >
> > On Wed, Jul 15, 2015 at 11:32 AM, Dmitriy Setrakyan  > >
> > wrote:
> >
> > > On Wed, Jul 15, 2015 at 12:00 AM, Semyon Boikov 
> > > wrote:
> > >
> > > > Hi all,
> > > >
> > > > As part of integration with Node.Js (IGNITE-961) we age going to add in
> > > > Ignite support for JSON (possibility for IgniteCache to put, get, index
> > > and
> > > > query JSON data).
> > > >
> > > > We can implement standard 'javax.json' API (JSR 353), with this API
> > work
> > > > with cache will look like in this example:
> > > >
> > > >
> > > Are we going to implement JSON specification ourselves? Sounds a bit
> > fishy.
> > > Can we just take some available implementation (assuming that the license
> > > fits)?
> > >
> > >
> > >
> > > > Ignite should somehow provide access to 'javax.json' API, unfortunately
> > > > 'javax.json' is not part of JDK so we have several options how it can
> > be
> > > > added in Ignite:
> > > >
> > > > 1. Add dependency for 'javax.json-api' in core module, in this case we
> > > can
> > > > have method to get access for json API on 'org.apache.ignite.Ignite':
> > > >
> > > > * interface Ignite {*
> > > > *...*
> > > >
> > > > *javax.json.JsonProvider json();*
> > > > * }*
> > > >
> > > > * JsonProvider json = ignite.json();*
> > > >
> > > > Not sure it is ok, since now we don't have 3rd party dependencies in
> > > ignite
> > > > 'core' module except 'javax.cache' API.
> > > >
> > > > 2. Added another optional module 'json', this module will have
> > dependency
> > > > for 'javax.json' API, and in this module we can have factory providing
> > > > access to 'javax.json' API:
> > > >
> > >
> > > I think an optional module makes sense.
> > >
> > >
> > >
> > > >
> > > > 3. Create plugin for json, in this case plugin will provide access to
> > > > 'javax.json' API:
> > > >
> > > > * IgniteJsonPlugin jsonPlugin = ignite.plugin(IgniteJsonPlugin.NAME);*
> > > >
> > > > * javax.json.JsonProvider provider = jsonPlugin.json();*
> > > >
> > > >
> > > > Not sure this aproach with plugin is ok, since now we don't have 'core'
> > > > ignite functionality implemented as plugins.
> > > >
> > >
> > > Agree, this probably won't work.
> > >
> > >
> > >
> > > > Also we need following functionality for json objects
> > > >
> > > > 1. Possibility to map json cache key to affinity key. This can be
> > > achieved
> > > > with custom affinity mapper:
> > > >
> > > > cache.setAffinityMapper(new AffinityKeyMapper() {
> > > > @Override public Object affinityKey(Object key) {
> > > > return
> > ((JsonObject)key).getJsonNumber("orgId").longValue();
> > > > }
> > > > });
> > > >
> > >
> > > We can also have a special field within JSON Object, called
> > > ignite_affinity_field=bla
> > >
> > >
> > > >
> > > > 2. Efficient implementation for equals/hashCode for json cache keys.
> > > >
> > > > One option is just have equals/hashCode like in HashMap.
> > > >
> > > > Another option can be add special JsonConfiguration, it should be set
> > in
> > > >