You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Denis Magda <dm...@apache.org> on 2017/04/18 02:37:40 UTC
GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
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: GridGain Donates Persistent Distributed Store To ASF (Apache
Ignite)
Posted by Denis Magda <dm...@apache.org>.
Igniters,
I would encourage everyone interested to share his/her opinion on this donation and if there are no objections I will kick off an official vote in a couple of ways.
—
Denis
> On Apr 18, 2017, at 4:11 AM, Nikita Ivanov <ni...@gmail.com> wrote:
>
> Combining this with upcoming new SQL features should give Google Spanner a
> run for its money...
> --
> Nikita Ivanov
>
>
> On Tue, Apr 18, 2017 at 3:39 AM, christos <ch...@gridgain.com> wrote:
>
>> This is fantastic news guys!! Finally a real solution that can cater for
>> BIG
>> AND FAST data!
>>
>>
>>
>> --
>> View this message in context: http://apache-ignite-
>> developers.2346864.n4.nabble.com/GridGain-Donates-
>> Persistent-Distributed-Store-To-ASF-Apache-Ignite-tp16788p16836.html
>> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
>>
Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Nikita Ivanov <ni...@gmail.com>.
Combining this with upcoming new SQL features should give Google Spanner a
run for its money...
--
Nikita Ivanov
On Tue, Apr 18, 2017 at 3:39 AM, christos <ch...@gridgain.com> wrote:
> This is fantastic news guys!! Finally a real solution that can cater for
> BIG
> AND FAST data!
>
>
>
> --
> View this message in context: http://apache-ignite-
> developers.2346864.n4.nabble.com/GridGain-Donates-
> Persistent-Distributed-Store-To-ASF-Apache-Ignite-tp16788p16836.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
>
Re: GridGain Donates Persistent Distributed Store To ASF (Apache
Ignite)
Posted by christos <ch...@gridgain.com>.
This is fantastic news guys!! Finally a real solution that can cater for BIG
AND FAST data!
--
View this message in context: http://apache-ignite-developers.2346864.n4.nabble.com/GridGain-Donates-Persistent-Distributed-Store-To-ASF-Apache-Ignite-tp16788p16836.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Sergi Vladykin <se...@gmail.com>.
Nice! Finally Ignite from a "Middleware Solution" becoming an "All In One
Backend Solution".
Sergi
2017-04-18 5:46 GMT+03:00 Dmitriy Setrakyan <ds...@apache.org>:
> Great news and I am glad that GridGain was finally able to open source such
> an essential feature to Ignite. Given that I was deeply involved in the
> development of this feature for the past year, I would add that one of the
> main advantages here is that Ignite becomes fully operational from disk
> (SSD or Flash) without any need to preload the data in memory.
>
> With full SQL support available in Ignite, this feature will allow Ignite
> serve as a distributed transactional database, both in memory and on disk,
> while continuing to support all the existing use cases, including the
> in-memory data grid.
>
> Cos, can you point us to any legal paperwork that needs to be signed in
> order to complete the donation?
>
> D.
>
> On Mon, Apr 17, 2017 at 7:37 PM, Denis Magda <dm...@apache.org> 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: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Dmitriy Setrakyan <ds...@apache.org>.
Great news and I am glad that GridGain was finally able to open source such
an essential feature to Ignite. Given that I was deeply involved in the
development of this feature for the past year, I would add that one of the
main advantages here is that Ignite becomes fully operational from disk
(SSD or Flash) without any need to preload the data in memory.
With full SQL support available in Ignite, this feature will allow Ignite
serve as a distributed transactional database, both in memory and on disk,
while continuing to support all the existing use cases, including the
in-memory data grid.
Cos, can you point us to any legal paperwork that needs to be signed in
order to complete the donation?
D.
On Mon, Apr 17, 2017 at 7:37 PM, Denis Magda <dm...@apache.org> 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: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Tue, Apr 18, 2017 at 11:54 PM, Dmitriy Setrakyan
<ds...@apache.org> wrote:
> On Tue, Apr 18, 2017 at 11:17 PM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
>
>> On Mon, Apr 17, 2017 at 7:37 PM, Denis Magda <dm...@apache.org> wrote:
>>
>> First of all, it really isn't a good thing that a major functionality
>> was developed
>> behind the firewall without any feedback from Apache Ignite community.
>>
>> So the first question I'd like to ask is this: what was the reason for this
>> to be developed in such a way (and a follow up -- how can this be
>> avoided in the future)?
>>
>> In my experience the only excuse for something like that is either a work
>> that was done before the project joined ASF or work that was done under
>> the draconian initial license agreement that can now be re-licensed under
>> ASF.
>>
>
> Completely agree and I would also personally prefer that all features are
> developed in the open source community from the get go. In this case it was
> not possible, as it initially was developed for one of the GridGain
> customers and eventually evolved into something that could add value to the
> community - hence the proposal to open source it.
Fair enough.
> The code is not complete yet, and will require additional development
> before it can become a part of an official Ignite release. I would prefer
> that the remaining development can happen openly in the Ignite community.
You can most definitely keep refactoring it -- but that'll have to
happen in a branch.
>> Which brings me to my next point: any addition to the project that doesn't
>> go through the normal channels of small reversible commits that are easy
>> to scrutinize for IP issues needs to be vetted. Depending on the size of
>> the
>> donation a separate SGA for ASF may be required.
>>
>
> Correct. We will also be required to fill out the IP-Clearance form,
> specifically designed for situations like this one, when a code is donated
> into an existing code base:
>
> http://incubator.apache.org/ip-clearance/
>
>
>>
>> Which brings me to my last point: where's the code? In order to have a
>> factual conversation about the next steps in the process I'd like to be
>> able to take a look at the code available to me under the Apache License.
>>
>
> Hm... I guess you are right, the code needs to be provided in a public GIT
> repository for review. To my knowledge this has not been done yet.
>
>
>> On top of which, I would like to either have a full access to the commit
>> and authorship history of this code OR a statement from the current
>> overall copyright owner.
>>
>
> Would a standard SGA suffice here?
Is there a single copyright owner for the codebase? If there's is -- then yes
you can file an SGA.
> 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?
You have to provide SGA and code base right away. Not making those available
will preclude any meaningful discussion and most certainly will preclude a vote.
Note that filing an SGA doesn't mean that the code will end up in ASF
-- it means
ASF (read its members) will have a right to scrutinize it without the
fear of being
exposed to questionable IP.
In order to file an SGA you will have to make the code available.
So here's a set of steps you need to do:
1. make code available some place on GitHub
2. file and SGA with ASF pointing at a tag in that repo
3. once both of these are done -- restart the discussion thread
Thanks,
Roman.
Re: GridGain Donates Persistent Distributed Store To ASF (Apache
Ignite)
Posted by Denis Magda <dm...@apache.org>.
Cos, Roman,
Your concerns sound reasonable to me. However, that’s my personal point of view and not of the overall community. Personally, I accustomed to lean on the notion of releases and deadlines. Not sure that it contradicts ASF principles or can’t be applied to Apache projects. In any case it’s up to the community to decide how to proceed. I’m just trying to form a sort of process ;)
In general, I would avoid all the arguments and look at the storage collaboratively and constructively. I didn’t consider to rush you. Just forwarded you the message so that you can spot it among many falling in your inbox. Take whatever time you need.
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 <http://incubator.apache.org/ip-clearance/ip-clearance-template.html>
Could any of you grant me karma or commit the changes from your accounts?
> 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 <https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-1.CreateGitHubpull-request>
Cos, the IP Clearance/grant process was followed and the following artifacts were prepared as a part of it (if you prefer the pull-request then it should be possible to do it):
The repository with the donation is ready and available for review:
https://github.com/agoncharuk/ignite/tree/pds-donate <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 <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 <https://cwiki.apache.org/confluence/display/IGNITE/Persistent+Store+Internal+Design>
—
Denis
> On May 17, 2017, at 8:01 PM, Roman Shaposhnik <rv...@apache.org> wrote:
>
> On Wed, May 17, 2017 at 3:04 PM, Konstantin Boudnik <co...@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
>> are important here, they convey a very different meaning.
>
> Which brings me to a related question: what exactly needs to be released
> on this aggressive schedule and who is a beneficiary of this release?
>
> What I am trying to say is this: if GirdGain has a product delivery
> deadline -- the
> company can go ahead and release its product with whatever features it needs to.
>
> But I'm with Cos -- the community has to be given time to get comfortable with
> the code base if for nothing else but for licensing implications.
>
> Thanks,
> Roman.
Re: GridGain Donates Persistent Distributed Store To ASF (Apache
Ignite)
Posted by Denis Magda <dm...@apache.org>.
> 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.
Followed Raul’s suggestion and initiated the VOTE as a part of different discussion:
http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Accept-Contribution-of-Ignite-Persistent-Store-td17896.html
Take your time to review the donation and vote once you’re ready.
—
Denis
> On May 19, 2017, at 4:08 AM, Raúl Kripalani <ra...@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 <ds...@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 <rv...@apache.org> wrote:
>>
>>> On Wed, May 17, 2017 at 3:04 PM, Konstantin Boudnik <co...@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
>>>> are important here, they convey a very different meaning.
>>>
>>> Which brings me to a related question: what exactly needs to be released
>>> on this aggressive schedule and who is a beneficiary of this release?
>>>
>>> What I am trying to say is this: if GirdGain has a product delivery
>>> deadline -- the
>>> company can go ahead and release its product with whatever features it
>>> needs to.
>>>
>>> But I'm with Cos -- the community has to be given time to get comfortable
>>> with
>>> the code base if for nothing else but for licensing implications.
>>>
>>> Thanks,
>>> Roman.
>>>
>>
Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Dmitriy Setrakyan <ds...@apache.org>.
Hi Raul, thanks for jumping in! I agree on all points.
On Fri, May 19, 2017 at 4:08 AM, Raúl Kripalani <ra...@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 <ds...@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 <rv...@apache.org>
> wrote:
> >
> > > On Wed, May 17, 2017 at 3:04 PM, Konstantin Boudnik <co...@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
> > > > are important here, they convey a very different meaning.
> > >
> > > Which brings me to a related question: what exactly needs to be
> released
> > > on this aggressive schedule and who is a beneficiary of this release?
> > >
> > > What I am trying to say is this: if GirdGain has a product delivery
> > > deadline -- the
> > > company can go ahead and release its product with whatever features it
> > > needs to.
> > >
> > > But I'm with Cos -- the community has to be given time to get
> comfortable
> > > with
> > > the code base if for nothing else but for licensing implications.
> > >
> > > Thanks,
> > > Roman.
> > >
> >
>
Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Konstantin Boudnik <co...@apache.org>.
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 <ra...@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 <ds...@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 <rv...@apache.org> wrote:
>>
>> > On Wed, May 17, 2017 at 3:04 PM, Konstantin Boudnik <co...@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
>> > > are important here, they convey a very different meaning.
>> >
>> > Which brings me to a related question: what exactly needs to be released
>> > on this aggressive schedule and who is a beneficiary of this release?
>> >
>> > What I am trying to say is this: if GirdGain has a product delivery
>> > deadline -- the
>> > company can go ahead and release its product with whatever features it
>> > needs to.
>> >
>> > But I'm with Cos -- the community has to be given time to get comfortable
>> > with
>> > the code base if for nothing else but for licensing implications.
>> >
>> > Thanks,
>> > Roman.
>> >
>>
Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Raúl Kripalani <ra...@evosent.com>.
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 <ds...@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 <rv...@apache.org> wrote:
>
> > On Wed, May 17, 2017 at 3:04 PM, Konstantin Boudnik <co...@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
> > > are important here, they convey a very different meaning.
> >
> > Which brings me to a related question: what exactly needs to be released
> > on this aggressive schedule and who is a beneficiary of this release?
> >
> > What I am trying to say is this: if GirdGain has a product delivery
> > deadline -- the
> > company can go ahead and release its product with whatever features it
> > needs to.
> >
> > But I'm with Cos -- the community has to be given time to get comfortable
> > with
> > the code base if for nothing else but for licensing implications.
> >
> > Thanks,
> > Roman.
> >
>
Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Denis Magda <dm...@gridgain.com>.
Roman, yes the software grant was acknowledged by Craig Russel. I mentioned
this earlier in the discussion.
On Friday, May 19, 2017, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> On Fri, May 19, 2017 at 2:08 PM, Dmitriy Setrakyan
> <dsetrakyan@apache.org <javascript:;>> wrote:
> > Hm... I think I misunderstood the issue.
> >
> > In this case, since there is no disagreement, I would propose the
> following
> > steps then:
> >
> > 1. We should merge the code into a separate Ignite branch and start
> > stabilizing it.
>
> Wait! Before that happens -- has there SGA been filed already? I apologize
> if it has and I missed it.
>
> Just trying to make sure we only land code on ASF infrastructure once
> proper
> legal paperwork has been received by the secretary@
>
> Thanks,
> Roman.
>
Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Fri, May 19, 2017 at 2:08 PM, Dmitriy Setrakyan
<ds...@apache.org> wrote:
> Hm... I think I misunderstood the issue.
>
> In this case, since there is no disagreement, I would propose the following
> steps then:
>
> 1. We should merge the code into a separate Ignite branch and start
> stabilizing it.
Wait! Before that happens -- has there SGA been filed already? I apologize
if it has and I missed it.
Just trying to make sure we only land code on ASF infrastructure once proper
legal paperwork has been received by the secretary@
Thanks,
Roman.
Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Alexey Goncharuk <al...@gmail.com>.
Guys,
As discussed, pushed the branch being stabilized to ignite-5267 (and
created the corresponding ticket).
2017-05-21 6:48 GMT+03:00 Denis Magda <dm...@apache.org>:
> Sounds good to me.
>
> To keep all of you in the loop, eventually, the *IP clearance vote* has
> been initiated on @incubator-general. Here is the form:
> http://incubator.apache.org/ip-clearance/persistent-
> distributed-store-ignite.html <http://incubator.apache.org/
> ip-clearance/persistent-distributed-store-ignite.html>
>
> —
> Denis
>
> > On May 19, 2017, at 5:08 PM, Dmitriy Setrakyan <ds...@apache.org>
> wrote:
> >
> > Hm... I think I misunderstood the issue.
> >
> > In this case, since there is no disagreement, I would propose the
> following
> > steps then:
> >
> > 1. We should merge the code into a separate Ignite branch and start
> > stabilizing it.
> > 2. Let's start the VOTE to accept the donation once the code is merged.
> > As Raul suggested, let's keep the VOTE to accept the donation separate
> from
> > any decision on what to do with the donation or when to release it.
> > 3. I am hoping that once the donation is accepted, all the discussions
> > about the new code, moving it to Ignite standards, stabilizing it, and
> > eventually releasing it should happen on the dev list, which should
> allow
> > everyone in the community to familiarize themselves with it.
> >
> > Does this sound like an agreeable process to move forward?
> >
> > D.
> >
> > On Fri, May 19, 2017 at 11:53 AM, Konstantin Boudnik <co...@boudnik.org>
> > wrote:
> >
> >> Dmitriy,
> >>
> >> no one has ever suggested to keep the code in a separate repository
> >> (once the grant issues were sorted out). Not sure where you get this
> >> impression. I don't think there's anything to argue about ;)
> >>
> >> Cos
> >>
> >>
> >> --
> >> Take care,
> >> Konstantin (Cos) Boudnik
> >>
> >>
> >> On Thu, May 18, 2017 at 6:36 PM, Dmitriy Setrakyan
> >> <ds...@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 <rv...@apache.org>
> >> wrote:
> >>>
> >>>> On Wed, May 17, 2017 at 3:04 PM, Konstantin Boudnik <co...@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
> >>>>> are important here, they convey a very different meaning.
> >>>>
> >>>> Which brings me to a related question: what exactly needs to be
> released
> >>>> on this aggressive schedule and who is a beneficiary of this release?
> >>>>
> >>>> What I am trying to say is this: if GirdGain has a product delivery
> >>>> deadline -- the
> >>>> company can go ahead and release its product with whatever features it
> >>>> needs to.
> >>>>
> >>>> But I'm with Cos -- the community has to be given time to get
> >> comfortable
> >>>> with
> >>>> the code base if for nothing else but for licensing implications.
> >>>>
> >>>> Thanks,
> >>>> Roman.
> >>>>
> >>
>
>
Re: GridGain Donates Persistent Distributed Store To ASF (Apache
Ignite)
Posted by Denis Magda <dm...@apache.org>.
Sounds good to me.
To keep all of you in the loop, eventually, the *IP clearance vote* has been initiated on @incubator-general. Here is the form:
http://incubator.apache.org/ip-clearance/persistent-distributed-store-ignite.html <http://incubator.apache.org/ip-clearance/persistent-distributed-store-ignite.html>
—
Denis
> On May 19, 2017, at 5:08 PM, Dmitriy Setrakyan <ds...@apache.org> wrote:
>
> Hm... I think I misunderstood the issue.
>
> In this case, since there is no disagreement, I would propose the following
> steps then:
>
> 1. We should merge the code into a separate Ignite branch and start
> stabilizing it.
> 2. Let's start the VOTE to accept the donation once the code is merged.
> As Raul suggested, let's keep the VOTE to accept the donation separate from
> any decision on what to do with the donation or when to release it.
> 3. I am hoping that once the donation is accepted, all the discussions
> about the new code, moving it to Ignite standards, stabilizing it, and
> eventually releasing it should happen on the dev list, which should allow
> everyone in the community to familiarize themselves with it.
>
> Does this sound like an agreeable process to move forward?
>
> D.
>
> On Fri, May 19, 2017 at 11:53 AM, Konstantin Boudnik <co...@boudnik.org>
> wrote:
>
>> Dmitriy,
>>
>> no one has ever suggested to keep the code in a separate repository
>> (once the grant issues were sorted out). Not sure where you get this
>> impression. I don't think there's anything to argue about ;)
>>
>> Cos
>>
>>
>> --
>> Take care,
>> Konstantin (Cos) Boudnik
>>
>>
>> On Thu, May 18, 2017 at 6:36 PM, Dmitriy Setrakyan
>> <ds...@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 <rv...@apache.org>
>> wrote:
>>>
>>>> On Wed, May 17, 2017 at 3:04 PM, Konstantin Boudnik <co...@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
>>>>> are important here, they convey a very different meaning.
>>>>
>>>> Which brings me to a related question: what exactly needs to be released
>>>> on this aggressive schedule and who is a beneficiary of this release?
>>>>
>>>> What I am trying to say is this: if GirdGain has a product delivery
>>>> deadline -- the
>>>> company can go ahead and release its product with whatever features it
>>>> needs to.
>>>>
>>>> But I'm with Cos -- the community has to be given time to get
>> comfortable
>>>> with
>>>> the code base if for nothing else but for licensing implications.
>>>>
>>>> Thanks,
>>>> Roman.
>>>>
>>
Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Dmitriy Setrakyan <ds...@apache.org>.
Hm... I think I misunderstood the issue.
In this case, since there is no disagreement, I would propose the following
steps then:
1. We should merge the code into a separate Ignite branch and start
stabilizing it.
2. Let's start the VOTE to accept the donation once the code is merged.
As Raul suggested, let's keep the VOTE to accept the donation separate from
any decision on what to do with the donation or when to release it.
3. I am hoping that once the donation is accepted, all the discussions
about the new code, moving it to Ignite standards, stabilizing it, and
eventually releasing it should happen on the dev list, which should allow
everyone in the community to familiarize themselves with it.
Does this sound like an agreeable process to move forward?
D.
On Fri, May 19, 2017 at 11:53 AM, Konstantin Boudnik <co...@boudnik.org>
wrote:
> Dmitriy,
>
> no one has ever suggested to keep the code in a separate repository
> (once the grant issues were sorted out). Not sure where you get this
> impression. I don't think there's anything to argue about ;)
>
> Cos
>
>
> --
> Take care,
> Konstantin (Cos) Boudnik
>
>
> On Thu, May 18, 2017 at 6:36 PM, Dmitriy Setrakyan
> <ds...@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 <rv...@apache.org>
> wrote:
> >
> >> On Wed, May 17, 2017 at 3:04 PM, Konstantin Boudnik <co...@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
> >> > are important here, they convey a very different meaning.
> >>
> >> Which brings me to a related question: what exactly needs to be released
> >> on this aggressive schedule and who is a beneficiary of this release?
> >>
> >> What I am trying to say is this: if GirdGain has a product delivery
> >> deadline -- the
> >> company can go ahead and release its product with whatever features it
> >> needs to.
> >>
> >> But I'm with Cos -- the community has to be given time to get
> comfortable
> >> with
> >> the code base if for nothing else but for licensing implications.
> >>
> >> Thanks,
> >> Roman.
> >>
>
Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Konstantin Boudnik <co...@boudnik.org>.
Dmitriy,
no one has ever suggested to keep the code in a separate repository
(once the grant issues were sorted out). Not sure where you get this
impression. I don't think there's anything to argue about ;)
Cos
--
Take care,
Konstantin (Cos) Boudnik
On Thu, May 18, 2017 at 6:36 PM, Dmitriy Setrakyan
<ds...@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 <rv...@apache.org> wrote:
>
>> On Wed, May 17, 2017 at 3:04 PM, Konstantin Boudnik <co...@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
>> > are important here, they convey a very different meaning.
>>
>> Which brings me to a related question: what exactly needs to be released
>> on this aggressive schedule and who is a beneficiary of this release?
>>
>> What I am trying to say is this: if GirdGain has a product delivery
>> deadline -- the
>> company can go ahead and release its product with whatever features it
>> needs to.
>>
>> But I'm with Cos -- the community has to be given time to get comfortable
>> with
>> the code base if for nothing else but for licensing implications.
>>
>> Thanks,
>> Roman.
>>
Re: GridGain Donates Persistent Distributed Store To ASF (Apache
Ignite)
Posted by Denis Magda <dm...@apache.org>.
Cos,
The folks just followed Roman’s suggestion:
------------
So here's a set of steps you need to do:
1. make code available some place on GitHub
2. file and SGA with ASF pointing at a tag in that repo
3. once both of these are done -- restart the discussion thread
————————
Basically, if to take a look at the list of donations on this page [1] it’s up to a community to decide where to “incubate” a donation - on a private GitHub repo or in an ASF branch.
[1] http://incubator.apache.org/ip-clearance/index.html <http://incubator.apache.org/ip-clearance/index.html>
—
Denis
> On May 19, 2017, at 2:55 PM, Konstantin Boudnik <co...@apache.org> wrote:
>
> Dmitriy,
>
> no one has ever suggested to keep the code in a separate repository
> (once the grant issues were sorted out). Not sure where you get this
> impression. I don't think there's anything to argue about ;)
> --
> 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, May 18, 2017 at 6:36 PM, Dmitriy Setrakyan
> <ds...@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 <rv...@apache.org> wrote:
>>
>>> On Wed, May 17, 2017 at 3:04 PM, Konstantin Boudnik <co...@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
>>>> are important here, they convey a very different meaning.
>>>
>>> Which brings me to a related question: what exactly needs to be released
>>> on this aggressive schedule and who is a beneficiary of this release?
>>>
>>> What I am trying to say is this: if GirdGain has a product delivery
>>> deadline -- the
>>> company can go ahead and release its product with whatever features it
>>> needs to.
>>>
>>> But I'm with Cos -- the community has to be given time to get comfortable
>>> with
>>> the code base if for nothing else but for licensing implications.
>>>
>>> Thanks,
>>> Roman.
>>>
Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Konstantin Boudnik <co...@apache.org>.
Dmitriy,
no one has ever suggested to keep the code in a separate repository
(once the grant issues were sorted out). Not sure where you get this
impression. I don't think there's anything to argue about ;)
--
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, May 18, 2017 at 6:36 PM, Dmitriy Setrakyan
<ds...@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 <rv...@apache.org> wrote:
>
>> On Wed, May 17, 2017 at 3:04 PM, Konstantin Boudnik <co...@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
>> > are important here, they convey a very different meaning.
>>
>> Which brings me to a related question: what exactly needs to be released
>> on this aggressive schedule and who is a beneficiary of this release?
>>
>> What I am trying to say is this: if GirdGain has a product delivery
>> deadline -- the
>> company can go ahead and release its product with whatever features it
>> needs to.
>>
>> But I'm with Cos -- the community has to be given time to get comfortable
>> with
>> the code base if for nothing else but for licensing implications.
>>
>> Thanks,
>> Roman.
>>
Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Dmitriy Setrakyan <ds...@apache.org>.
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 <rv...@apache.org> wrote:
> On Wed, May 17, 2017 at 3:04 PM, Konstantin Boudnik <co...@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
> > are important here, they convey a very different meaning.
>
> Which brings me to a related question: what exactly needs to be released
> on this aggressive schedule and who is a beneficiary of this release?
>
> What I am trying to say is this: if GirdGain has a product delivery
> deadline -- the
> company can go ahead and release its product with whatever features it
> needs to.
>
> But I'm with Cos -- the community has to be given time to get comfortable
> with
> the code base if for nothing else but for licensing implications.
>
> Thanks,
> Roman.
>
Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Roman Shaposhnik <rv...@apache.org>.
On Wed, May 17, 2017 at 3:04 PM, Konstantin Boudnik <co...@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
> are important here, they convey a very different meaning.
Which brings me to a related question: what exactly needs to be released
on this aggressive schedule and who is a beneficiary of this release?
What I am trying to say is this: if GirdGain has a product delivery
deadline -- the
company can go ahead and release its product with whatever features it needs to.
But I'm with Cos -- the community has to be given time to get comfortable with
the code base if for nothing else but for licensing implications.
Thanks,
Roman.
Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Konstantin Boudnik <co...@apache.org>.
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 <dm...@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 <co...@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 <dm...@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 <dm...@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 <dm...@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 <co...@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
>>> <ds...@apache.org> wrote:
>>>
>>> On Wed, Apr 19, 2017 at 6:00 PM, Konstantin Boudnik <co...@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.
>>>
>>>
>>>
>>>
>
Re: GridGain Donates Persistent Distributed Store To ASF (Apache
Ignite)
Posted by Denis Magda <dm...@apache.org>.
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 <co...@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 <dm...@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 <dm...@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 <dm...@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 <co...@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
>> <ds...@apache.org> wrote:
>>
>> On Wed, Apr 19, 2017 at 6:00 PM, Konstantin Boudnik <co...@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.
>>
>>
>>
>>
Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Konstantin Boudnik <co...@apache.org>.
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 <dm...@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 <dm...@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 <dm...@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 <co...@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
> <ds...@apache.org> wrote:
>
> On Wed, Apr 19, 2017 at 6:00 PM, Konstantin Boudnik <co...@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.
>
>
>
>
Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Alexey Goncharuk <al...@gmail.com>.
Sure, those classes will be renamed to use Ignite* prefix.
Any other comments regarding Configuration or public API changes?
2017-05-16 17:12 GMT+03:00 Alexey Kuznetsov <ak...@apache.org>:
> Alexey Goncharuk,
>
> I take a look at source code and noticed classes with names
> like: GridCacheDatabaseSharedManager.java
> As far as I remember we decided that "Grid" is a kind of "deprecated"
> prefix?
>
> What do you think? Does it make sense to rename?
>
> On Tue, May 16, 2017 at 9:06 PM, Alexey Goncharuk <
> alexey.goncharuk@gmail.com> wrote:
>
> > Denis,
> >
> > Headers are updated, RAT check is passing now.
> >
> > 2017-05-16 2:37 GMT+03:00 Denis Magda <dm...@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 <dm...@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 <co...@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 <
> > > roman@shaposhnik.org> wrote:
> > > >>> On Wed, Apr 19, 2017 at 6:21 PM, Dmitriy Setrakyan
> > > >>> <ds...@apache.org> wrote:
> > > >>>> On Wed, Apr 19, 2017 at 6:00 PM, Konstantin Boudnik <
> cos@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.
> > > >
> > >
> > >
> >
>
>
>
> --
> Alexey Kuznetsov
>
Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Alexey Kuznetsov <ak...@apache.org>.
Alexey Goncharuk,
I take a look at source code and noticed classes with names
like: GridCacheDatabaseSharedManager.java
As far as I remember we decided that "Grid" is a kind of "deprecated"
prefix?
What do you think? Does it make sense to rename?
On Tue, May 16, 2017 at 9:06 PM, Alexey Goncharuk <
alexey.goncharuk@gmail.com> wrote:
> Denis,
>
> Headers are updated, RAT check is passing now.
>
> 2017-05-16 2:37 GMT+03:00 Denis Magda <dm...@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 <dm...@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 <co...@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 <
> > roman@shaposhnik.org> wrote:
> > >>> On Wed, Apr 19, 2017 at 6:21 PM, Dmitriy Setrakyan
> > >>> <ds...@apache.org> wrote:
> > >>>> On Wed, Apr 19, 2017 at 6:00 PM, Konstantin Boudnik <cos@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.
> > >
> >
> >
>
--
Alexey Kuznetsov
Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Alexey Goncharuk <al...@gmail.com>.
Denis,
Headers are updated, RAT check is passing now.
2017-05-16 2:37 GMT+03:00 Denis Magda <dm...@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 <dm...@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 <co...@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 <
> roman@shaposhnik.org> wrote:
> >>> On Wed, Apr 19, 2017 at 6:21 PM, Dmitriy Setrakyan
> >>> <ds...@apache.org> wrote:
> >>>> On Wed, Apr 19, 2017 at 6:00 PM, Konstantin Boudnik <co...@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.
> >
>
>
Re: GridGain Donates Persistent Distributed Store To ASF (Apache
Ignite)
Posted by Denis Magda <dm...@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 <dm...@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 <co...@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
>>> <ds...@apache.org> wrote:
>>>> On Wed, Apr 19, 2017 at 6:00 PM, Konstantin Boudnik <co...@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.
>
Re: GridGain Donates Persistent Distributed Store To ASF (Apache
Ignite)
Posted by Denis Magda <dm...@apache.org>.
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 <co...@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
>> <ds...@apache.org> wrote:
>>> On Wed, Apr 19, 2017 at 6:00 PM, Konstantin Boudnik <co...@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.
Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Konstantin Boudnik <co...@boudnik.org>.
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
> <ds...@apache.org> wrote:
>> On Wed, Apr 19, 2017 at 6:00 PM, Konstantin Boudnik <co...@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.
Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Wed, Apr 19, 2017 at 6:21 PM, Dmitriy Setrakyan
<ds...@apache.org> wrote:
> On Wed, Apr 19, 2017 at 6:00 PM, Konstantin Boudnik <co...@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.
Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Wed, Apr 19, 2017 at 6:00 PM, Konstantin Boudnik <co...@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.
Having said that, this is just a technicality, and I believe that GridGain
will be able to proceed with the code donation either way.
D.
Re: GridGain Donates Persistent Distributed Store To ASF (Apache
Ignite)
Posted by Konstantin Boudnik <co...@apache.org>.
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)
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Tue, Apr 18, 2017 at 11:17 PM, Roman Shaposhnik <ro...@shaposhnik.org>
wrote:
> On Mon, Apr 17, 2017 at 7:37 PM, Denis Magda <dm...@apache.org> wrote:
>
> First of all, it really isn't a good thing that a major functionality
> was developed
> behind the firewall without any feedback from Apache Ignite community.
>
> So the first question I'd like to ask is this: what was the reason for this
> to be developed in such a way (and a follow up -- how can this be
> avoided in the future)?
>
> In my experience the only excuse for something like that is either a work
> that was done before the project joined ASF or work that was done under
> the draconian initial license agreement that can now be re-licensed under
> ASF.
>
Completely agree and I would also personally prefer that all features are
developed in the open source community from the get go. In this case it was
not possible, as it initially was developed for one of the GridGain
customers and eventually evolved into something that could add value to the
community - hence the proposal to open source it.
The code is not complete yet, and will require additional development
before it can become a part of an official Ignite release. I would prefer
that the remaining development can happen openly in the Ignite community.
>
> Which brings me to my next point: any addition to the project that doesn't
> go through the normal channels of small reversible commits that are easy
> to scrutinize for IP issues needs to be vetted. Depending on the size of
> the
> donation a separate SGA for ASF may be required.
>
Correct. We will also be required to fill out the IP-Clearance form,
specifically designed for situations like this one, when a code is donated
into an existing code base:
http://incubator.apache.org/ip-clearance/
>
> Which brings me to my last point: where's the code? In order to have a
> factual conversation about the next steps in the process I'd like to be
> able to take a look at the code available to me under the Apache License.
>
Hm... I guess you are right, the code needs to be provided in a public GIT
repository for review. To my knowledge this has not been done yet.
> On top of which, I would like to either have a full access to the commit
> and authorship history of this code OR a statement from the current
> overall copyright owner.
>
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?
>
> Please make it available and post the URL to this thread. Then we can
> discuss the next steps.
>
> Thanks,
> Roman (wearing his ASF member hat).
>
Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Mon, Apr 17, 2017 at 7:37 PM, Denis Magda <dm...@apache.org> 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?
First of all, it really isn't a good thing that a major functionality
was developed
behind the firewall without any feedback from Apache Ignite community.
So the first question I'd like to ask is this: what was the reason for this
to be developed in such a way (and a follow up -- how can this be
avoided in the future)?
In my experience the only excuse for something like that is either a work
that was done before the project joined ASF or work that was done under
the draconian initial license agreement that can now be re-licensed under ASF.
Which brings me to my next point: any addition to the project that doesn't
go through the normal channels of small reversible commits that are easy
to scrutinize for IP issues needs to be vetted. Depending on the size of the
donation a separate SGA for ASF may be required.
Which brings me to my last point: where's the code? In order to have a
factual conversation about the next steps in the process I'd like to be
able to take a look at the code available to me under the Apache License.
On top of which, I would like to either have a full access to the commit
and authorship history of this code OR a statement from the current
overall copyright owner.
Please make it available and post the URL to this thread. Then we can
discuss the next steps.
Thanks,
Roman (wearing his ASF member hat).
Re: GridGain Donates Persistent Distributed Store To ASF (Apache
Ignite)
Posted by Konstantin Boudnik <co...@apache.org>.
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&A 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\u2019t
> have time to wrap it up in a doc form.
>
> \u2014
> Denis
>
> > On Apr 18, 2017, at 10:44 PM, Dmitriy Setrakyan <ds...@apache.org> wrote:
> >
> > Cos, good questions! My answers are inline...
> >
> > On Tue, Apr 18, 2017 at 4:17 PM, Konstantin Boudnik <cos@apache.org
> > <ma...@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&A 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
> > dev list to ease up the digestion process.
> >
> >
> >>
> >> 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\u2019s 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?
> >>>
> >>> \u2014
> >>> Denis
>
Re: GridGain Donates Persistent Distributed Store To ASF (Apache
Ignite)
Posted by Denis Magda <dm...@apache.org>.
>> 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&A 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 <ds...@apache.org> wrote:
>
> Cos, good questions! My answers are inline...
>
> On Tue, Apr 18, 2017 at 4:17 PM, Konstantin Boudnik <cos@apache.org <ma...@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&A 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
> dev list to ease up the digestion process.
>
>
>>
>> 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: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Posted by Dmitriy Setrakyan <ds...@apache.org>.
Cos, good questions! My answers are inline...
On Tue, Apr 18, 2017 at 4:17 PM, Konstantin Boudnik <co...@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&A 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
dev list to ease up the digestion process.
>
> 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: GridGain Donates Persistent Distributed Store To ASF (Apache
Ignite)
Posted by Konstantin Boudnik <co...@apache.org>.
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&A 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\u2019s 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?
>
> \u2014
> Denis
>
>
>
>
>
>