IP Filtering in IPFinders
Hi All, I have opened the following JIRA for the said topic: https://issues.apache.org/jira/browse/IGNITE-14606 The concept is to filter IPs based on a pattern or a blocklist in IPFinders while consuming IPs. This is more pertinent for cloud based IPFinders since they can have shared containers. For the moment, I have implemented regex based filtering: https://issues.apache.org/jira/browse/IGNITE-14607 for Azure Blob Storage IP Finder. Over time, we can extend the same to other IP finders. Please see the PR: https://github.com/apache/ignite/pull/9024 Regards, Atri -- Regards, Atri Apache Concerted
[jira] [Created] (IGNITE-14608) Blocklist Based IP Filtering in IPFinders
Atri Sharma created IGNITE-14608: Summary: Blocklist Based IP Filtering in IPFinders Key: IGNITE-14608 URL: https://issues.apache.org/jira/browse/IGNITE-14608 Project: Ignite Issue Type: Sub-task Reporter: Atri Sharma -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14607) Regex Based Filter in IPFinders
Atri Sharma created IGNITE-14607: Summary: Regex Based Filter in IPFinders Key: IGNITE-14607 URL: https://issues.apache.org/jira/browse/IGNITE-14607 Project: Ignite Issue Type: Sub-task Reporter: Atri Sharma This Jira tracks the effort to implement regex based IP filtering in IPFinders -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14606) Filter Support in IPFinders
Atri Sharma created IGNITE-14606: Summary: Filter Support in IPFinders Key: IGNITE-14606 URL: https://issues.apache.org/jira/browse/IGNITE-14606 Project: Ignite Issue Type: Improvement Reporter: Atri Sharma In some scenarios, IPFinders need to be able to filter returned IPs based on a blocklist or a pattern. This is especially useful for cloud based IPFinders where the container can be shared. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Model of permissions for Ignite 3
Danis, Got it, thanks. Please provide the link to the IEP when you have one, I’d be happy to review! -Val On Tue, Apr 20, 2021 at 12:21 AM Denis Garus wrote: > Hello! > > We arranged that I prepare an IEP. > If you have some ideas about what should be reflected in this IEP, do not > hesitate to let me know. > > вт, 20 апр. 2021 г. в 02:06, Valentin Kulichenko < > valentin.kuliche...@gmail.com>: > > > Hi folks, > > > > Did you have a discussion? How did it go? Can someone summarize the > > results? > > > > -Val > > > > On Mon, Apr 12, 2021 at 2:00 AM Kseniya Romanova < > > romanova.ks@gmail.com> > > wrote: > > > > > Hi! Scheduled open call for Friday > > > https://www.meetup.com/Moscow-Apache-Ignite-Meetup/events/277518672/ > > > Please join to see the zoom link. Consulted with Denis Garus and put > the > > > topic as "Security", cause it's definitely wider than just permissions. > > > > > > Cheers! > > > > > > пн, 12 апр. 2021 г. в 09:25, Alexei Scherbakov < > > > alexey.scherbak...@gmail.com > > > >: > > > > > > > +1 > > > > > > > > We should rethink the security model in Ignite 3 and have a default > > RBAC > > > > based implementation, from my point of view. > > > > By default, no code should be written to enable and use it. > > > > > > > > Let's schedule a meeting and discuss the details. > > > > > > > > вс, 11 апр. 2021 г. в 19:43, Denis Garus : > > > > > > > > > Andrey, Alexey thank you for the feedback! > > > > > > > > > > > I suggest decoupling authentication from authorization > > > > > > > > > > Yes, it would be useful. Existing SecuritySubject and > SecurityContext > > > > > require reworking. > > > > > > > > > > > I think it would be great to have a default implementation of > > > > > user-role-permission model > > > > > > > > > > Completely agree it is a cool idea. Ignite should have more default > > > > > implementation referred to security. > > > > > > > > > > > Should we have a community meeting to discuss this? > > > > > > > > > > Yes, it would be great. > > > > > The wish list for Ignite 3 does not contain security improvement > > that, > > > > > IMHO, is wrong. > > > > > We should fix that oversight on early-stage Ignite 3 development. > > > > > > > > > > пт, 9 апр. 2021 г. в 18:47, Alexey Goncharuk < > > > alexey.goncha...@gmail.com > > > > >: > > > > > > > > > > > Hello Denis, Andrey, Igniters, > > > > > > > > > > > > Why don't we take a step further in improving the security model > in > > > > > Ignite > > > > > > 3? I think it would be great to have a default implementation of > > > > > > user-role-permission model in Ignite to be on par with security > > > models > > > > of > > > > > > widely-used databases. This will complement community efforts in > > > making > > > > > > most of the Ignite 3 behavior to be changeable in runtime. > > > > > > > > > > > > WDYT? Should we have a community meeting to discuss this? > > > > > > > > > > > > > > > > > > чт, 8 апр. 2021 г. в 23:54, Andrey Kuznetsov >: > > > > > > > > > > > > > Hi Denis! > > > > > > > > > > > > > > The idea and prototype look great. > > > > > > > > > > > > > > I'd like to highlight one arguable point. Default authorization > > > > > > > implementation still assumes there are permissions provided in > > > > > > > SecuritySubject. In turn, authentication is still responsible > for > > > > > filling > > > > > > > these permissions. I suggest decoupling authentication from > > > > > > authorization, > > > > > > > so that GridSecurityProcessor implementation is fully > responsible > > > for > > > > > > > obtaining permissions for SecuritySubject given on > authorization. > > > In > > > > > > > particular, implementation can choose an existing behavior of > > > > bundling > > > > > > > permissions with SecuritySubject. > > > > > > > > > > > > > > Makes sense? > > > > > > > > > > > > > > чт, 8 апр. 2021 г. в 17:52, Denis Garus : > > > > > > > > > > > > > > > Sorry, I forgot to point the link > > > > > > > > > > > > > > > > 1. https://github.com/apache/ignite/pull/8989 > > > > > > > > > > > > > > > > чт, 8 апр. 2021 г. в 17:50, Denis Garus >: > > > > > > > > > > > > > > > > > Hello, Igniters! > > > > > > > > > > > > > > > > > > I want to propose to improve the way which we use > > > > > > > > > to present permissions in Ignite 3. > > > > > > > > > > > > > > > > > > The model of permission in Ignite has a set of drawbacks. > > > > > > > > > The main drawback, IMHO: if you need to add a new > permission, > > > > > > > > > you should change the core module by extended the > > > > > > 'SecurityPermission' > > > > > > > > > enum. > > > > > > > > > An approach like this becomes more challenged if new > > permission > > > > is > > > > > > > > created > > > > > > > > > for an extension. > > > > > > > > > > > > > > > > > > The existing permission model is overcomplicated. > > > > > > > > > The SecurityPermission enum is divided into four groups, > > > > > > > > > and to determine whether a security subject has been given > > > >
[jira] [Created] (IGNITE-14605) ContinuousQuery fails in java thick client when .NET custom logger is used
Tom Kring created IGNITE-14605:
--
Summary: ContinuousQuery fails in java thick client when .NET
custom logger is used
Key: IGNITE-14605
URL: https://issues.apache.org/jira/browse/IGNITE-14605
Project: Ignite
Issue Type: Bug
Components: cache, clients
Affects Versions: 2.9.1, 2.10
Environment: Ignite running on Windows 10.
Reporter: Tom Kring
The ContinuousQuery fails with a ClassNotFoundException in the following
scenario:
* Use .NET services in the cluster.
* The .NET ignite configuration uses a custom logger. <= this seems to be the
root cause
* Define a .NET class.
* Register the class with the Ignite binary name mapper.
* Start a java thick client.
* Define the same type in java and register it with the binary name mapper.
* Set up a continuous query for a cache.
* Put an instance of the java class on the cache.
* This triggers the ClassNotFoundException.
Here is the .NET code:
{code:java}
static void Main(string[] args)
{
IgniteConfiguration cfg = new IgniteConfiguration();
cfg.BinaryConfiguration = new
Apache.Ignite.Core.Binary.BinaryConfiguration()
{
NameMapper = new BinaryBasicNameMapper() { IsSimpleName = true }
};
cfg.Logger = new SampleLogger(); //comment this out for the
ContinousQuery to work
IIgnite ignite = Ignition.Start(cfg);
ignite.GetCluster().SetActive(true);
ignite.GetBinary().GetBinaryType(typeof(TestDto));
Console.ReadLine();
}
public class SampleLogger : ILogger
{
public bool IsEnabled(LogLevel level)
{
return true;
}
public void Log(LogLevel level, string message, object[] args,
IFormatProvider formatProvider, string category, string nativeErrorInfo,
Exception ex)
{
Console.WriteLine(message);
}
}
{code}
Here is the Java code:
{code:java}
BinaryConfiguration binCfg = new BinaryConfiguration();
BinaryBasicNameMapper namemapper = new BinaryBasicNameMapper();
namemapper.setSimpleName(true);
binCfg.setNameMapper(namemapper);
IgniteConfiguration cfg = new
IgniteConfiguration().setBinaryConfiguration(binCfg);
cfg.setClientMode(true);
Ignite ignite = Ignition.start(cfg);
ignite.binary().toBinary(new TestDto());
IgniteCache testCache =
ignite.getOrCreateCache("testcache2");
//setup a query to get updates
ContinuousQuery query2 = new ContinuousQuery<>();
query2.setLocalListener(new CacheEntryUpdatedListener() {
@Override
public void onUpdated(Iterable> events)
throws CacheEntryListenerException {
// react to the update events here
events.forEach(event -> {
TestDto test = (TestDto)event.getValue();
});
}
});
testCache.query(query2);
TestDto t = new TestDto();
t.Value = "value";
testCache.put(1l, t);
{code}
Here is the exception:
{code:java}
Exception in thread "main" org.apache.ignite.cache.CachePartialUpdateException:
Failed to update keys (retry update if possible).: [1] at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1245)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:2083)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1319)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:856)
at itron.Program.main(Program.java:95) Caused by: class
org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
Failed to update keys (retry update if possible).: [1] at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:407)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.onPrimaryResponse(GridNearAtomicSingleUpdateFuture.java:253)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateResponse(GridDhtAtomicCache.java:3311)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$500(GridDhtAtomicCache.java:146)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:306)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:301)
at
Re: Stop sending IGNITE Created e-mails to dev@
Hello, Maxim! You are free to revert any commit which has led to any new stable test failure, or new flaky test that was non-flaky before. Just revert the change and reopen the ticket. The problem here is that it's very hard to detect on the spot, most of MTCGA e-mails are false positives and even if they are not, it is not relevant for most of developers. WDYT? I'm also still waiting for more input. Regards, -- Ilya Kasnacheev ср, 14 апр. 2021 г. в 21:26, Maxim Muzafarov : > +1 for new JIRA issues > -1 for MTCGA notifications > > Why we should hide errors from the dev-list? Who should take care of > issues reported by MTCGA.Bot in this case? > We must apply stricter rules for such issues: a commit leading to an > error must be reverted. > > On Wed, 14 Apr 2021 at 20:00, Denis Mekhanikov > wrote: > > > > Huge +1 to this. > > > > I've already brought up this topic in the past: > > > http://apache-ignite-developers.2346864.n4.nabble.com/Bots-on-dev-list-td34406.html > > I hope some day newcomers won't need to set up their email filters when > > they come to the developers list. > > > > Denis > > > > ср, 14 апр. 2021 г. в 18:07, Atri Sharma : > > > > > +1 to move issues to the issues list. > > > > > > For MTCGA, maybe build@? > > > > > > On Wed, Apr 14, 2021 at 8:35 PM Ilya Kasnacheev > wrote: > > > > > > > > Hello! > > > > > > > > We have a discussion on how to ensure best engagement in dev@ list, > and > > > it > > > > seems that Issue Created emails from IGNITE project consume a lot of > > > screen > > > > space, it's hard to spot genuine discussions in > > > > https://lists.apache.org/list.html?dev@ignite.apache.org for > example. > > > > > > > > We already have issues@ mailing list. I propose that we stop > sending any > > > > JIRA emails to dev@. If anyone wishes to get just Created emails, > they > > > can > > > > subscribe to these messages in their JIRA account settings. I imagine > > > most > > > > of you already filter these messages out, so you may need to adjust > your > > > > filters slightly. > > > > > > > > A distant second is MTCGA messages, which are also autogenerated and > not > > > > informative for most readers of the channel, since they are at best > > > > targeted at a single committer and at worst flaky. > > > > > > > > Where could we move those? What is your opinion here, on both issues? > > > > > > > > Regards, > > > > > > -- > > > Regards, > > > > > > Atri > > > Apache Concerted > > > >
[jira] [Created] (IGNITE-14604) Implement redeploy for DMS manager aggregated watch
Kirill Gusakov created IGNITE-14604: --- Summary: Implement redeploy for DMS manager aggregated watch Key: IGNITE-14604 URL: https://issues.apache.org/jira/browse/IGNITE-14604 Project: Ignite Issue Type: Sub-task Reporter: Kirill Gusakov Assignee: Kirill Gusakov DMS manager must support redeploying of aggregated container watch if any watches returns onUpdate=false. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14603) Implement redeploy for DMS manager aggregated watch
Kirill Gusakov created IGNITE-14603: --- Summary: Implement redeploy for DMS manager aggregated watch Key: IGNITE-14603 URL: https://issues.apache.org/jira/browse/IGNITE-14603 Project: Ignite Issue Type: Bug Reporter: Kirill Gusakov Assignee: Kirill Gusakov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14602) Calcite engine. Wrong string representation of dates outside standard ISO range
Konstantin Orlov created IGNITE-14602:
-
Summary: Calcite engine. Wrong string representation of dates
outside standard ISO range
Key: IGNITE-14602
URL: https://issues.apache.org/jira/browse/IGNITE-14602
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Konstantin Orlov
Subj.
Affected tests:
{{src/test/sql/types/date/date_parsing.test_ignored}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14601) Specs should use service's params instead of copying.
Anton Vinogradov created IGNITE-14601:
-
Summary: Specs should use service's params instead of copying.
Key: IGNITE-14601
URL: https://issues.apache.org/jira/browse/IGNITE-14601
Project: Ignite
Issue Type: Sub-task
Reporter: Anton Vinogradov
Assignee: Anton Vinogradov
Currently a lot of params copied to spec.
Need just to use {{self.service.xxx}} instead
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14600) [Ducktape: Thin client] Add SSL configuration
Evgeniya Vdovets created IGNITE-14600: - Summary: [Ducktape: Thin client] Add SSL configuration Key: IGNITE-14600 URL: https://issues.apache.org/jira/browse/IGNITE-14600 Project: Ignite Issue Type: Sub-task Reporter: Evgeniya Vdovets Assignee: Evgeniya Vdovets 1. Add SSL parameters to IgniteClientConfiguration 2. Add SSL parameters tp config template 3. Realise "SSL parameters initialisation from globals" logic in IgniteClientConfiguration (it is already done for IgniteConfiguration: https://github.com/apache/ignite/blob/ignite-ducktape/modules/ducktests/tests/ignitetest/services/utils/ignite_configuration/__init__.py#L66 This needs to be duplicated for IgniteClientConfiguration) -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [VOTE][EXTENSION] Release Apache Ignite performance-statistics-ext, spring-data-all-ext and spring-tx-ext extensions 1.0.0 RC1
Igniters, Changing the scope of Spring dependencies to "provided" in Ignite Spring extensions does not currently work as expected: some versions of Spring that a user can specify via maven configuration for Spring extensions may conflict with the hard-coded version of Spring dependencies that the ignite-spring module relies on. The issue mentioned above affects the Ignite Spring Transactions integration. And since this integration is included in the Ignite 2.10 release, I suggest postponing the release of the Ignite Spring Transactions integration until the above issue is properly fixed. Any objections? On 16.04.2021 09:15, Ivan Daschinsky wrote: -1 From me. There is an absence of NOTICE and LICENSE files in binary package. Also, there is no source package. These is a violation of apache release policy [1] [1] https://www.apache.org/legal/release-policy.html чт, 15 апр. 2021 г. в 23:23, Nikita Amelchev : According to ASF release policy [1] non-PMC committers can sign artifacts: all artifacts placed in their directory must be signed by a committer, preferably by a PMC member. [1] https://www.apache.org/legal/release-policy.html чт, 15 апр. 2021 г. в 23:05, Dmitriy Pavlov : My best guess that since PMCs have a binding vote in voting in release, a PMC member should sign binaries as well. And I suppose that in the past only PMC members were signing the release. Meanwhile, https://infra.apache.org/release-signing.html does not contain any mention of PMC role and only committers are mentioned there. It might be not an answer, since a lot of projects have PMC=Committer and just one election. Sincerely, Dmitriy Pavlov чт, 15 апр. 2021 г. в 22:05, Ivan Daschinsky : I'm sorry, but is it OK, that artifacts are signed with signature of non-PMC? чт, 15 апр. 2021 г. в 19:26, Nikita Amelchev : Dear Ignite Community, I have uploaded a release candidate of the following extension modules: performance-statistics-ext spring-data-ext spring-data-2.0-ext spring-data-2.2-ext spring-data-commons spring-tx-ext The release candidate of the performance-statistics-ext extension: https://dist.apache.org/repos/dist/dev/ignite/ignite-performance-statistics-ext/1.0.0-rc1/ The following staging can be used for testing: https://repository.apache.org/content/repositories/orgapacheignite-1509 Tags were created: ignite-performance-statistics-ext-1.0.0-rc1 https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=commit;h=b992d9758278c38e93b375b08e4052954744a436 ignite-spring-data-ext-1.0.0-rc1 ignite-spring-data-2.2-ext-1.0.0-rc1 ignite-spring-data-2.0-ext-1.0.0-rc1 ignite-spring-data-commons-1.0.0-rc1 ignite-spring-data-all-ext-1.0.0-rc1 https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=commit;h=277ca95f6472d8bd46d906e70ba1a312d36dadb0 ignite-spring-tx-ext-1.0.0-rc1 https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=commit;h=55a3ae9e011ba48796847a33481842f154f0febb RELEASE NOTES: https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=blob;f=RELEASE_NOTES.txt;h=22f8d665c194ba2dfa6167354d97ad53d5ef206f;hb=c8de80ee14d1fb76d6cbb0b18513bb70b499c3cb DOCUMENTATION: Documentation of listed extensions was updated in the following issues: https://issues.apache.org/jira/issues/?filter=-1=key%20in%20(IGNITE-14417%2CIGNITE-14398%2CIGNITE-14397%2CIGNITE-14493) The vote is formal, see voting guidelines https://www.apache.org/foundation/voting.html +1 - to accept all the Apache Ignite performance-statistics-ext, spring-data-all-ext and spring-tx-ext extensions 1.0.0-rc1 listed in the thread 0 - don't care either way -1 - DO NOT accept either of the Apache Ignite performance-statistics-ext, spring-data-all-ext and spring-tx-ext extensions 1.0.0-rc1 (explain why) The vote will hold for 72 hours and will end on April 18 2021 17:00 UTC https://www.timeanddate.com/countdown/generic?iso=20210418T17=1440=cursive -- Best wishes, Amelchev Nikita -- Sincerely yours, Ivan Daschinskiy -- Best wishes, Amelchev Nikita
[jira] [Created] (IGNITE-14599) Add generic way to bootstrap configuration
Alexander Lapin created IGNITE-14599:
Summary: Add generic way to bootstrap configuration
Key: IGNITE-14599
URL: https://issues.apache.org/jira/browse/IGNITE-14599
Project: Ignite
Issue Type: Improvement
Reporter: Alexander Lapin
Assignee: Alexander Lapin
Currently it's possible to bootstrap configuration only with json formatted
string.
{code:java}
Ignite start(@Nullable String jsonStrBootstrapCfg);
{code}
Instead of given temporary solution some sort of generic implementation should
be used, for example configuration file with set of formats: json, hocon.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14598) Change the Download page reference text
Nikita Safonov created IGNITE-14598: --- Summary: Change the Download page reference text Key: IGNITE-14598 URL: https://issues.apache.org/jira/browse/IGNITE-14598 Project: Ignite Issue Type: Bug Components: website Reporter: Nikita Safonov Please navigate to [https://ignite.apache.org/download.cgi] > 3RD PARTY BINARIES and change the *GridGain Professional Edition* refernce text to *GridGain Community Edition.* The link itself is correct. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14597) Calcite engine. Exception when using FIRST
Konstantin Orlov created IGNITE-14597:
-
Summary: Calcite engine. Exception when using FIRST
Key: IGNITE-14597
URL: https://issues.apache.org/jira/browse/IGNITE-14597
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Konstantin Orlov
Exception is thrown when running a query {{SELECT FIRST(NULL::DECIMAL)}}
{code:java}
class org.apache.ignite.IgniteException: Error at: decimal_aggregates.test:10.
sql: SELECT FIRST(NULL::DECIMAL)
at
org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:518)
at
org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.run(SqlScriptRunner.java:93)
at
org.apache.ignite.internal.processors.query.calcite.logical.ScriptTestRunner$1.run(ScriptTestRunner.java:219)
at java.lang.Thread.run(Thread.java:748)
Caused by: class
org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to plan
query.
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:541)
at
org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:84)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeQuery(ExecutionServiceImpl.java:398)
at
org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:246)
at
org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.sql(SqlScriptRunner.java:111)
at
org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.access$600(SqlScriptRunner.java:51)
at
org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:513)
... 3 more
Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1,
column 8 to line 1, column 27: Function 'FIRST(NULL :: DECIMAL, 0)' can only be
used in MATCH_RECOGNIZE
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:467)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:883)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:868)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5043)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:5574)
at
org.apache.ignite.internal.processors.query.calcite.prepare.IgniteSqlValidator.validateCall(IgniteSqlValidator.java:230)
at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:116)
at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:273)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateExpr(SqlValidatorImpl.java:4259)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4234)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3474)
at
org.apache.ignite.internal.processors.query.calcite.prepare.IgniteSqlValidator.validateSelect(IgniteSqlValidator.java:176)
at
org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1067)
at
org.apache.ignite.internal.processors.query.calcite.prepare.IgniteSqlValidator.validateNamespace(IgniteSqlValidator.java:190)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1041)
at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:232)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1016)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:724)
at
org.apache.ignite.internal.processors.query.calcite.prepare.IgnitePlanner.validateAndGetTypeMetadata(IgnitePlanner.java:202)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:587)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareSingle(ExecutionServiceImpl.java:562)
at
[jira] [Created] (IGNITE-14596) Calcite engine. Support for function TYPEOF
Konstantin Orlov created IGNITE-14596:
-
Summary: Calcite engine. Support for function TYPEOF
Key: IGNITE-14596
URL: https://issues.apache.org/jira/browse/IGNITE-14596
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Konstantin Orlov
Currently a function TYPEOF is not supported.
Affected tests:
{{src/test/sql/types/decimal/decimal_aggregates.test_ignored}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [DISCUSSION] Javadoc style requirements and checks in Ignite-3.
I've fixed the PR.
Now,
1. Javadoc style is only checked if it is present for the element. All
declared javadoc tags MUST have a description.
So, one should either write correct javadoc or don't write at all.
2. Additional checks performed for non-internal and non-test classes. All
public and protected elements must have non-emtpy javadoc.
So, checkstyle detects 500+ missed descriptions (missed javadocs, tags
descriptions, tags themselves) in public scope
and 180+ bad-styles (missed brased, spaces, empty-lines) javadocs in whole
codebase.
I'd suggest to force non-empty javadocs for all non-test classes including
internal (but their members) as well.
On Mon, Apr 19, 2021 at 6:37 PM Andrey Mashenkov
wrote:
> Alexey,
>
> These are bad examples and unfortunately, most of the Ignite code doesn't
> look self-descriptive.
> (Do you feel the difference between @SerializableTransient and
> @TransientSerializable?)
>
> To understand the semantic of e.g. 'metricsHistSize' you have to analyze
> its usages.
> Getter and setter for this property look better, but it still not clear
> what happens with metric values above the limit?
>
> I have another example, one of the core components GridDhtPartitionDemander
> has totally useless javadoc.
> It is obviously has nothing with thread pool + "local cache" phrase looks
> very confusing.
>
> /**
> * Thread pool for requesting partitions from other nodes and populating
> local cache.
> */
> public class GridDhtPartitionDemander
>
> To understand the purpose of this internal component I have to analyze its
> code and usages.
> However, if one will face unexpected behavior, he/she may be confused if
> it is a lack of javadoc or wrong behavior.
>
> There is no way to restrict or avoid such issues with any checks.
> Agree, meaningful javadocs as self-descriptive code is more about culture
> and discipline.
>
> The absence of javadoc on internal API, unreasonably raises the entry
> threshold for new developers and makes the development of intra-component
> interaction harder.
> I admit a high-level description for public classes may be enough to
> resolve this without pushing developers to write empty/useless docs for
> every method/field.
>
>
> On Mon, Apr 19, 2021 at 5:21 PM Alexey Kukushkin <
> kukushkinale...@gmail.com> wrote:
>
>> I personally do not understand why we need mandatory javadoc even in
>> public
>> modules. I think javadoc is needed only when the code is not
>> self-descriptive. What value does a javadoc like this bring
>> <
>> https://github.com/apache/ignite/blob/2.10.0/modules/core/src/main/java/org/apache/ignite/configuration/IgniteConfiguration.java
>> >
>> to a developer:
>>
>> /** Default metrics history size (value is {@code 1}). */
>> public static final int DFLT_METRICS_HISTORY_SIZE = 1;
>>
>> /** Metrics history time. */
>> private int metricsHistSize = DFLT_METRICS_HISTORY_SIZE;
>>
>> BTW, I picked a random example and it already has a copy-paste mistake in
>> the javadoc, which is there for years. I think that indicates it has no
>> real value and developers just do it to comply with the rule.
>>
>> Some say mandatory javadoc is for the discipline but I think Apache Ignite
>> developers are mature enough to understand when additional documentation
>> is
>> really required.
>>
>>
>>
>> пн, 19 апр. 2021 г. в 16:37, Ivan Pavlukhin :
>>
>> > Hi Andrey and Igniters,
>> >
>> > Sorry if I misread something but I have totally different opinion in
>> > one aspect. In my mind it is much better in practice to follow strict
>> > rules for public API javadocs but not for internals. I would use
>> > static checks for API packages and disable them for internal ones and
>> > refine code readability during code review. Main motivation here is
>> > that ubiquitous javadocs did not work well in ignite-2 and I believe
>> > it would not in ignite-3.
>> >
>> > 2021-04-19 13:30 GMT+03:00, Andrey Mashenkov <
>> andrey.mashen...@gmail.com>:
>> > > Hi Igniters,
>> > >
>> > > We use JDK Javadoc tool to validate javadocs on TC (Javadoc suite) in
>> > > Ignite 2 and now in Ignite 3.
>> > > A javadoc tool is designed for javadoc site generation that also
>> performs
>> > > some basic checks and markup validation,
>> > > but has nothing to do with javadoc styles.
>> > >
>> > > I've found maven-checkstyle-plugin has modules for javadoc style
>> > checking,
>> > > which looks more suited for the issue.
>> > > I've tried to turn on javadoc checks in checkstyle plugin, then run it
>> > > against Ignite-3 main branch and got 1200+ errors.
>> > >
>> > > For Ignite-2 thing may goes worse and numbers can be much higher,
>> > > but let please, start a separate discussion for this if one feels it
>> make
>> > > sense.
>> > >
>> > > Javadoc is part of documentation which a face of product and we MUST
>> keep
>> > > high standards for javadocs as well.
>> > >
>> > > Let's improve this within the ticket [1] regarding the next
>> suggestions:
>> > > 1. Add Javadoc checks to
[jira] [Created] (IGNITE-14595) ExpiryPolicy support to python thin client
Ivan Daschinsky created IGNITE-14595: Summary: ExpiryPolicy support to python thin client Key: IGNITE-14595 URL: https://issues.apache.org/jira/browse/IGNITE-14595 Project: Ignite Issue Type: New Feature Components: python, thin client Reporter: Ivan Daschinsky It's of a crucial importance to add support for expiration policy in python client. This is on of the most used feature of any cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14594) Calcite integration. UnionPlannerTest is not included to any test suite
Aleksey Plekhanov created IGNITE-14594: -- Summary: Calcite integration. UnionPlannerTest is not included to any test suite Key: IGNITE-14594 URL: https://issues.apache.org/jira/browse/IGNITE-14594 Project: Ignite Issue Type: Bug Reporter: Aleksey Plekhanov UnionPlannerTest should be included to PlannerTestSuite. Also, some plan checks should be added to the test, currently it only prints plan to the output. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Model of permissions for Ignite 3
Hello!
We arranged that I prepare an IEP.
If you have some ideas about what should be reflected in this IEP, do not
hesitate to let me know.
вт, 20 апр. 2021 г. в 02:06, Valentin Kulichenko <
valentin.kuliche...@gmail.com>:
> Hi folks,
>
> Did you have a discussion? How did it go? Can someone summarize the
> results?
>
> -Val
>
> On Mon, Apr 12, 2021 at 2:00 AM Kseniya Romanova <
> romanova.ks@gmail.com>
> wrote:
>
> > Hi! Scheduled open call for Friday
> > https://www.meetup.com/Moscow-Apache-Ignite-Meetup/events/277518672/
> > Please join to see the zoom link. Consulted with Denis Garus and put the
> > topic as "Security", cause it's definitely wider than just permissions.
> >
> > Cheers!
> >
> > пн, 12 апр. 2021 г. в 09:25, Alexei Scherbakov <
> > alexey.scherbak...@gmail.com
> > >:
> >
> > > +1
> > >
> > > We should rethink the security model in Ignite 3 and have a default
> RBAC
> > > based implementation, from my point of view.
> > > By default, no code should be written to enable and use it.
> > >
> > > Let's schedule a meeting and discuss the details.
> > >
> > > вс, 11 апр. 2021 г. в 19:43, Denis Garus :
> > >
> > > > Andrey, Alexey thank you for the feedback!
> > > >
> > > > > I suggest decoupling authentication from authorization
> > > >
> > > > Yes, it would be useful. Existing SecuritySubject and SecurityContext
> > > > require reworking.
> > > >
> > > > > I think it would be great to have a default implementation of
> > > > user-role-permission model
> > > >
> > > > Completely agree it is a cool idea. Ignite should have more default
> > > > implementation referred to security.
> > > >
> > > > > Should we have a community meeting to discuss this?
> > > >
> > > > Yes, it would be great.
> > > > The wish list for Ignite 3 does not contain security improvement
> that,
> > > > IMHO, is wrong.
> > > > We should fix that oversight on early-stage Ignite 3 development.
> > > >
> > > > пт, 9 апр. 2021 г. в 18:47, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > > >:
> > > >
> > > > > Hello Denis, Andrey, Igniters,
> > > > >
> > > > > Why don't we take a step further in improving the security model in
> > > > Ignite
> > > > > 3? I think it would be great to have a default implementation of
> > > > > user-role-permission model in Ignite to be on par with security
> > models
> > > of
> > > > > widely-used databases. This will complement community efforts in
> > making
> > > > > most of the Ignite 3 behavior to be changeable in runtime.
> > > > >
> > > > > WDYT? Should we have a community meeting to discuss this?
> > > > >
> > > > >
> > > > > чт, 8 апр. 2021 г. в 23:54, Andrey Kuznetsov :
> > > > >
> > > > > > Hi Denis!
> > > > > >
> > > > > > The idea and prototype look great.
> > > > > >
> > > > > > I'd like to highlight one arguable point. Default authorization
> > > > > > implementation still assumes there are permissions provided in
> > > > > > SecuritySubject. In turn, authentication is still responsible for
> > > > filling
> > > > > > these permissions. I suggest decoupling authentication from
> > > > > authorization,
> > > > > > so that GridSecurityProcessor implementation is fully responsible
> > for
> > > > > > obtaining permissions for SecuritySubject given on authorization.
> > In
> > > > > > particular, implementation can choose an existing behavior of
> > > bundling
> > > > > > permissions with SecuritySubject.
> > > > > >
> > > > > > Makes sense?
> > > > > >
> > > > > > чт, 8 апр. 2021 г. в 17:52, Denis Garus :
> > > > > >
> > > > > > > Sorry, I forgot to point the link
> > > > > > >
> > > > > > > 1. https://github.com/apache/ignite/pull/8989
> > > > > > >
> > > > > > > чт, 8 апр. 2021 г. в 17:50, Denis Garus :
> > > > > > >
> > > > > > > > Hello, Igniters!
> > > > > > > >
> > > > > > > > I want to propose to improve the way which we use
> > > > > > > > to present permissions in Ignite 3.
> > > > > > > >
> > > > > > > > The model of permission in Ignite has a set of drawbacks.
> > > > > > > > The main drawback, IMHO: if you need to add a new permission,
> > > > > > > > you should change the core module by extended the
> > > > > 'SecurityPermission'
> > > > > > > > enum.
> > > > > > > > An approach like this becomes more challenged if new
> permission
> > > is
> > > > > > > created
> > > > > > > > for an extension.
> > > > > > > >
> > > > > > > > The existing permission model is overcomplicated.
> > > > > > > > The SecurityPermission enum is divided into four groups,
> > > > > > > > and to determine whether a security subject has been given
> > > > > permission,
> > > > > > > > a plugin developer has to know what the permission group is.
> > > > > > > > But 'CACHE_CREATE' and 'CACHE_DESTROY' are included in two
> > groups
> > > > > > (system
> > > > > > > > operations and cache operations).
> > > > > > > > When 'CACHE_CREATE' ('CACHE_DESTROY') is treated as system
> > > > > permission,
> > > > > > > > it applies to all caches. In other cases, when 'CACHE_CREATE'
> > > > > > > >
