Re: JDBC thin client incorrect security context
Hi! That is a known issue [1]. > is there any workaround to get this information? I think, unfortunately, no. 1. https://issues.apache.org/jira/browse/IGNITE-12589 пн, 17 февр. 2020 г. в 10:02, VeenaMithare : > Hi , > > Hi , > > We have built a security and audit plugin for security of our ignite > cluster. We are unable to get the right audit information i.e. we are > unable > to get the right subject for users logged in through dbeaver ( jdbc thin > client. ). This is because the subjectid associated with the "CACHE_PUT" > event when an update is triggered by the jdbc thin client, contains the > uuid > of the node that executed the update rather than the logged in jdbc thin > client user. > > If this is a limitation with the current version of ignite, is there any > workaround to get this information ? > > This was discussed in the 'Ignite users' group > > http://apache-ignite-users.70518.x6.nabble.com/JDBC-thin-client-incorrect-security-context-td31354.html > > And I was advised to continue my conversation here. > > Andrei mentions that the uuid associated with the event should be that of > the jdbc client( in our case the logged in dbeaver user ). But I notice > that > the event always contains the uuid of the node where the query gets > executed > . > > I do manage to get the right jdbc client from the authenticationcontext in > the authorize and form the right securitycontext. But this doesnt reflect > in > the generated cacheevent. > > Kindly guide. > regards, > Veena. > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >
JDBC thin client incorrect security context
Hi , Hi , We have built a security and audit plugin for security of our ignite cluster. We are unable to get the right audit information i.e. we are unable to get the right subject for users logged in through dbeaver ( jdbc thin client. ). This is because the subjectid associated with the "CACHE_PUT" event when an update is triggered by the jdbc thin client, contains the uuid of the node that executed the update rather than the logged in jdbc thin client user. If this is a limitation with the current version of ignite, is there any workaround to get this information ? This was discussed in the 'Ignite users' group http://apache-ignite-users.70518.x6.nabble.com/JDBC-thin-client-incorrect-security-context-td31354.html And I was advised to continue my conversation here. Andrei mentions that the uuid associated with the event should be that of the jdbc client( in our case the logged in dbeaver user ). But I notice that the event always contains the uuid of the node where the query gets executed . I do manage to get the right jdbc client from the authenticationcontext in the authorize and form the right securitycontext. But this doesnt reflect in the generated cacheevent. Kindly guide. regards, Veena. -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Issue
Issue 9325 needs to be update (https://issues.apache.org/jira/browse/IGNITE-9325), because reporter Artur Romantsov is not available more
Re: [DISCUSS] Relevance of CacheConfiguration.DefaultLockTimeout
Andrey, Good that we care about compatibility! A note for a careful reader: nobody told about removal in this thread ;-) Created a ticket for this and a neighbor thread [1]. [1] https://issues.apache.org/jira/browse/IGNITE-12686 Best regards, Ivan Pavlukhin пт, 14 февр. 2020 г. в 17:40, Andrey Gura : > > I couldn't find any usages too. > > But value if this property is serialized in some places and we can't > remove this due to a backward compatibility. > > I think we can safely remove it on 3.0. But for now it is better to > mark it as deprecated. > > On Thu, Feb 13, 2020 at 5:42 PM Alexey Goncharuk > wrote: > > > > Ivan, > > > > Nothing from my side as well - looks like the property is not used.
[jira] [Created] (IGNITE-12686) Deprecate obsolete configuration properties
Ivan Pavlukhin created IGNITE-12686: --- Summary: Deprecate obsolete configuration properties Key: IGNITE-12686 URL: https://issues.apache.org/jira/browse/IGNITE-12686 Project: Ignite Issue Type: Bug Components: cache Reporter: Ivan Pavlukhin Fix For: 2.9 Following properties were discovered as obsolete (no usages in codebase): * TransactionConfiguration.PessimisticTxLogSize * TransactionConfiguration.PessimisticTxLogLinger * CacheConfiguration.DefaultLockTimeout Let's deprecate them. Note that we are not going to remove them at this stage to avoid possible compatibility issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: ML examples EvaluatorExample and MultipleMetricsExample looks the same
Fixed your comments! Stepan, please rebuild the release and test! чт, 13 февр. 2020 г. в 17:22, Alexey Zinoviev : > Should I wait any ML-related issues in examples? > I could wait a day or two if you are going to continue your testing deals > with ML and examples to push changes together. > > Are you running your examples on the release staging as a ignite > dependency, isn't it? > > > чт, 13 февр. 2020 г. в 14:37, Stepan Pilschikov >: > >> filled ticket - https://issues.apache.org/jira/browse/IGNITE-12673 >> >> чт, 13 февр. 2020 г. в 13:46, Alexey Zinoviev : >> >>> I suppose one ticket is enough, collect where all your nites and thoughts >>> >>> чт, 13 февр. 2020 г., 12:12 Stepan Pilschikov >> >: >>> And one (three) more thing In TutorialStepByStepExample we running 17 examples First 12 logging is pretty good and looks like "Tutorial step N: name" -> model -> accuracy -> "Tutorial step N: completed" But then starting with 13 this pattern is kind of broke, step start and step completion is missing Also want to admin that Step_8_CV_with_Param_Grid_and_metrics_and_pipeline is haven't step completion log And complete log for Step_9_Scaling_With_Stacking looks like 'Tutorial step 5 (scaling) example completed' i don't know, should i made some ticket? One ticket for each problem or one for all or you can fix it in one commit? because fixes quite small ср, 12 февр. 2020 г. в 16:31, Alexey Zinoviev : > Yes, you are right. Missed resources, I'll remove them tomorrow > > ср, 12 февр. 2020 г. в 16:23, Stepan Pilschikov < > pilshchikov@gmail.com>: > >> With mnist_tf_model in same directory >> All others looks right >> >> ср, 12 февр. 2020 г. в 16:21, Stepan Pilschikov < >> pilshchikov@gmail.com>: >> >>> Hmm, interesting, got it >>> Also found >>> apache-ignite-2.8.0-bin/examples/src/main/resources/models/mleap >>> I think its also should be removed then >>> >>> ср, 12 февр. 2020 г. в 16:11, Alexey Zinoviev < >>> zaleslaw@gmail.com>: >>> Please, have a look to the next ticket https://issues.apache.org/jira/browse/IGNITE-12659 Also tensorflow packages are blockers for IGFS deprecation and removal. ср, 12 февр. 2020 г. в 15:58, Alexey Zinoviev < zaleslaw@gmail.com>: > They are not lost, they are removed from release branch due to a > lot of bugs, cves and so on, don't worry about that. > > ср, 12 февр. 2020 г., 14:31 Stepan Pilschikov < > pilshchikov@gmail.com>: > >> Also lost ignite-ml-tensorflow-model-parser and ignite-tensorflow >> in libs/optional >> >> >> ср, 12 февр. 2020 г. в 14:25, Stepan Pilschikov < >> pilshchikov@gmail.com>: >> >>> But now have new problems >>> I build ignite-2.8 build on TC >>> https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/5043672 >>> Previous >>> https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/4988324 >>> >>> New build much lighter >>> Previous: 5.7 Gb >>> Current: 4.3 Gb >>> And its looks like something missing, on a first look i notice >>> that /libs/optional/ignite-ml-mleap-model-parser lost completely >>> >>> >>> ср, 12 февр. 2020 г. в 14:18, Stepan Pilschikov < >>> pilshchikov@gmail.com>: >>> Thanks for fix Duplicated examples deleted and tutorial works on real (1+ node) cluster now I think ticket can be closed, have no power here вт, 11 февр. 2020 г. в 20:44, Alexey Zinoviev < zaleslaw@gmail.com>: > Sorry, for that, but I it touches ML-related stuff only and > doesn't influence on any another module. > I merged them to master later (currently, I have a 4 tickets > in a queue). > > Will keep in mind for the next fixes > > вт, 11 февр. 2020 г. в 18:58, Maxim Muzafarov < > mmu...@apache.org>: > >> Alexey, >> >> Is the approach when we cherry-pick fixes to the 2.8 only >> after all >> fixes have verified in the master branch better? I just want >> to be >> sure the release branch to be stable enough. >> >> On Tue, 11 Feb 2020 at 18:36, Alexey Zinoviev < >> zaleslaw@gmail.com> wrote: >> > >> > Fixed both in release branch 2.8. Please verify and let me >> know >> > >> > вт, 11 февр. 2020 г. в 14:58, Stepan
Re: [ML] Tickets for beginners
I thought about this task. We have enough examples where encoders are used as part of preprocessing and have regression or classification algorithm as a result. I suggest in this ticket to prepare example that are not ended with the trainer, please have a look to examples/ml/dataset folder Maybe you could create something meaningful like this. Your choice! пт, 14 февр. 2020 г. в 10:17, Alexey Zinoviev : > Hi, Lev! > I'll return with explanation on next week, maybe I need to adds some > details to this ticket. > > P.S. About dataset - you could search among the datasets presented in > MLSandbox class or could add your own (I'd prefer small datasets from > http://archive.ics.uci.edu/ml/index.php) > > > пт, 14 февр. 2020 г. в 10:02, Лев Киселев : > >> Hello everyone >> I'd like to take following task: >> >> https://issues.apache.org/jira/browse/IGNITE-12384?jql=project%20%3D%20IGNITE%20AND%20status%20in%20(Open%2C%20Reopened)%20AND%20component%20%3D%20ML%20AND%20labels%20%3D%20newbie >> >> But I do not fully understand what exactly needs to be done. >> As far as I understand encoders are needed to convert categorical >> variables >> to numerical. So, to demonstrate how they works I need some dataset with >> several categorical features. Should I search for it or generate by >> myself? >> Then, do I need to solve some regression/classification problem in order >> to demonstrate "power" of using categorical variables to fit prediction or >> classification models? >> >
[jira] [Created] (IGNITE-12685) [ML] [Umbrella] Unify Preprocessors and Pipeline approaches to collect common statistics
Alexey Zinoviev created IGNITE-12685: Summary: [ML] [Umbrella] Unify Preprocessors and Pipeline approaches to collect common statistics Key: IGNITE-12685 URL: https://issues.apache.org/jira/browse/IGNITE-12685 Project: Ignite Issue Type: Improvement Components: ml Reporter: Alexey Zinoviev Assignee: Alexey Zinoviev Fix For: 2.9 In the current implementation we have different behavior in Cross-Validation during running on the experimental Pipeline and chain of Preprocessors. Look at the tutorial step 8 CV_Param_Grid and 8_CV_Param_Grid_and_pipeline In the first example all preprocessors fits on the whole dataset and don't use train/test filter (due to limited API in preprocessors), and collects the stat on the whole initial dataset. In the second example, we have honest re-fitting on each cross-validation fold three times with three different stats. As a result we could get a different encoding values or Max/Min values for each column and so on. Should learn this question and be in consistency with the most popular approaches. -- This message was sent by Atlassian Jira (v8.3.4#803005)
