Hello, Igniters!
Alex Plehanov did the review, and I've reworked the implementation of the
issue [1] that is part of the IEP-38 [2].
Could somebody else do a review of the PR [3]?
Alex, thank you for the review!
1. https://issues.apache.org/jira/browse/IGNITE-11410
2.
Hello, Pavel!
Thank you for the feedback!
I've created IEP-38 that describes the Ignite Sandbox [1].
Yes, the issue requires documentation (there is the flag "Docs equired"),
but common practice is to write documentation in the end.
>> 1) Why do you run resource injection through security and
Denis,
The idea of having a sandbox for running a user-defined code is useful, but
I don't fully understand the implementation approach.
There is no detailed description of the ticket about what public API
methods or configuration parameters should be covered.
There is no description of what have
Fully agree with the benchmark's importance.
Currently, we're not able to perform proper benchmarking.
Slava, Is it possible to ask you to check the solution using GridGain's
benchmarking environment?
On Mon, Oct 14, 2019 at 12:07 PM Вячеслав Коптилин
wrote:
> Hello Anton,
>
> > We should avoid
Hello Anton,
> We should avoid heavy merges if possible.
Why it should be avoided? To be honest, I don't see any reason for that.
Every pull request can be and should be reviewed when it is done and ready
to be merged into the epic branch (IEP branch).
So, the final review of the entire IEP is
Folks,
We should avoid heavy merges if possible.
I'm ok with IEP to keep tasks properly, but strictly against all-in-one
"+27000,-18200" merges.
This task implements Sandbox (API + core) which covered by tests and by
some integrations with existing components, which is enough to merge.
The most
Hi Denis,
In my humble opinion, the security (the sandbox feature is about security,
right?) either covers all APIs/subsystems or not.
Security should work always and everywhere otherwise it is not security :)
> From my point, we should divide the sandbox and features that use it.
> Also, I
>From my point, we should divide the sandbox and features that use it.
The sandbox is fully implemented and has needed tests.
Also, I added in the main features of Ignite (cache and compute) the
sandbox calls.
I don't see any problem to have the sandbox in the master branch
and implement
Hi Denis,
Yep, I understand the scope of the ticket, but... I think it is not a good
idea to merge partly implemented feature(s) into the master branch.
Especially, at this moment. We are at the stage of preparing a new release
and I doubt that all improvements, tests (unit tests, integration
Hello, Slava!
The scope of the issue is limited by the following features:
- StreamReceiver for DataStreamer;
- EntryProcessor;
- ComputeJob;
- filter and transformer for ScanQuery.
But, sure, we should execute any user-defined code in the sandbox on a
remote node.
Feel free to
Hello Denis, Anton,
Could you please clarify the following aspect? Do we need the same
changes/capabilities related to Continuous Queries, Disco listeners,
CacheStore Factories etc?
Thanks,
S.
пт, 11 окт. 2019 г. в 12:24, Anton Vinogradov :
> Folks,
>
> As a prereviewer, I'd like to say that
Folks,
As a prereviewer, I'd like to say that the solution looks good to me, but
fresh eyes would be good.
On Fri, Oct 11, 2019 at 9:40 AM Denis Garus wrote:
> Hello, Igniters!
>
> I've raised the PR [1] with the sandbox for AI [2].
> Could somebody review it?
>
> If you have questions and
Hello, Igniters!
I've raised the PR [1] with the sandbox for AI [2].
Could somebody review it?
If you have questions and prefer the Slack, I've created the channel [3].
1. https://github.com/apache/ignite/pull/6707
2. https://issues.apache.org/jira/browse/IGNITE-11410
3.
13 matches
Mail list logo
